Ask HN: Who is consuming all these semantic HTML tags?
What I know: screen readers may announce/make use of main/article/section/aside/nav/search/del/ins because they have default ARIA settings.
What I want to know: who ELSE consumes these tags and for what, and who is consuming:
1. <figure> and <figcaption>
2. <small>
3. <strong> and <em>
4. <del> and <ins>
5. <samp> and <kbd>
6. <small>
7. <abbr>
8. <cite> and the cite attribute of <blockquote>
9. <mark>
10. <hgroup>
<kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</samp></kbd></kbd>
And I have no idea why would anyone bother with such complicated markup instead of just using <code>, because... if nobody would write code like this, why would anyone write a program to read code like this that nobody is writing?
I think I've read that <article> should work like an ATOM feed, but is anyone parsing <article> as if they were feed items? I mean, as a general-purpose solution. If it's done for a single site that's not really markup-level semantics, that's like site-level semantics, you could have just used a selector based on the class that site used for its articles, for example. Is that all this is? A shorthand for class="..."?
[1] https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-kbd-element
47 comments
[ 3.1 ms ] story [ 116 ms ] threadIn theory, more information would be easier for a language model to extract meaning from though.
I feel so disappointed with all the hand-waviness I'm almost considering using the <big> tag for big text. The only thing stopping me is that I don't know if I'll get a penalty somewhere for using a deprecated tag.
Also, underline doesn't work for vertically oriented scripts, and is usually just another way to emphasize, which is why it was moved to styling instead.
Why would someone writing English have to think about how bold text looks like in Japanese? That makes no sense.
Even for accessibility it makes no sense. As far as I know, screen readers don't even announce bold/italic/em/strong or them differently. And if they announced, I'd expect any italic text I ever write to be read out loud as "in italics..." not "in emphasis..."
I genuinely can not understand the thought process that went into creating these tags. It's like they completely ignored the idea that text as a medium has its own layer of semantics and tried to skip over it. But this is just my personal opinion. In the end the objective facts are that <em> and <strong> don't really do anything in the real world besides wasting more bytes than <i> and <b>, so there's exactly zero benefits in using them.
I really wish someone would prove me wrong, though, hence this thread.
Imagine if I had a markup language for voice synthesis. If I typed a word, the computer would say out loud that word. But I had tags like <whisper> and <yell> to change the volume of the computer voice, and <pausedly> and <quickly> to change its speed. These tags make no sense in the text medium, and yet their semantics are self-evident in speech.
If authors had a way to mark up how their text should be voiced, perhaps they would mark them so. Who wouldn't love a real <sarcasm> tag for sarcastically voiced text? But HTML went the opposite way. Instead of providing more tools to let authors express themselves, they took every format of expression and dumped it in a single label.
Of all the opinions someone could hold strongly, that's certainly one of them.
No, I only care about the way I write text. If I'm writing an article and I want to make text bold, I don't want to waste my time having to come up with a deeper explanation about WHY should the text be bold. That's an obstacle in the creative process. I want bold text. Period. I don't want <em> or <strong>, and I don't want a "bring attention to" element". I want bold.
Can you say that EVERY SINGLE TIME I want bold text that will match the semantics of <strong>? If that's true, then it shouldn't be called <strong>, it should be called <bold>. If that's not true, then one day I'll mark something as <strong> because I want bold text and it will be the incorrect tag for that text because of a semantic mismatch. In that case, what should I do? Should I just use <span style="text-weight: bold"> or <span class="bold"> for my bold text? Are you telling me that every time I want bold text I'll have to make the conscious choice of deciding whether I should use a <strong> tag or a <span> tag? Can you imagine the nightmare of making this work in a CMS like Wordpress? It would be much easier to just never use <strong> at all and just use <span> for bold every time.
If the only way to make sure you're using the semantics correctly is to just never use the tag at all, I say we just give up on this <strong> nonsense and use the <b> tag which matches the semantics of what the person writing the text wants to convey.
When I read the above, I thought: you want bold, because you want to highlight a word. Because highlighting a word is a widely recognized way to bring attention to it. And so making it bold is just a tool, it's secondary to the actual goal.
I suspect you might not agree with that, but could you point me to the part where I got it wrong from your perspective?
Trying to come up with an universal reason for why bold is bold is like trying to come up with an universal formula to explain why any number 42 is 42. You wouldn't say every 42 came from 40 + 2 just because 40 + 2 equals 42, because some 42's come from 44 - 2 and others come from 6 times 7. Similarly, there is no universal reason for bold to be bold except for the fact that it is bold and that is it.
You say bold is used for highlighting. What would you say italic is used for then? And underline? All caps? Small caps? Title case? Colored text? A yellow background on the text? There are countless ways to highlight text.
Do you have the courage to style <strong> as ANYTHING but bold or <em> as anything but italic? (oblique doesn't count!)
No, you do not.
Because in your heart you know. The writer CHOSE bold. He CHOSE italic.
He had all these "highlight" tools in front of him, like a palette of colors, and he specifically and unambiguously picked bold. You can't ever change the meaning of bold to anything but bold, regardless of whether you use <b> as bold or <strong> as bold, because bold is an inseparable part of the content now.
If you changed <strong> to a non-bold red color text, it would change the typographic semantics of everything ever written with <strong>.
So in my view, it's not something abstract like highlight, it's literally bold, in its pure concrete form, because the author had a healthy vision, he spoke a Latin language, and he wanted his text to have bold letters.
I mean, just look at Wordpress and WYSIWYG editors. Nobody in sane mind would write "emphasis" and "important" text unstyled and put those buttons in the editor, because no author would EVER click on them. No author WANTS to mark emphasis or important text. Authors click the B button and the I button because they want bold and italic.
Can you imagine someone looking up Markdown's or restructured text's to find out how to mark "emphasis"? Nobody is writing text or *text* or _text_ or __text__ because they want emphasis. They're looking up which one of these characters generates BOLD text.
What the author means is BOLD. Means. As in meaning, semantics. It makes no sense to second guess what they really mean and change those semantics to emphasis/importance just because you think those are human-language/medium-agnostic and thus more portable. When you change <b> to <strong> what you're doing has a name: semantic bleaching, which happens when a word that had concrete meaning loses its meaning when it starts functioning in a more abstract (grammatical) way. Feels like the opposite of what anyone would want!
And then IMHO it would be incorrect to use <strong>.
As for the difference between <strong> and <em>, they way I understand it is:
> <strong>Hacker News</strong> is <em>the</em> site.
Basically one highlights a term (say, it could be then looked up somewhere), and the other adds spoken emphasis--in the above sentence, HN is not some site, it's THE site we talked about before.
The standard way of rendering (or priting) words with such semantic meaning is respectively bold and italics. But if you ask me it could also be underline and uppercase (respectively).
And if you render the page not to a visual medium but to sound (screen readers), then you give the screen reader a chance to treat (and read) those words differently.
So, why couldn't they do that with <b> and <i>?
Every person with healthy vision writing a Latin language is using <strong> as bold, and most of them don't even realize it because it's hidden behind GUIs that show a B (bold) button which generates <strong> code. If you make this an issue in their tracker they will just tell you <strong> is more semantic and <b> won't be used.
Regardless of what the semantics of <strong> should have been, in practice you just made <b> with a longer name. In other words, there is no reason to use or have made <strong>, since the end result was just <b> again. Screen readers could have just done what they do with <strong> (i.e. nothing) with <b> and saved us all a lot of trouble.
I can say that almost every single time someone wants bold text now it will be a <strong> tag, even if the semantics are wrong.
So waitasecond, <strong> was created, airheaded developers of WYSIWYG plugins messed it up, and that retroactively means there is no reason for it to have ever been created? That's a real pretzel you're twisting.
How about: "Programmers of WYSIWYG widgets should just stop messing things up, i.e. sabotaging the efforts of the blind and other people who use/develop screenreaders—so we can finally achieve the accessibility wins that <strong> was created to solve"?
> Screen readers could have just done what they do with <strong>
No, they can't. Not in the sense of, "There's a problem that exists. We want to solve it." Your proposal is to ignore the problem and do nothing. You can apply that approach to anything. (Heck, why even have screenreaders at all? People who are blind or dyslexic are shut out from the Web? Let's just do nothing.)
> ...and saved us all a lot of trouble
Saved who a lot of trouble? What trouble?
Your company then decides that Japanese text should be supported. Now your code needs to output italics / underlines for English, or emphasis dots / enlarged text / font change in Japanese. You dutifully add the style sheet shenanigans and special case HTML generator code to do this.
Next, your company wants to support Hindi. So now your code needs to support three different ways to render the text depending on intent and language - with all the maintenance headache this entails.
... and so on.
Soon enough you start to think "This is crazy! I'll just make some style classes for things that need emphasizing, and then put the presentation stuff in the style sheets. That way I can greatly simplify things!"
And now you've invented em and strong.
The whole reason why style sheets were invented was to separate intent from presentation. The i and b tags in HTML are a classic example of engineering failure due to the assumption that they knew enough about a subject outside of their wheelhouse, and as a result failed to consult the experts (in this case, typesetters). Once the experts weighed in, the i and b tags were (rightly) deprecated.
Here's a random article about the upcoming EU regulations: https://www.siteimprove.com/glossary/eu-web-accessibility-di... - they also have a site checker that performs an automated accessibility scan.
As for it not being critical due to inconsistent screen reader support--it sounds like a chicken and egg problem. If developers don't use those tags consistently, then people using screen readers have hard time with them, and so screen readers adjust.
In any case, if it doesn't hurt but can potentially help, I personally prefer to use semantic tags to convey the meaning and visual styles for pure visual effects.
The point of semantic HTML is that it benefits everybody equally by providing well described content for all readers. This is the purpose of accessibility. For visual readers this means the browser provides some default presentation that enhances the quality of output with minimal effort to the developer. For users reliant upon screen readers it means the content is communicated with greater precision and clarity. For bots it means stronger acceptance of your content versus other competing sites.
Honestly, HTML is past its prime. Most developers cannot be bothered to figure this stuff out, and cannot be figured how to use the browser's compile target (the DOM), and so much more. Instead most developers are entirely reliant on enormous frameworks and HTTP to do absolutely everything for them. Its like reading a menu is too challenging so instead buying the restaurant and kitchen staff. Its exchanging one set of problems for another at 10x the expense and then crying when people point this out. None of this is challenging, but... the world is filled with non-challenges that people would rather go to war to avoid.
HTML should have had first-class support for templating, in my opinion. The model should be that a page references a template by a URL, and the browser won't render anything until it has fetched the template. But they were adamant in sticking to the isolated document model that hasn't made sense for pretty much all of HTML's applications.
I wish Google or Microsoft would come up with a replacement for HTML that was website-aware. It really only needs to replace text/html with text/html2 and have the server send this new markup that is parsed in a different way. Most web technologies could remain the same and it would be a huge leap forward. In fact, considering how much the code generation is done by frameworks anyway, most developers wouldn't even notice they aren't sending normal HTML anymore, just like they wouldn't notice when HTTP2 is being used.
Whether HTML is provided as a full document or in micro-segments with/without templates is irrelevant. This is actually a form of empathy failure. Templates exist as a convenience to developers as necessary to reduce or eliminate code repetition, but your users are reading the inter-working of your source code.
I think HTML vastly outgrew its use case because it kept avoiding breaking backward compatibility. It was obvious from the start, but we patched the lack of built-in templating with frames and then with AJAX.
Again, whether or not HTML outgrew its business case is irrelevant to whether it is properly deployed to its consuming audience.
Programming separates out presentation and logic (html and JavaScript). This is a good thing. I'd like to see the separation to go further.
Locking presentation to logic language is a great way to stifle innovation, it's the same reason why we are not browsing the web through a pdf renderer.
I'm sure Adobe would love that timeline.
Yeah, don't do that. Use server-side includes for all the common elements. If your server doesn't support server-side includes then they're pretty easy to replicate with a couple of lines of JS, or via a web component. (But HTML really should have a client-side include tag. The Object and iframe tags sort of work but not properly.)
> So for most of HTML's life, we've used the wrong tool for the job
Hard disagree. HTML is great for large websites, e.g. news sites and wikis, etc., especially if you have a decent server setup. It's not so good for web apps, but we all know that.
> HTML should have had first-class support for templating
Would have been nice, but it's easy enough to just do that on the server with SSI or PHP, or XML+XSLT, or any of the many server frameworks.
and that ideally it would be supported natively in the language rather than requiring find-and-replace tooling
These are all solutions to the same problem: HTML lacks this natively. Web browsers had 20 years to provide a solution for literally copying text code and they were quicker to implement WebGL and web assembly...
And the worst of all is that the only "templating" solution we got with <template> made the same mistake as frames did: the accessed page is the root and the included code is the children. HTML needs dependency inversion. Just like we include a single bundle.js that controls all pages in a website there should have been a way to include single template.html that defines the layout used through a site, the JS and CSS required by this layout, and other reusable template components too (which, imo, HTML should be to render without needing JS. Seriously, I should be able to write a web-component <my-h1> that unpacks to <div class="h1-wrapper"><h1> without needing JS because that cover 50% of the use cases...)
I'm not sure why we have CSS frameworks that require buttons to have a "btn btn-filled btn-solid" class though, and be wrapped in a form-control in a control-group in a form-group-container.... semantic still works fine.
In my view, frameworks are the result of someone realizing that an abstraction is easier to work with. Just like we don't write in machine code or assembly code much anymore. This seems like a simpler explanation than a conspiracy by "employers" to commoditize software development.
Let me explain it like this. Writing software is just another form of writing. Writing, at least on a very simplistic level is something everybody should be capable of achieving with even the most modest and basic of elementary education. Yet, most people cannot do more than write shopping lists or granular syntax like filling out forms or writing small letters. The effort to achieve something actually original is not great, but its entirely reliant upon a high level of openness which is tightly coupled with high intelligence, and most people don't have that. Even worse is the ability to do it often enough as required for employment requires high industriousness and there is absolutely no correlation between industriousness and intelligence, which means intelligence alone is not a sufficient predictor of success.
The problem is then expectations to achieve original output are inversely proportional the availability of people to do the work even for the smallest of tasks. Compensation does not make up for this, not even close. For one thing the demand for the requisite labor is too high. Secondly, most of this output requires extremely low effort and most employers cannot bring themselves to pay extremely high incomes to tiny repetitious tasks even if few people are capable of doing it well. Third, even if they were willing to pay in excess of $300,000 for a person to put text on screen 2 hours a day the greater concern is how to replace that person should they get hit by a bus. The high salary, even for low cost geographies, is not a stretch after consideration for recruitment and benefits and so forth, so other factors become greater constraints.
The solution business has settled upon is to architecturally constrain the effort, even at great expense. Then everybody must do things the same certain way and do so without any investment of training on the part of the employer. The output can be garbage, but if the developers are commodities at least the cost of continuity remains low and finding replacements is dramatically faster.
Mobile battery life and performance is already pretty amazing.
A world where we have our very smartest people putting text on a screen instead of ending world hunger or something, or where all the apps are broken constantly, or where development randomly halts as teams come and go, or where only top geniuses can be hired and the rest of us have to work service and labor with basically no career path to anything else except maybe management, doesn't sound like what I want.
Pandoc will generate html code using these elements when you use implicit_figures feature:
https://pandoc.org/MANUAL.html#extension-implicit_figures
And it seems to be well supported in web browsers:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fi...
You can see an example how it looks like in this post from my blog, there are no css tweaks for figure or it's caption (I use static site generator based on pandoc):
https://blog.marbu.eu/posts/2023-04-29-the-first-web-browser...
And personally I find that better compared to alternative solution consisting of multiple div elements.
The spec explicitly notes:[1]
The point of <figure> is that the element can be REMOVED from the document and moved elsewhere without changing the meaning of the document. I assume the intention is that you say "see figure 3" like a textbook. If you write something like: There's no way to move the <figure> containing the screenshot to a sidebar for example, because then what you wrote wouldn't make any sense.If <figure> was being used the way it was meant to be used, it would be trivial to write a browser plugin that hid all figures and listed them in a sidebar. But nobody is following the spec. Everyone in the planet is using <figure> as if it was just a container for an image with a tag for the image caption (pandadoc, wordpress, etc., are all doing this!), so that's in practice what it is now.
This is what makes it so hard to understand who would even consume these tags for something useful. It seems every time they're widely used, they're widely used with semantics that don't match the spec, so if you wrote a markup-based tool, you would have to go against the spec, which means there is no point in having a common HTML spec in first place, just make your own API like microdata. I'd even say the only reason that browsers work at all is that authors are forced to see their websites through a browser so the markup has to at least work in the browser. For every tool that authors don't all use (such as a browser plugin that hides figures), there's no way to guarantee the author used the markup correctly, so it's not something that can be relied on.
[1] https://html.spec.whatwg.org/multipage/grouping-content.html...
I would not blame this on pandoc though, it's my mistake of missing what the intended purpose of figure element is, because I haven't studied the spec and browsers doesn't do anything useful with it (as you pointed out). That said if I used pandoc to generate pdf via latex, I would have noticed that, since the figures are repositioned as expected in such case.
And while I agree that in the current state, it's kind of pointless for browsers to try to take advantage of this element when most of the real code is against the spec, I believe that it didn't help that browsers didn't do that in the beginning when nobody was using it yet. But since the spec is not explicitly asking for anything, browsers did the bare minimum.
While I can imagine 2 use cases already:
i) better layout of printed page (eg. when I try to print my blog post, firefox will happily cut a figure in half if I select print on a5 paper even though it could try to reorganize it bit smarter ...)
ii) similar to what you describe, an ability to show the figures in a separate window so that you can see the text and figures at the same time (this is actually similar to a picture-in-picture like feature for images what I describe in the blog, and to be honest I would still find that kind of useful)
And then using them becomes almost habitual.
Personally I like to use "semantically correct" tags, as that somehow feels right. But then with a CSS framework it's easier than using a "wrong" tag, which you would have to manually restyle.
What? It's easier than using custom markup that you then need to style appropriately. Why would you not use them? Why would you use <span class="small"> instead of <small>?
> the spec[1] says you should mark up a menu with this atrocity...
No it doesn't. That's a specific example of indicating keys to press in a menu. Menus generally are marked up as lists inside a nav element.
Because I can't be sure I'm using <small> correctly. The spec says "The small element represents side comments such as small print." and then says "Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements."
You know what this makes me think of? Those captions under images that says the source of the image. Like "photo by John Smith licensed under creative commons." I bet it's the wrong use for this. If it's the right use, then it's worthless either way because there will be a caption for an image in your website that doesn't have this sort of text in it, so you shouldn't use <small> for it, but you'll still want it to look like every other caption in your website, so you'll end up using a class for it anyway.
It's ironic people are relying on semantic tags for styling over classes while it's been repeated so often that semantics is not for styling.
>That's a specific example of indicating keys to press in a menu
Yes, that's what I meant. The fact that the spec implies you're supposed to write code like that God knows whom for doesn't change.
I wish someone made a list of the practical effects of using this markup. The spec is ridiculously vague about all of it to the point of being unreliable. For example, iirc <aside> gets a landmark that should only be a top landmark (like a sidebar), but the spec seems to hint you could use <aside> in the middle of a paragraph. Why would I do that when if it broke accessibility?
I also think it sucks that semantic HTML has become de facto a poorly documented accessibility API...
It's just a bunch of rules that some ivory tower people made up, which have little to no correspondence to the much more useful questions of:
- what kind of information do people wish to extract from an HTML document?
- what kind of information does accessibility software need to extract from an HTML document?
- what does the typical structure of a web page in the wild look like?
- what kind of information cannot be inferred from natural context and requires annotations?
W3 standards are, on the whole, pretty much garbage. The parts that aren't garbage are the parts that were standardized in the wild, from things people were already doing spontaneously.
Also, the entire 'semantic html' movement was mostly a fad where people who never used a screenreader gushed about how much more accessible their HTML was because it used the morally pure, new, progressive HTML tags. It was masturbation.
Everyone acted like people actually care about the HTML for the webpages they visit, but the reality is, they don't. Not even web developers. Unless they are explicitly paid to satisfy some government accessibility guidelines.