5 ms·

Ask HN: Who is consuming all these semantic HTML tags?

28 points by AlienRobot 3y ago

HTML5 introduced a bunch of "semantic" HTML tags to markup content. To this day I still haven't figured out what are the practical implications of using them at all, so I've come here ask. 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> 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

redavni 3y ago
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.
- ichik 3y ago
  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.
- AlienRobot 3y ago
  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.
  - kstenerud 3y ago
    "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.
    - AlienRobot 3y ago
      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.
austin-cheney 3y ago
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.
- AlienRobot 3y ago
  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.
marbu 3y ago
> 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 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/figure 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/ 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.
- AlienRobot 3y ago
  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] >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. 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: >I was familiar with it’s interface from few screenshots like the one shown below 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#the-figure-element https://html.spec.whatwg.org/multipage/grouping-content.html...
TomaszZielinski 3y ago
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.
bjourne 3y ago
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.
perilunar 3y ago
> 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.
- AlienRobot 3y ago
  >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.
  - perilunar 3y ago
    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>
1attice 3y ago
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.
- AlienRobot 3y ago
  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...
unconed 3y ago
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.

eternityforest 3y ago

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.

austin-cheney 3y ago
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.
- NAHWheatCracker 3y ago
  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.
  - austin-cheney 3y ago
    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.
    - eternityforest 3y ago
      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.

TomaszZielinski 3y ago
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.
- AlienRobot 3y ago
  >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>?
  - cxr 3y ago
    > Can you say that EVERY SINGLE TIME I want bold text that will match the semantics of <strong>?
    - AlienRobot 3y ago
      Good argument, ignoring what occurred in practice. 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.
      - cxr 3y ago
        > In other words, there is no reason to use or have made <strong>, since the end result was just <b> again 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?