by soheilpro on 4/11/25, 2:14 AM with 264 comments
by Osmose on 4/11/25, 2:55 AM
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.
by ssl232 on 4/11/25, 7:25 AM
by ralferoo on 4/11/25, 9:01 AM
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.
by MBCook on 4/11/25, 3:16 AM
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.
by penguin_booze on 4/11/25, 6:07 AM
by superkuh on 4/11/25, 2:40 AM
by quotemstr on 4/11/25, 3:59 AM
by p4bl0 on 4/11/25, 8:44 AM
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.
by ricardobeat on 4/11/25, 6:51 AM
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.
by tony-allan on 4/11/25, 2:38 AM
by tommica on 4/11/25, 5:55 AM
by sayheytozoe on 4/12/25, 10:34 AM
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
by Ferret7446 on 4/11/25, 9:56 AM
https://www.felesatra.moe/about
The "old" behavior is great because you don't need global knowledge; you can have a snippet that gets templated into various layers and still getting the right level of heading applied.
by thund on 4/11/25, 6:37 AM
by jpc0 on 4/11/25, 8:37 AM
From the MDN docs on headings and paragraphs [0].
Yet this article is unclearly stating that it isn't preferred but required seeing as the places it semantically makes sense to use multiple H1 tags in a page will now log warnings to developers ( article, aside, nav etc .. )
The article mentions confusion yet the defacto documentation on the web encourages the confusion by not being more specific...
0. https://developer.mozilla.org/en-US/docs/Learn_web_developme...
by MyOutfitIsVague on 4/11/25, 2:28 PM
by WhyNotHugo on 4/11/25, 1:30 PM
Mainly, I'd love for pages without any CSS to render in dark mode when the system+browser are set to dark mode.
by TZubiri on 4/11/25, 2:54 AM
<section name="Animals">
<section name="Mammals"> Mammals are blabla </section>
<section name="Reptiles"> Reptiles are blabla </section>
<section name="Plants">
</section>
<section name="Minerals">
</section>
In this case Animals, Plants and Minerals would be h1, and Mammals and Reptiles would be h2. If you truly wanted to separate representation from content you would do that, as it is you are not really doing that, the h1 and h2 would be creating some kind of explicit open and close tags and hierarchy in a format different than the rest of html.
If someone goes back in time could you kick that Berner's Lee on your way back from killing hitler, correcting the sign on electricity? Thanks. Also send a message to Douglas Crockford if you've got time.
by ryao on 4/11/25, 2:10 PM
Lighthouse will flag a warning if <h1> is used without a specified font-size.
by littlestymaar on 4/11/25, 11:27 AM
Sometimes it's a necessary evil (when you have to fix a security vulnerability), but here I really fail how it was necessary.
by eek2121 on 4/11/25, 12:56 PM
I don’t want to specify styles for all my content. For some content, I want to use browser defaults.
Sure, now it is just H1, but just wait…
by mediumsmart on 4/11/25, 2:01 PM
by cassepipe on 4/11/25, 10:40 AM
I have checked the websites on CSS naked day. Default styles were ok but not great.
by blahyawnblah on 4/11/25, 7:21 AM
by successful23 on 4/11/25, 6:19 AM
Dropping the UA styles makes things more predictable: <h1> means <h1>, no matter where it lives. Yeah, the partial rollout across browsers is going to be rough - debugging across inconsistent browser behavior is going to be a nightmare. Still, if this pushes devs to rely less on implicit styling and more on their own structure, they can now take control of heading semantics more properly.
by dimava on 4/11/25, 6:31 PM
They are changing to
x h1 { warning: semantically questionable }
/* where x is :is(article, aside, nav, section) */
x h1 { font-size: h2 }
x x h1 { font-size: h3 }
x x x h1 { font-size: h4 }
So anyone who doesn't place H1s where they shouldn't have been anyways is fine
by bslalwn on 4/11/25, 8:27 AM
by JohnHaugeland on 4/11/25, 9:34 AM
by codedokode on 4/11/25, 2:37 AM
What an awful idea. How is a web developer supposed to test the website when he and user might have different browser behaviour? It looks like someone read about deployment at Facebook and wanted to implement the same thing without any valid reason. Firefox is not a server-side software and this style of deployment doesn't make much sense.
by donnachangstein on 4/11/25, 7:18 AM
<checks Bugzilla>
Nope, my two year old bug is still being ignored.
by russellbeattie on 4/11/25, 4:57 AM