Default styles for h1 elements are changing

Some fun historical context behind the outline algorithm and why it didn&#x27;t catch on: <a href="https:&#x2F;&#x2F;www.w3.org&#x2F;Bugs&#x2F;Public&#x2F;show_bug.cgi?id=25003" rel="nofollow">https:&#x2F;&#x2F;www.w3.org&#x2F;Bugs&#x2F;Public&#x2F;show_bug.cgi?id=25003</a><p>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.

Related to this, does anyone know why &lt;h5&gt; and &lt;h6&gt; are smaller than &lt;p&gt; by default? I asked this on Stackexchange years ago and didn’t really get to the bottom of it: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;55696808&#x2F;why-do-h5-and-h6-have-smaller-font-sizes-than-p-in-most-user-agent-default" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;55696808&#x2F;why-do-h5-and-h...</a>.

Stuff like &quot;Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of &lt;h1&gt;s without defined font-size as bad practice.&quot; make me pretty certain this is the wrong change to make.<p>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.<p>As a reader, I don&#x27;t want page authors to start hard coding sizes into these elements, because then they&#x27;ll be more likely to choose non-default values to make their page stand out a bit more.<p>Additionally, the current behaviour (which I&#x27;d never particularly considered before) sounds entirely reasonable - if I take some existing markup and blockquote it in some container, I&#x27;d expect the headings to shrink as they&#x27;re now all sub-elements of some other section.

When did that H1 behavior become part of the spec?<p>I’ve been writing HTML since around ‘95 and don’t remember ever hearing of it before.<p>I suspect it would confuse the hell out of me if I had run into it. Sounds like a good thing to remove.

So many words but no example screenshot showing what the changes might look like?

Good. &lt;h1&gt; tag should be &lt;h1&gt; no matter where it is. It shouldn&#x27;t change; at least not by default. Even better that this change back to the old way will fix a problem for accessibility for screen readers.

It&#x27;s a shame that the outline algorithm didn&#x27;t succeed. Why <i>shouldn&#x27;t</i> we be able to compose content from different sources arbitrarily? Why shouldn&#x27;t I be able to write an &lt;h1&gt; fragment and have it mean &quot;top-level heading OF MY CONTEXT&quot; instead of making an assertion about global document context that I can&#x27;t control?

Seems like the proper fix would be to introduce a &lt;h&gt; element with heading level dictated only by the number of &lt;section&gt; nesting. But it&#x27;s too late for that now I guess.<p>Anyway, I&#x27;m quite surprised to learn all this about &lt;h1&gt; while I&#x27;ve always read everywhere up until today and including on MDN (Mozilla&#x27;s documentation), that one should use only one &lt;h1&gt; per page.<p>Now I wonder if and how &lt;section&gt; nesting affects &lt;h2&gt;, &lt;h3&gt;, etc.

Keeping track of heading levels across sections and components is a challenge, rarely taken care of in most websites.<p>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.

I haven&#x27;t really thought about sectioning elements (&lt;section&gt;, &lt;aside&gt;, &lt;nav&gt;, and &lt;article&gt;) and the cool behaviour of a tag like &lt;h1&gt; when these tags are nested.

Huh, the change seems reasonable, though changing defaults is always going to create friction. I always thought H1 looked the same no matter what context.

I seem to remember that when the HTML5 spec was being defined, there was an idea to use `hgroup` to offer something similar where you could re-use an `h1` later in the page to mean “this is the heading of this bit”, and it would be smaller than the `h1` outside of the group. I think because at the same time things like `article` and `section` were being added, it was decided it was too confusing. I just checked back and looks like `hgroup` ended up being used to gather a subtitle (as a `p`) with an `h1`, which I didn’t know until today and will be using!<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTML&#x2F;Reference&#x2F;Elements&#x2F;hgroup" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTML&#x2F;Reference&#x2F;...</a>

Wow, this will actually break my site.<p><a href="https:&#x2F;&#x2F;www.felesatra.moe&#x2F;about" rel="nofollow">https:&#x2F;&#x2F;www.felesatra.moe&#x2F;about</a><p>The &quot;old&quot; behavior is great because you don&#x27;t need global knowledge; you can have a snippet that gets templated into various layers and still getting the right level of heading applied.

Interesting stuff, great for Accessibility! Maybe some screenshots could have made the article more... accessible.

