[HN Gopher] Ask HN: Who is consuming all these semantic HTML tags?
___________________________________________________________________
Ask HN: Who is consuming all these semantic HTML tags?
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
Author : AlienRobot
Score : 7 points
Date : 2023-12-04 19:05 UTC (3 hours ago)
| redavni wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 <Bang Dian > 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.
| LukeBMM wrote:
| 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?
| AlienRobot wrote:
| 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.
| LukeBMM wrote:
| 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.
| austin-cheney wrote:
| 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 wrote:
| 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.
| austin-cheney wrote:
| 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.
| AlienRobot wrote:
| 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.
| austin-cheney wrote:
| 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.
| marbu wrote:
| > 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.
| AlienRobot wrote:
| 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...
___________________________________________________________________
(page generated 2023-12-04 23:02 UTC)