Posted by soheilpro 2 days ago
In short, the W3C adopted it because they thought it was a good idea, while browsers and screen readers both refused to adopt it for various reasons like ambiguity with existing web content or concerns about screen readers having to implement and maintain their own independent outline algorithm implementations. 8 years and an entire standards organization after the thread above, the WHATWG finally dropped it.
I wish there was a neutral <h> element that could then be specified at an arbitrary <h~n~> sometimes I have documents that have headings 8 levels deep.
It's like if you removed relative paths and working directories from all OSes. A lot of things become really annoying to do.
[1] https://www.smashingmagazine.com/2011/11/our-pointless-pursu...
[2] https://www.smashingmagazine.com/2011/11/pursuing-semantic-v...
I'm not going to lie, I don't have a lot of faith in the people making markup decisions for HTML these days. It was obvious that none of these tags made any sense and anyone who knows what semantics mean knows they would get semantically bleached the instant they hit end users. Wordpress still uses B and I buttons for <em> and <strong>. That's never going to change because emphasis and strong are just not a thing that users understand so it can't be on the UI. In fact, I don't even understand the difference between the documentation fails to explicitly assert it. Screen readers and web browsers render them the same way as <b> and <i>. At this point I have to wonder for whom exactly what this markup created, and what problem did it seek to solve. I have no idea what was going on with the committee to take years of <h1> and <h2> meaning completely different things and think "what if <h1> meant the same thing as <h2> sometimes if it's in a <section>?" or "what if we <h3> didn't mean <h3> when it's in a <hgroup>?" This was a great place to introduce an <h> tag. Did they just want to avoid breaking backwards compatibility while at the same time not caring about it? I just don't understand...
Meanwhile everybody from users, to search engines, to social media platforms, to forums, to article writers are still waiting for a <spoiler>.
So you could use b in something like UI breadcrumbs, but of you wanted to strongly highlight something as an author of some text, you'd use strong.
I'm not really sure we need these though. As for my breadcrumbs example, I think everyone would use CSS rather than a b element.
So, I kinda understand the idea, but I've never needed it.
A thing that maybe comes to mind is that inner monologue in books uses italics sometimes. So using i would make sense more than em. But when wanting to emphasize/stress a word or phrase an em would make more sense than i.
+1 regarding <spoiler>!
It's not like we had decades of UI experience then, so it would surprise me if the thought process was much deeper than that.
HTML is about semantic markup, not visual markup. Features like CSS were introduced because people started trying to use the semantic markup to achieve specific visual results, and so CSS was the solution to allow HTML to continue to be semantic markup and CSS to optionally format it if people wanted specific non-default things.
As a reader, I don't want page authors to start hard coding sizes into these elements, because then they'll be more likely to choose non-default values to make their page stand out a bit more.
Additionally, the current behaviour (which I'd never particularly considered before) sounds entirely reasonable - if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
They mean h1 elements without a font-size specified in CSS (or style attribute) will be flagged as a warning. User agent styles can still override site styles if you want to set one.
> if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
This logic only applied to the h1 element specifically, as it was an attempt to shoehorn some “clever” logic from the abandoned <h> tag proposed in a early draft of HTML5 (which was going to work the way you’d describe for headings at any level), on to the existing h1 element.
(Source: I used to follow the WHAT-WG mailing list closely during the HTML5 spec development process.)
Nested H1s was never semantically correct in the first place, at least for accessibility purposes.
You can do flexible sizes without media queries (eg, viewport size units + clamp). Designers generally understand the web pretty well these days.
I only see one situation where people might have depended on these styles, but it's a big one - anywhere that you output the plain HTML of a "rich text" component from a CMS or whatever. There, if the stakes are low, it might not have been a big deal to just let the browser do it and headings might look too big sometimes now.
This is not about graceful degradation. An HTML document without any CSS should never be in a degraded state. It should be perfectly usable and perfectly well accepted.
However, if CSS specifies some things and omits others that are related to it (one example is specifying the font size for one heading level but not another one; another example is specifying the background colour without specifying the foreground colour or vice-versa), then it makes sense to be a warning.
I can't articulate it and I could very well be on the wrong vibe, but this feels like the bad practice of relying on the failure mode within a try/catch for normal functioning.
Yeah... when it was meant for documents. In practice, modern websites are not documents - at best, they have a document or a few (like an article, or a post) embedded somewhere inside something else: an application, a designed page - basically, layout and presentation but not a document. HTML was never truly designed to do anything like this and it will always remain the clay feet part of this colossus.
The reason people still use <h1> or other "semantic" tags is only because of that idea that search engines give more "weight" to text in those tags, not because they care about semantics or other formal stuff. Otherwise they would've kept slapping styled <divs>.
I have always argued that there needs to be an entirely different language for websites, something semantically closer to XUL, XAML or QML. Best we've ever got are various custom DSLs that render to HTML/CSS/JS combo, conveniently hiding the underlying mess under the rug.
The example in the article
<body> <h1>Level 1</h1> <section> <h1>Level 2</h1> <section> <h1>Level 3</h1> <section> <h1>Level 4</h1> </section> </section> </section> </body>
can become
<body> <h1>Level 1</h1> <section> <h2>Level 2</h1> <section> <h3>Level 3</h1> <section> <h4>Level 4</h1> </section> </section> </section> </body>
You forgot to include a font size in your h1's which is what people are complaining about needing to do.
> Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice.
Then when listing what to expect:
> Lighthouse will flag a warning if <h1> is used without a specified font-size.
And under the section "Fixing the Lighthouse warning":
> Lighthouse has recently inherited a check based on Chromium's DevTools warnings for sites that don't specify a font-size for <h1> elements.
Then it uses top-level h1 selectors in its examples of recommended styles. I mean you might be right about when that warning will appear, but the article doesn't seem to think you are.
I've tried to find better references, but mostly coming up with tutorial-trash and random `.edu` sites.
Menu Deprecation Notice: https://www.w3.org/TR/WD-html40-970708/appendix/changes.html
Menu Deprecated in HTML 4: https://www.w3.org/TR/html401/struct/lists.html#h-10.4
Menu Part of HTML 5 Spec: https://www.w3.org/TR/2011/WD-html5-20110405/interactive-ele...
Other Commentary: https://dpogue.ca/articles/html5-menu.html
Random bug report: https://github.com/IBMa/equal-access/issues/752#issuecomment...
> As a reader, I don't want page authors to start hard coding sizes into these elements
I also, would rather they don't hard-code sizes (and also fonts, margins, etc); use whatever size is configured in the browser which is suitable for that display and that user.
> Additionally, the current behaviour (which I'd never particularly considered before) sounds entirely reasonable - if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
Maybe. It is unclear that there should be a first-level heading inside of something else anyways.
That ship has already sailed. Whether they do it inline or through CSS, no one cares about the defaults, or your defaults. "Standing out" has been by far the biggest factor in web design ever since there was a web, and continues to drive the development of web technologies - that's because most websites are marketing products, either entirely, or in non-functional aspects (branding).
> HTML is about semantic markup, not visual markup.
Hard disagree here. HTML is too low-level to be semantic. "Separation of content and presentation" is a fundamentally flawed idea, because in many cases presentation is core to the semantics, and this is especially true for the Web, as in marketing, presentation is the content.
I remember the times when the CSS Zen Garden appeared, and everyone went on to meditate there and get high on the "separation of concerns" fumes emitted by the stylesheet selector widget. It was a great trip, but like with all such experiences, the effects are transient and don't carry to the adult reality.
Still, many a webdev tried to hold on to this ideal, many still do today. The results speak for themselves. What does "semantic HMTL" look like? A thick soup of nested divs with more or less meaningful class names, that only loosely resembles the natural structure of the content, because it's written specifically for its companion stylesheets, and only looks well with those particular stylesheets.
Here's a thought many still don't seem to realize: "semantics" in HTML isn't just about tag names, it's also about the shape of your tree. Your document isn't purely semantic, when the entire structure of the document is determined by needs of a specific presentation.
</rant>
You do have a good point about blockquotes. It's one of my main annoyances with markup / outliner formats used in many applications: they treat headline levels as absolute instead of relative, which doesn't play well with attempts at nesting documents inside documents.
In fact, to the extent HTML elements are supposed to be semantic, we shouldn't have headline levels in the first place! Instead of <h1>, <h2>, ... we should just have <header> - the headline level is implicit in the nesting anyway, and it naturally supports quoting/embedding documents in documents (and arbitrarily deep). As they are, <hN> are predominantly about presentation.
Same applies to Microsoft Word, too - the decision to have explicit named styles for headings (1 thru 9) as well as lists and others, causes problems more often than one would expect - at least for the few of us who insist on styling the document semantically, instead of applying specific looks to text by hand like most people do.
I don't think that's true or at least as strongly as you suggest. When Bootstrap first came along, all websites that used it clearly looked the same, with minor differences. We see the same today but instead of Bootstrap, people use Tailwind or other libraries/frameworks but the effect is the same, most landing pages look the same, even if the images have different colors.
Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches. Very different from the web in the 90s/early 00s, where every website worked and looked very different from each other.
There's a logic to this phenomena, and it involves few people/companies trying something new to stand out (sometimes by being flashy, sometimes by being more ergonomic or less assaulting on the senses), some others following suit, and then if that "sticks", you'll see everyone else adopting the same design too. In particular, when some design reaches enough adoption, people who don't use it start to stand out, negatively - visitors start to see them as quaint, or worse, weird and therefore untrustworthy.
(It's not a bad heuristic, either. You can avoid a lot of Internet scams if you pay attention to how the website comes across to you at a visceral level. It's kind of a "spidey sense" many of us Internet dwellers have :).)
This is not Internet-specific either, it's also a thing in branding and product design spaces in general.
> Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches.
That applies to products/services. Those tend to stand out subtler, but usually there's still a marketing department having strong influence (if not final say) on the design, and they make sure the branding is clear and the site is still easy to distinguish from any other site built with the same libraries and frameworks.
(The other category of websites is just glorified posters and magazines, and those are much weirder and unique, though even there you'll find fashion trends.)
EDIT:
The more general point is, presentation is always a core concern in commercial software, because branding is a core concern for companies. This has been true even before the Web; I recall some old UI Design Guidelines from Microsoft, IIRC for Windows 95, where this is acknowledged explicitly - the OS is pressured to provide ways to customize look&feel of UI elements, because software vendors demand it for branding, and so we can forget about having uniform UIs between applications. This is the unfortunate reality that drives UI standards.
The <header> vs <h#> decision often ends up being a flow-breaking exception in my development process.
It also bugs me that we have exactly six hardcoded heading levels. Something about that feels like it violates a deep, lizard-brain-level DRY principle.
My main concern is how well screen readers and assistive tech would handle a semantic-only approach, as the <h#> elements go all the way back to the beginning of HTML and are pretty deeply rooted in standard practices.
Completely agree. In fact, this is what auditing tools should flag.
Let HTML be HTML!
Frankly, I think that the existing algorithm sounds correct, but I could be wrong.
I’ve been writing HTML since around ‘95 and don’t remember ever hearing of it before.
I suspect it would confuse the hell out of me if I had run into it. Sounds like a good thing to remove.
[1] https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structur....
Further <h1> with only the default style SHOULD NOT BE A WARNING. At least make it only warn if 'h1's are nested.
But then screen readers universally decided that no, instead of using sections to navigate a page, they will just ignore the spec and flatten everything into the top of the hierarchy. So nobody uses them.
(And yes, it shouldn't be a warning to use an h1 in a section with the default style either. They are just making a non-backwards-compatible change to the default style, fucking own it and have the old pages change.)
Anyway, I'm quite surprised to learn all this about <h1> while I've always read everywhere up until today and including on MDN (Mozilla's documentation), that one should use only one <h1> per page.
Now I wonder if and how <section> nesting affects <h2>, <h3>, etc.
It’s a shame that we basically can’t rely on default styling to structure a simple document .
There are tons of moments in my life and in my career where I wanted to "just publish" some web page with content while not really caring for aesthetics. But even if you write semantically correct HTML without styling, what you get is not neutral and coherent as it should be, on the contrary, it’s all over the place and inconsistent.
You can define your own styles and have a similar behaviour.
Back we go to completely broken document outlines. Not that we ever fixed it in reality, as the announcement points out, but this is a big admission of defeat for the semantic web.
Essentially, it was hopeless to expect that designers would adapt their stylesheets to style headings based on the number of sections surrounding them. And if the visual styles don't adapt, nobody will use the outline algorithm to choose their headings.
(Which is sad, because the algorithm makes content nicely nestable. With the algorithm, I can take an article that was independent and use it as a section in a larger work, and the headings will automatically adapt. Though, as a pet-peeve of mine, nested IDs would also be somewhat necessary for this, so that it's fine to have two embedded articles which both have a section with an ID #introduction.)
The algorithm changed the visuals of headers used in semantics, that is, H1's in lower sections. But software beyond browsers like screen readers would need to add support for this logic too, so that H1's in a section were semantically treated as a H2.
By "outline" in this context I'm referring to the computed hierarchy of heading elements in the content. Not the styles.
What I meant is that removing the default styles is an admission of defeat, that we are giving up on the whole idea of automatically leveled headings - it's now definitely not going to be implemented by any software.