&gt; Preferably, you should use a single &lt;h1&gt; per page—this is the top level heading, and all others sit below this in the hierarchy<p>From the MDN docs on headings and paragraphs [0].<p>Yet this article is unclearly stating that it isn&#x27;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 .. )<p>The article mentions confusion yet the defacto documentation on the web encourages the confusion by not being more specific...<p>0. <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn_web_development&#x2F;Core&#x2F;Structuring_content&#x2F;Headings_and_paragraphs#" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn_web_developme...</a>

Are there any other elements that change their styling based on position in the document? I&#x27;ve been doing web development for over a decade and I&#x27;ve never even known about this behavior. Seems like a bad default, and I&#x27;m not bothered seeing it go away.

If we&#x27;re making breaking changes to the default CSS styles, I wish we&#x27;d include default styles for dark mode as well.<p>Mainly, I&#x27;d love for pages without any CSS to render in dark mode when the system+browser are set to dark mode.

I always thought the headers in html were kind of dumb. I always think of book sections as:<p>&lt;section name=&quot;Animals&quot;&gt;<p><pre><code> &lt;section name=&quot;Mammals&quot;&gt; Mammals are blabla &lt;&#x2F;section&gt; &lt;section name=&quot;Reptiles&quot;&gt; Reptiles are blabla &lt;&#x2F;section&gt; </code></pre> &lt;&#x2F;section&gt;<p>&lt;section name=&quot;Plants&quot;&gt;<p>&lt;&#x2F;section&gt;<p>&lt;section name=&quot;Minerals&quot;&gt;<p>&lt;&#x2F;section&gt;<p>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.<p>If someone goes back in time could you kick that Berner&#x27;s Lee on your way back from killing hitler, correcting the sign on electricity? Thanks. Also send a message to Douglas Crockford if you&#x27;ve got time.

Am I the only one who had no idea that these sectioning elements existed?<p><pre><code> Lighthouse will flag a warning if &lt;h1&gt; is used without a specified font-size. </code></pre> This seems like a silly warning to give if there are no sectioning elements affecting &lt;h1&gt;.

Breaking change to a platform that is ubiquitous like the web are always evil.<p>Sometimes it&#x27;s a necessary evil (when you have to fix a security vulnerability), but here I really fail how it was necessary.

Terrible idea. Why is it that all the big browser makers are doing stupid stuff?<p>I don’t want to specify styles for all my content. For some content, I want to use browser defaults.<p>Sure, now it is just H1, but just wait…

fwiw ... to test the site you can load and read it on a desktop and on a phone. if it also passes the validator and jslint without error or warning you are half done. It should load within 1 second on mobile (pagespeed) have zero errors on wave webaim, A+ on securityheaders.com, and full marks on webbkoll.5july.net, a proper dmarc reject entry and pass dr-dsgvo webcheck. That would be a good start. Oh, and no divs. Not allowed ...

I wish browser embedded something like PicoCSS so that you when you would ship a pure html website where you don&#x27;t care about the styling, you&#x27;d let the browser figure out styles based on the semantics. You choose from a variety of themes and tweak them.<p>I have checked the websites on CSS naked day. Default styles were ok but not great.

I&#x27;ve always been under the impression that there was only one &lt;h1&gt; per page

Honestly, this feels like a long-overdue cleanup. The outline algorithm always sounded good on paper, but in practice, it just created confusion - especially when different tools and screen readers treated headings differently.<p>Dropping the UA styles makes things more predictable: &lt;h1&gt; means &lt;h1&gt;, 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.

tl;dr for those who didn&#x27;t read the actual article:<p>They are changing to<p><pre><code> x h1 { warning: semantically questionable } </code></pre> from<p><pre><code> &#x2F;* where x is :is(article, aside, nav, section) *&#x2F; x h1 { font-size: h2 } x x h1 { font-size: h3 } x x x h1 { font-size: h4 } </code></pre> which was removed from spec in 2022<p>So anyone who doesn&#x27;t place H1s where they shouldn&#x27;t have been anyways is fine

Does this mean there are people out there who don&#x27;t use a reset.css stylesheet? I find that to be spooky.

ah, that mozilla commitment to unnecessary changes and backwards breakage

&gt; The plan is to roll out to 5% of users on the Firefox 138 stable release, ramp up to 50% of users<p>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&#x27;t make much sense.

This is great news, because it must mean all bugs in Firefox have been fixed!<p>&lt;checks Bugzilla&gt;<p>Nope, my two year old bug is still being ignored.

Craziness like this is why many designers say screw it and use &lt;div&gt;s for everything. Make sure to use the role attribute and it&#x27;s even accessible.