Ask HN: Who is consuming all these semantic HTML tags?
44 comments
HTML is one of those things that sounds easy to write, except almost nobody knows how to do it or why they should. At best people are super ecstatic when they can figure out how to make it visually pleasing.
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.
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.
I've always felt the main use case of HTML is for a single page document, like PDF. When it's for that, it excels at what it does. But when you have a website with multiple pages where 90% of the HTML is copy pasted from the rest, it just stops making sense. So for most of HTML's life, we've used the wrong tool for the job, but because it was the only tool we had, we used it anyway.
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.
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.
> But when you have a website with multiple pages where 90% of the HTML is copy pasted from the rest, it just stops making sense
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.
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.
the author wasn't saying this can't be managed by tools, I believe they're saying its kinda insane that we have tools to automatically assemble huge stacks of html on the server, very little of which is different each time, then send the whole glob over to the user.
and that ideally it would be supported natively in the language rather than requiring find-and-replace tooling
and that ideally it would be supported natively in the language rather than requiring find-and-replace tooling
Yes, I forgot to include it in the original comment, but besides frames and AJAX we also have static site generators, from no-code stuff like Frontpage all the way to Hugo, and server-side templating like PHP, Jinja, etc.
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...)
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...)
Content is just text, a more expressive form of raw data. It's the organization and description of that data which makes it useful. For example steps in a set of instructions are less valuable than the instructions as a whole when clearly organized as a series of steps. This remains true regardless of the context, format, or means of conveyance.
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.
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 understand, but by this logic, no technology matters so long as it gets the pixels on the screen, because that's what the user ultimately sees. In that case, why even use HTML at all? Just upload a huge JPEG that looks like a page and call it a day.
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.
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.
A dynamic document format outgrew it's use case as a document format.
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.
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.
That depends on how you define a user. In many cases this is too narrowly defined to a specific subset of visual users only and thus may present output that legally qualifies as discriminatory in many jurisdictions. What matters is not what is visually viewed according to a tracking metric but what is cognitively consumed by the intended audience such that it results in dedicated engagement or interaction.
Again, whether or not HTML outgrew its business case is irrelevant to whether it is properly deployed to its consuming audience.
Again, whether or not HTML outgrew its business case is irrelevant to whether it is properly deployed to its consuming audience.
The giant frameworks are used because so much of what we're doing is apps. Imperative stuff sucks once you've tried declarative.
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.
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.
The giant frameworks are used solely for employers to ease candidate selection and not have to invest in training. The only business goal is to put dynamic text on screen. Many developers naively believe these frameworks are there to empower them without realizing they have become commodities or that they are unemployable and hopelessly incompetent without complete reliance upon these frameworks.
You might have a point, but if the frameworks didn't exist, couldn't employers commoditize around knowledge of the base HTML?
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.
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.
No, absolutely not. Web technologies are now well described and well formalized, but they are built upon extremely sloppy foundations. This results in multi-paradigm technologies that work extremely well and play well together, but architecturally and stylistically are all over the place. Worse, most people are not formally educated to execute on these technologies and simply guess at correctness. If you are both smart and well experienced that expressive flexibility is not an impediment at all, you can independently find correctness through independent research and experience, but most people lack both the intelligence and experience necessary to overcome this hurdle.
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.
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.
What is the "great expense"?
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.
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.
Yes, if you read how certain tags are actually intended/supposed to be used, you realize that semantic HTML is mostly nonsense. You can't extract a list of articles from a page by looking for `<article>` tags, because there are all sorts of other 'acceptable' uses, none of which any web developer in the wild actually knows, let alone applies rigorously.
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.
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.
Blind people depend on them. They tend to be used more (by web devs) than ARIA properties, IIRC, so I'm told it helps a lot.
Some of them have default ARIA settings which I can understand, but others (like <mark>) don't seem to come with any.
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...
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...
> 1. <figure> and <figcaption>
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.
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.
I'm sorry for what I'm going to tell you, but this is exactly the sort of wrong use of the <figure> tag I mentioned about. In fact, your blog contains the PERFECT example of WRONG use of the <figure> tag, which illustrates why <figure> semantics are a lost game at this point.
The spec explicitly notes:[1]
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...
The spec explicitly notes:[1]
>When a figure is referred to from the main content of the document by identifying it by its caption (e.g., by figure number), it enables such content to be easily moved away from that primary content, e.g., to the side of the page, to dedicated pages, or to an appendix, without affecting the flow of the document.
>
>If a figure element is referenced by its relative position, e.g., "in the photograph above" or "as the next figure shows", then moving the figure would disrupt the page's meaning. Authors are encouraged to consider using labels to refer to figures, rather than using such relative references, so that the page can easily be restyled without affecting the page's meaning.
>I was familiar with it’s interface from few screenshots like the one shown below
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...
Oh, you are indeed right about the figure element! Sorry for missing your point at first.
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)
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)
All of this is part of the semantic web quagmire. To make web pages machine readable. I.e parseable in an unambiguous way. It never caught on because it is trivial to parse web pages anyway and if you wanted something machine readable, you'd publish your data in json or something. But it's proponents haven't given up yet and are still working on making the web truly semantic.
Great question. When the "Semantic Web" hype train rolled through back in the day, I asked the same question. I got a lot of hand-wavey answers about search engine understanding semantics of markup. Also if you use <b> instead of <strong> you are a barbarian.
In theory, more information would be easier for a language model to extract meaning from though.
In theory, more information would be easier for a language model to extract meaning from though.
Funny you mention that. I'm writing a plugin to replace Wordpress default markup for the ITALIC button, BOLD button and UNDERLINE button to <i>, <b>, and <u>, instead of the nonsensical <em>, <strong>, and <span style="text=decoration: underline"> it has by default.
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.
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.
Just keep in mind that this will flag content on accessibility scans.
What does this mean? What are accessibility scans, and why are they flagging content?
Accessibility is a legal requirement in some jurisdictions.
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.
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 far as I know screen readers don't seem to differentiate between <em>, <strong>, <b> or <i>[1]. If the checker flags this despite there being no actual effects in the real world, it would really make me doubtful about its accuracy...
>Mainstream screen readers currently treat B/I tags identically to STRONG/EM tags. That is, they are ignored unless a user specifies that they be indicated. Some users report that announcing changes can be distracting.
That page also lists examples of semantic and visual uses of bold and italics, which sound pretty reasonable to me.
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.
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.
"em" and "strong" are locale and medium neutral ways to signal intent. For example, most non-Latin scripts don't have an italic form, but rather use a different mechanism to signal emphasis. As well, screen readers and even high-contrast views may not work well with such things as italic and bold, and need a different mechanism to signal emphasis and strong.
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.
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.
I understand, but honestly this is really not my problem. That's the problem of someone reading and writing non-Latin scripts. In my Latin scripts, I see bold and italic and underline all the time and obviously I need a way to mark these, since they have very well-defined textual semantics in the kind of script I'm working with. If these semantics don't apply to Japanese, for example, then just don't use <b> and <i> in Japanese? Make a <傍点> or <sideline> tag for Japanese that shows up in the Japanese version of Wordpress and other CMS's.
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.
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.
As a (relatively, though age is catching up with my vision, admittedly) able-bodied Westerner who reads no other languages than English, I find this opinion shocking. Would paraphrasing your point as, "I don't think anyone who reads in any way other than the one I'm familiar with deserves knowledge," have a different impact, or does that seem ok to you, too?
No. The correct paraphrase would be "I think you should recognize that text is different from speech and English is different from Japanese and welcome the diversity of media of knowledge instead of trying to make an one-size-fits-all solution for every method to convey information that the human body is capable of."
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.
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.
Changing the context to voice markup doesn't in any way change or address the core point, which is that you really seem to be expressing that you only care about the way that you happen to consume text and therefore any other viewpoints are superfluous. Also that you're willing to go out of your way to create and publish a plugin to effectively sabotage anyone trying to do anything else.
Of all the opinions someone could hold strongly, that's certainly one of them.
Of all the opinions someone could hold strongly, that's certainly one of them.
>you really seem to be expressing that you only care about the way that you happen to consume text
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.
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.
> I don't want <em> or <strong>, and I don't want a "bring attention to" element". I want bold.
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?
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?
The problem is that you're trying to come up with a reason for the text to be bold. The reason the text is bold is simply because the writer wanted bold text. Bold is the tool and the tool that the writer chose was bold, specifically.
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!
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!
OK, now I can see that there could be e.g. a two-word brand name, where one of the words is simply bolder than the other, as a purely visual effect.
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.
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.
>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>?
So, why couldn't they do that with <b> and <i>?
Imagine writing code that outputs to HTML for your company. They require support for emphasizing some words, so you use the i and b tags.
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.
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.
Indeed that's what comes to mind: it would make you life a bit easier if you're trying to do web scraping with content analysis. And that's what search engines are, I suppose.
CSS frameworks like Bootstrap provide nice default styles for many of those semantic tags, that convey their meaning.
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.
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.
> it's hard to see a point in bothering with all these tags at all
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.
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.
>Why would you use <span class="small"> instead of <small>?
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.
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 think you're overthinking this. Use <figcaption> for captions and <small> for the small print:
<figure>
<img src="johnsmith.jpg" alt="John Smith">
<figcaption>
photo by John Smith.
<small>Licensed under a Creative Commons Attribution-ShareAlike...</small>
</figcaption>
</figure>
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:
Because if nobody is consuming these, it's hard to see a point in bothering with all these tags at all. I know for a fact Wordpress and many other CMS's just wrap every image in a <figure> which goes against the spec, so I assume whoever tried to consume that to make figures go into a sidebar or something probably just gave up because the markup of most the web is wrong, but what about the rest? Because, I don't know if you've seen this, but the spec[1] says you should mark up a menu with this atrocity:
<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