9 ms·

Default styles for h1 elements are changing

368 points by soheilpro 2y ago

TZubiri 2y ago
[flagged]
codedokode 2y ago
> The plan is to roll out to 5% of users on the Firefox 138 stable release, ramp up to 50% of users 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.
- spcebar 2y ago
  In theory a web developer is already overriding these styles, and if they're not, they can. Default browser styles are never to be taken for granted.
  - roenxi 2y ago
    Mozilla doesn't agree with you; if they thought that was true they wouldn't do the weird phased rollout to stable. Although I agree with codedokode insofar as I don't see how the phased rollout in stable could possibly help. Hopefully they've thought of something I haven't otherwise it is silly.
  - econ 2y ago
    You shouldn't but there are many sites that assume the default font is black and the default background is white. (I'm sure I forgot to set them myself.) There are [to] many ways to set the font size. I don't even know which on is the correct choice, if there is such a thing. Maybe not trying to control it is the best approach? How can one tell?
  - rendaw 2y ago
    The fact that every webdev carries around/trades personal "reset" stylesheets to undo everything the browser does by default is insane. It really highlights the disconnect between W3C and reality.
    - ryandrake 2y ago
      I think the fact that every webdev feels the need to override the user's agent and impose their own idea of what size a H1 should be is, well, kind of imposing. I might want to make H1 be 50 point comic sans. This should not matter to the web developer.
      - TylerE 2y ago
        It matters because we’re the one that has to deal with ticket when user complains that their tweaked-to-within-an-inch-of-its life system inevitably breaks the world. The problem isn’t you per say, it’s the 5000 people that mis-follow some YouTube video because it looks cool without it actually understanding what they’re changing , how to undo it, or what the implications are.
      - codedokode 2y ago
        I don't understand how one can design a website that would survive arbitrary style changes. I think that is unrealistic, so the designer should expect all default styles to be standard. And if the user has too much free time to change the font size then it is their own problem; my suggestion is that they simply use reader mode and change the styles there. I would like to remind that some time ago browsers allowed to change the default font size; it never worked well so Opera started to scale the whole page instead. Other browsers followed it. Android browsers seem to repeat the same mistake by the way: they override developer's styles when the user changes font size in OS accessibility settings.
        ryandrake 2y ago
        I mean, it's my computer. I should ultimately be in control of how a document renders. I might need larger text due to poor eyesight, or need to use a screen reader. Or I might just be irritated that the web developer just up and decided that light gray on dark gray text looked cool (it doesn't, it barely can be read). Or I might want to scroll with my keyboard because a mouse is painful to my RSI. If I go out of the way and set up accessibility settings, I would expect all applications on my device (including the web browser) to respect those settings.
- beeflet 2y ago
  I guess you could override the styles to whatever you want to keep it consistent, and then once the update rolls out to enough users you can stop overriding the styles if you want.
  - zcorpan 2y ago
    Yes.
- wnevets 2y ago
  > How is a web developer supposed to test the website when he and user might have different browser behaviour? Any web developer that would have an issue with this is already overriding the default styling.
- ack_complete 2y ago
  Bigger problem is when users run into a problem and can't find information about it because others can't reproduce it. I ran into this when they ran an A/B test on removing the search box and it drove me crazy that no one else seemingly had the same behavior, until I found and disabled the A/B test plugin.
- foolfoolz 2y ago
  this is clearly an edge case and most (all?) modern websites will not run into any problems. this is a very reasonable change given the impact
- mmis1000 2y ago
  In practice, it's like not even one web developer would have problem. The default h1 style on web is quite disgusting in general, mostly with extremely big font size and wide padding. Made it very unusable on mobile devices. Without overriding it, you should already have problems.
- kmijyiyxfbklao 2y ago
  That situation will happen no matter how they do the release. There just has to be an easy way to tell if you have the change or not.
- rvba 2y ago
  Those in charge of Firefox / Mozilla foundation look as if they are trying to make Firefox irrelevant
- not_a_bot_4sho 2y ago
  > Firefox is not a server-side software and this style of deployment doesn't make much sense. How does safe velocity not apply to client apps? We've been doing this for decades.
  - benatkin 2y ago
    It shouldn't. It's part of an anti-feature called "studies": https://support.mozilla.org/en-US/kb/shield https://support.mozilla.org/en-US/kb/shield
    - not_a_bot_4sho 2y ago
      I'm still not following. I get studies and exp. But that's different than rolling out a default behavior to all users, which still requires safe velocity guardrails so you don't Crowdstrike yourself.
      - benatkin 2y ago
        They shouldn’t be tinkering around in my computer.
- eschaton 2y ago
  A web page’s behavior should be independent of any particular styling of the hierarchical elements used to represent the document it’s presenting. Just like any web page should work perfectly with JavaScript disabled, it should work perfectly with a user-supplied style sheet. If you’re making a web page that has this problem, what you’re making should not be a web page, and you should feel bad about the choices that led you to that point in your life. It will take a while to fix this problem in our industry since we’ve waited so long on it, but the best time to start is now.
  - grandempire 2y ago
    > Just like any web page should work perfectly with JavaScript disabled And the problem is neither of those things are true in reality. So in real life a change like this can cost the economy millions of dollars.
    - eschaton 2y ago
      Sure they are, they’re just not sexy. And making this change will ultimately save orders of magnitude more than the cost.
      - grandempire 2y ago
        There are real websites people rely on that don’t work without JavaScript - and ones that depend on the h1 size too.
        eschaton 2y ago
        And that’s a bad thing, and the people involved in making those sites should feel bad and do something about their mistakes rather than just shrug. And we should call them what they are: Mistakes, abuses of the web.
        toast0 2y ago
        Sure, the people making these things should feel bad about it, and ideally change their choices... But if 5% of Firefox users can't use your page, and your page is important, they'll consider Firefox broken and go use something else. Firefox isn't doing so well on market share, and appearing to be broken isn't going to help.
- arp242 2y ago
  > How is a web developer supposed to test the website when he and user might have different browser behaviour? So that is always going to be the case with a change like this, simply because people use older versions, use different browsers, etc. If this change breaks popular-site.com then it will continue work fine for 95% of people, and it breaks for "only" 5%, one of whom will (hopefully) report it. This allows the Firefox people to test the waters to make sure it's not going to horrible break things and break things for too many people.
  - lynx97 2y ago
    Yay, "our users are our beta-testers" hard at work. How about devs evaluate a change by doing some testing, instead of using users as guinea pigs? I agree with parent, this is an awful approach.
    - anon7000 2y ago
      The scale is far too big. You cannot take into account the millions of permutations of websites and browser extensions when testing changes like this.
    - frosted-flakes 2y ago
      They're not testing the browser, they're testing the Web. Testing in the real world with real users is the only way to adequately probe the effects of potentially breaking changes like this. This is not new either. Many such changes have been reverted after discovering that they broke more things than expected. One example is the Object.groupBy static method, which was initially Array.prototype.group.
      - lynx97 2y ago
        > They're not testing the browser, they're testing the Web. That sounds like a pretty lame excuse. So if a self-driving car manufacturer does testing, they are not testing the car, they are testing the environment? Sounds like a pretty neat trick, maybe marketing should adopt this attitude.
    - 2y ago
- deleted 2y ago
  [deleted]
- notatoad 2y ago
  if you're a web developer, it's always a good idea to keep a copy of the beta release installed to test your sites on, so you can see these changes before it hits the stable release.
  - warpech 2y ago
    What surprised me that they roll it out to 50% of the beta channel users. So you might or might not see the change until they roll it out for all
    - zcorpan 2y ago
      Good point! We've adjusted the plan so that it's 100% of beta (starting today). Thanks.
- Borgz 2y ago
  From the linked article: >To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config.
- tshaddox 2y ago
  Isn’t this how many features are rolled out for Chrome and Firefox? Chrome’s feature flag system is called Finch: https://developer.chrome.com/docs/web-platform/chrome-finch https://developer.chrome.com/docs/web-platform/chrome-finch This is a list of variations: https://chromeenterprise.google/policies/ https://chromeenterprise.google/policies/
- paulddraper 2y ago
  1. Users are already going to see different behaviors, depending on their browser version. It will have to work for both. 2. Anyone that cares a lot how h1 looks is going to set the style themselves, rather than relying on whatever the browser default happens to be. 3. Bad browser defaults have (not inaccurately) been blamed for people excessively crapping out CSS.
- ramesh31 2y ago
  Nobody tell him about the experiments tab
- jiggawatts 2y ago
  Even on the server side it can be annoying. For example, I tested something in my own private Azure Subscription, but the feature was simply missing in the customer subscription. Microsoft was enabling features randomly without even documenting this or showing any kind of user-visible indicator of what feature set was available or not.
- input_sh 2y ago
  > How is a web developer supposed to test the website when he and user might have different browser behaviour? If only there was like a Developer version, perhaps one version ahead of stable: https://www.mozilla.org/en-US/firefox/developer/ https://www.mozilla.org/en-US/firefox/developer/
  - jeroenhd 2y ago
    Firefox dev edition is nice but when changes are rolled out gradually like this, forcing the setting in about:config is the only reliable way. Firefox runs experiments on its users in dev edition as much as it does in stable.
- jeroenhd 2y ago
  In case you were actually looking for an answer to your question, it's in the article: > To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config. Gbd article doesn't specify how to test in Chrome (probably something in chrome://flags), but you can read the deprecation warnings dumped into your console. You may need to enable them in your default log level. If so, there may be a lot of other behaviour that you'll probably want to fix.
  - zcorpan 2y ago
    Chrome doesn't implement the change yet, only the deprecation warning. So you can check the console in devtools or run a Lighthouse check.
- tempay 2y ago
  From the article: > Since Firefox 136, developers will see a console warning for h1s in article/aside/nav/section without author-defined font-size or margins Seems like it should be fairly obvious for any dev that tries to look into it even if they're not part of the cohort with the new behavoir.
- zcorpan 2y ago
  To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config. Rolling out potentially risky changes in this way is not new, and is also a strategy that other browsers employ. It allows for course-correcting if necessary and is less disruptive than shipping to 100% of users directly.
- zx8080 2y ago
  For gradual feature roll out there should be a clear success or failure criteria and also the feedback loop. What are they?
  - zcorpan 2y ago
    The feedback loop is Firefox's "report broken site" in the Help menu. Success is there are no reports about broken sites due to this change, or the breakage is minor -- differently sized headings and different margins on some pages is expected and is acceptable. Sites becoming unusable is not acceptable.
- onion2k 2y ago
  Test what exactly? If your test is "The page renders how I expect when using the browser's default styling" then that's a terrible test, because that can change at any time without your control. You just have to accept what that is. There isn't a valid test for it. The fix for this is to define your own H1 margin and font size and then to test that the site looks correct with those values. Your test is should be that your styling works, not that Firefox's styling works. That'd be like testing a dependency. You shouldn't be doing that.
- donnachangstein 2y ago
  Easy, spin up 20 VMs, find the one that's different.
- badgersnake 2y ago
  Replacing doing actual testing with ‘just give it to 5% of users and see who screams’ is not an industry trend I’m on board with. Sure, it’s a lot cheaper but also, you’re supposed to ship things that actually work.
- K0nserv 2y ago
  The indignation in this thread and from OP is ridiculous, especially when all the ire is aimed at Firefox, who are doing the same thing all browser makers do. When you are changing the very fabric of the whole web, rolling things out in a gradual, controlled way is paramount. Not just because people can find and report issues before roll-out reaches 100%, but also because browsers collect telemetry on features and how they work in the wild that can be used to gauge the effect.
  - jrvieira 2y ago
    you are both right. the decision to make this change is wrong in the first place
    - diggan 2y ago
      All three of you are wrong, computers were a mistake.
      - acheron 2y ago
        In the beginning, the universe was created. This has made a lot of people very angry and is widely regarded as a bad move.
- oblio 2y ago
  How do you think the other browsers roll out changes...?
  - oblio 2y ago
    To the downvoter: they do A/B testing and staged rollouts... nobody at that scale updates 100% in one go.
- WhyNotHugo 2y ago
  Even if they rolled out to 100% of the users on day 1, you'd sill have an heterogeneous audience with all the folks using older versions of Firefox. It likely takes (at least) many months before 99% of Firefox users upgrade to a any specific release.
tony-allan 2y ago
I haven't really thought about sectioning elements (<section>, <aside>, <nav>, and <article>) and the cool behaviour of a tag like <h1> when these tags are nested.
- pests 2y ago
  Well it’s getting removed so only useful if you want to recreate the css they are removing.
  - tony-allan 2y ago
    Oops. Perhaps I need to read the article again!
- radicalriddler 2y ago
  Validation tools will also tell you if you have an H1 in a <section>, but no H1 outside of the section, because the <section> actually creates it's own scope, thus your page has no H1.
  - ricardobeat 2y ago
    Looks like that kind of validation was premature. They mention in this article that the “creates its own scope” part was never actually implemented for accessibility, this change brings the display rules back inline with reality.
    - radicalriddler 1y ago
      Nice, I didn't know that. The difference between W3C and what browsers actually implement, if you don't laugh, you'll cry.
superkuh 2y ago
Good. <h1> tag should be <h1> no matter where it is. It shouldn'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.
- mjevans 2y ago
  I agree with this. Further <h1> with only the default style SHOULD NOT BE A WARNING. At least make it only warn if 'h1's are nested.
  - sfink 2y ago
    The article seemed to repeatedly suggest that any <h1> without a font size set would be a warning, but reading more closely I'm pretty sure it's only talking about <h1> nested within <section> etc. (So I believe Lighthouse and Firefox are both already doing what you describe in the last sentence.)
    - alexpetros 2y ago
      I'd love the article to clarify this, because it stuck out to me as well. But as you pointed out, I think that's what they meant: the lighthouse warning is called "H1UserAgentFontSizeInSection"
    - mjevans 2y ago
      I still think even one within a section (or even div like nested sections) shouldn't be a warning... but I hadn't heard of <section> until today (seemingly it's been in browsers for decades, I just hadn't seen it USED anywhere) so I'm not sure if that implies something other than a logical structural block. From the context it seemed like a different type of div or span.
      - Cthulhu_ 2y ago
        "decades" I had to look it up, it's been 15 years apparently, with HTML5 being 17 years old... I quipped to my colleague that I'm still stuck at XHTML. Mind you, that's also because in 2008 we still had to support Internet Explorer 6.
TZubiri 2y ago
I always thought the headers in html were kind of dumb. I always think of book sections as: <section name="Animals"> <section name="Mammals"> Mammals are blabla </section> <section name="Reptiles"> Reptiles are blabla </section> </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.
- mikepurvis 2y ago
  I dunno about this. Attributes are supposed to be metadata, not displayed textual content. Like it's fine to give the anchor for a section as an attr: <section id="animals"> <h2>Animals</h2> <p>Here are my animal facts</p> </section> I would feel strange if a browser's built in CSS were reaching into an element's attribute and rendering the text therein as something visible to the reader.
  - flowerthoughts 2y ago
    I don't think that matters to GP's point. It's the fact that then "name" attribute stays the same no matter the nesting level. There's already <figure><figcaption></figure> and <table><caption></table> as examples of embedded heading. The difference there being that figure and table elements very rarely nest. So allowing h in <section><h><section><h></section></section> to become h1 and h2 would make sense.
  - paulddraper 2y ago
    <input type="button" value="Submit">
    - Skeime 2y ago
Osmose 2y ago
Some fun historical context behind the outline algorithm and why it didn't catch on: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 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.
- skerit 2y ago
  I thought it was a good idea and liked using it. I do not see how the old "global" h1, h2, h3... system we still have to use is any better.
  - mvdtnz 2y ago
    It's better because it's explicit. That's it.
    - qw 2y ago
      I would prefer to use a neutral <h> tag, that was proposed in the xhtml2 specs. It always made more sense to let the browser infer the place in the hierarchy.
      - dspillett 2y ago
        I've seen this done with one of the existing tags and appropriate nesting. <h1> for masthead, <h2> for major subdivisions in a huge page (essentially sub-mastheads), then <h3> for everything else with styling (and nesting in ToCs and such) being dictated either by how nested they are in <section> tags (or <div>s with an appropriate class). H3 here becomes a neutral header, and h4+ are just not used (nor is H2 in short/medium pages).
        Popeyes 2y ago
MBCook 2y ago
When did that H1 behavior become part of the spec? 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.
- jeroenhd 2y ago
  AFAIK it's one of those W3C versus WHATWG/browser vendor things. The spec has an algorithm, no browser actually implements it faithfully, and when browsers were still competing with each other nobody was going to break half the web to be spec compliant. The problem started decades ago (https://html5accessibility.com/stuff/2022/04/05/12-years-beyond-a-html-joke/ https://html5accessibility.com/stuff/2022/04/05/12-years-bey...).
  - currysausage 2y ago
    If I remember correctly, W3C’s XHTML2 working group wanted a generic <h> tag [1], and WHATWG, focused on evolving HTML in a backwards-compatible manner, repurposed <h1> as a context-dependent heading tag instead. [1] https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structural.html#sec_8.5 https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structur....
- zcorpan 2y ago
  It has been in the spec since 2009: https://github.com/whatwg/html/commit/0ed655652d52f0ab068fcb2003ffcd1b6bbed249 https://github.com/whatwg/html/commit/0ed655652d52f0ab068fcb...
- _joel 2y ago
  Perhaps to address screen-readers and broken semantics of a page?
- GavinAnderegg 2y ago
  It changed with the introduction of HTML5. It was one of those ideas that’s great for spec nerds, but flew in the face of previous standards compliance. It’s something I used on a lot of sites in the 2010s, but that I no longer have access to change. I’m betting this will make some old sites built by standards fiends look weird in spots, but not break things too badly. https://mattryall.net/blog/html-5-headings-and-sections https://mattryall.net/blog/html-5-headings-and-sections
quotemstr 2y ago
It's a shame that the outline algorithm didn't succeed. Why shouldn't we be able to compose content from different sources arbitrarily? Why shouldn't I be able to write an <h1> fragment and have it mean "top-level heading OF MY CONTEXT" instead of making an assertion about global document context that I can't control?
- zarzavat 2y ago
  The outline algorithm didn't succeed because it was too complicated and hard to understand for the common case. You can define your own styles and have a similar behaviour.
- teo_zero 2y ago
  While I agree on hierarchical headings, I don't think H1...H6 are the right tools. These represent absolute levels, we would need a means to express "level+1". I think a H tag with no digit would better convey the meaning "heading of the right level as defined by the surrounding SECTION tags".
  - lblume 2y ago
    But they don't have to represent absolute levels. They could just as easily have represented relative levels, with h2 in a doubly nested section to describe the level today expressed as h4. Dependent on your usecase, this could either be very useful or just mess up your styles a lot.
  - pjerem 2y ago
    Well I totally agree with you but we don’t have that. h1 was that, but not anymore. 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.
  - brewmarche 2y ago
russellbeattie 2y ago
Craziness like this is why many designers say screw it and use <div>s for everything. Make sure to use the role attribute and it's even accessible.
babhinav 2y ago
[dead]
tommica 2y ago
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.
penguin_booze 2y ago
So many words but no example screenshot showing what the changes might look like?
- zcorpan 2y ago
  Good point. Now fixed!
  - leakycap 2y ago
    The screenshots helped me understand it... turns out the "change" will work how my brain already thought it worked.
successful23 2y ago
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. 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.
thund 2y ago
Interesting stuff, great for Accessibility! Maybe some screenshots could have made the article more... accessible.
- zcorpan 2y ago
  Fixed, thanks.
ricardobeat 2y ago
Keeping track of heading levels across sections and components is a challenge, rarely taken care of in most websites. 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.
- Cthulhu_ 2y ago
  ? No, this removes some magic default behaviour; if the outline is broken, the website you're viewing uses default styles and relies on behaviour that was removed in 2022. It's better to take ownership of styling instead of relying on defaults, this has been true since... the 90's? 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.
  - ricardobeat 2y ago
    > if the outline is broken, the website you're viewing uses default styles and relies on behaviour that was removed in 2022 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.
- Skeime 2y ago
  Trying to shoehorn this onto the existing headings was a mistake. They should have introduced a new <h> or maybe <ha> (heading-automatic) element for this. Plus, support in the form of a CSS pseudoclass like :heading(n), which matches <hn> headings and <h> elements nested in n articles/sections/..., would have been great. 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.)
donnachangstein 2y ago
This is great news, because it must mean all bugs in Firefox have been fixed! <checks Bugzilla> Nope, my two year old bug is still being ignored.
- zuhsetaqi 2y ago
  So your assumption is that non bugfix changes in a software are only allowed when all bugs are fixed, or what?
- lexicality 2y ago
  Good news! Firefox is open source and you can provide your own fixes if you feel the official triage process is taking too long.
- zcorpan 2y ago
  What is your bug?
blahyawnblah 2y ago
I've always been under the impression that there was only one <h1> per page
- MindTooth 2y ago
  Yeah. Came to ask the same. Always been my understanding.
- moebrowne 2y ago
  I believe it is still best practice to have a single h1 per page but the spec allows many: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/Heading_Elements#avoid_using_multiple_h1_elements_on_one_page https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- reddalo 2y ago
  It's just a SEO "good practice", but it's perfectly fine to have more than one <h1> tag.
ssl232 2y ago
Related to this, does anyone know why <h5> and <h6> are smaller than <p> by default? I asked this on Stackexchange years ago and didn’t really get to the bottom of it: https://stackoverflow.com/questions/55696808/why-do-h5-and-h6-have-smaller-font-sizes-than-p-in-most-user-agent-default https://stackoverflow.com/questions/55696808/why-do-h5-and-h....
- schindlabua 2y ago
  Not that I would know but I'd assume it's just one of those early internet things. Like somebody decided that 6 levels of headers were good enough hence h1 through h6, and well you need to be able to distinguish them by size but also h1 shouldn't be too big so h5 and h6 being smaller than body text is a good compromise? 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.
bslalwn 2y ago
Does this mean there are people out there who don't use a reset.css stylesheet? I find that to be spooky.
jpc0 2y ago
> Preferably, you should use a single <h1> per page—this is the top level heading, and all others sit below this in the hierarchy 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_development/Core/Structuring_content/Headings_and_paragraphs# https://developer.mozilla.org/en-US/docs/Learn_web_developme...
- jillesvangurp 2y ago
  It's a weird one. HTML does have a TITLE tag. But it's supposed to go in the HEAD. The BODY does not have a TITLE. Any word processor uses something called a Title (and Subtitle) at the top of your document and then things Heading1 for sections. HTML originally didn't have dedicated tags for this; just h1-h6 (because surely six is enough for anyone). So you get this weird off by one error that arises from the notion that HTML just lacks essential tags. So you use H2 to mean Heading1. Because H1 is reserved for the title. Never mind about sub titles. Not a thing in HTML. Mostly this is because Tim Berners Lee probably didn't think this one through properly decades ago. And it was never really fixed. These days you can just invent your own tag names and style them of course. Which is a useful trick that is a bit underused. The structural semantics are nice for things like accessibility, SEO, and a few other things but otherwise HTML is a really poor choice of a format to exchange structural information. You generate it from other formats preferably. Writing it manually is a PITA. Even if you are a developer. Things like Markdown exist for a reason (and perpetuate the problem).
  - Ferret7446 2y ago
    I don't think it's fair to blame Tim Berners Lee for this. The WWW was supposed to serve documents. The TITLE would have been rendered by your browser, and in fact, it still kind of is, in the window title bar. The Web has long departed from that vision however; very few pages, if any, could still be considered documents.
p4bl0 2y ago
Seems like the proper fix would be to introduce a <h> element with heading level dictated only by the number of <section> nesting. But it's too late for that now I guess. 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.
- JohnHaugeland 2y ago
  that exists https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/header https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - p4bl0 2y ago
    I don't understand <header> to be a heading element (i.e., a section title). Instead it is a semantic container for heading elements: title, date, author, maybe category/tags, etc. To me, the heading level used inside a given <header> is a distinct, somewhat orthogonal thing (at least in how it is decided, from the nesting level or the tag name).
ralferoo 2y ago
Stuff like "Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice." make me pretty certain this is the wrong change to make. 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.
- zozbot234 2y ago
  Looks like this change only applies to literal <h1> elements, such that <h2> ... <h6> still preserve the old behavior. If so you can just use the <h2> tag in section-like contexts in place of the older <h1>, and get the same or a very similar outcome.
  - jrvieira 2y ago
    completely defeating the purpose of html semantics in the first place
    - maccard 2y ago
      Honestly that ship has long since sailed.
      - ramses0 2y ago
        There is hope! I was going to point to my favorite example of the [menu] element being deprecated, but it looks like it's been un-deprecated! 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 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 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-elements.html#menus https://www.w3.org/TR/2011/WD-html5-20110405/interactive-ele... Other Commentary: https://dpogue.ca/articles/html5-menu.html https://dpogue.ca/articles/html5-menu.html Random bug report: https://github.com/IBMa/equal-access/issues/752#issuecomment-1088926294 https://github.com/IBMa/equal-access/issues/752#issuecomment...
JohnHaugeland 2y ago
ah, that mozilla commitment to unnecessary changes and backwards breakage
- K0nserv 2y ago
  All browser makers are making the change together, why are your singling out Mozilla?
  - zcorpan 2y ago
    Someone has to be first. :-)
Ferret7446 2y ago
Wow, this will actually break my site. https://www.felesatra.moe/about 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.
- pyinstallwoes 2y ago
  Yeah exactly. It makes a lot more sense to treat headers automatically.
- zcorpan 2y ago
  It only worked visually. For screen reader users, all headings are level 1. If you switch to using h2 etc, it will be more accessible.
  - Ferret7446 2y ago
    That's a problem with the screen reader implementation. At least, according to the previous semantics.
    - AlienRobot 2y ago
      It was a problem with the screen reader implementation in 2009 when the semantics were introduced. In 2025 if no screen reader works right it's a problem with the spec.
    - zcorpan 2y ago
      As of 2022 (when the outline algorithm was removed from the spec), it's a problem with your website implementation.
deleted 2y ago
[deleted]
cassepipe 2y ago
I wish browser embedded something like PicoCSS so that you when you would ship a pure html website where you don't care about the styling, you'd let the browser figure out styles based on the semantics. You choose from a variety of themes and tweak them. I have checked the websites on CSS naked day. Default styles were ok but not great.
littlestymaar 2y ago
Breaking change to a platform that is ubiquitous like the web are always evil. Sometimes it's a necessary evil (when you have to fix a security vulnerability), but here I really fail how it was necessary.
eek2121 2y ago
Terrible idea. Why is it that all the big browser makers are doing stupid stuff? 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…
- MyOutfitIsVague 2y ago
  Then do so. If you want specific styles, then style your content. If you don't, then you get whatever the defaults are. I really don't think there's much worth complaining about here.
WhyNotHugo 2y ago
If we're making breaking changes to the default CSS styles, I wish we'd include default styles for dark mode as well. Mainly, I'd love for pages without any CSS to render in dark mode when the system+browser are set to dark mode.
- zcorpan 2y ago
  They do if you include <meta name="color-scheme" content="light dark"> Also see https://github.com/whatwg/html/issues/5426 https://github.com/whatwg/html/issues/5426
mediumsmart 2y ago
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 ...
ryao 2y ago
Am I the only one who had no idea that these sectioning elements existed? Lighthouse will flag a warning if <h1> is used without a specified font-size. This seems like a silly warning to give if there are no sectioning elements affecting <h1>.
- zcorpan 2y ago
  There is no warning in that case.
  - ryao 2y ago
    It is a shame the article did not explain that.
MyOutfitIsVague 2y ago
Are there any other elements that change their styling based on position in the document? I've been doing web development for over a decade and I've never even known about this behavior. Seems like a bad default, and I'm not bothered seeing it go away.
- zcorpan 2y ago
  Nested lists have 0 block-margin and different list-style-type. But that seems to be about it...
dimava 2y ago
tl;dr for those who didn't read the actual article: They are changing to x h1 { warning: semantically questionable } from /* 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 } which was removed from spec in 2022 So anyone who doesn't place H1s where they shouldn't have been anyways is fine
sayheytozoe 2y ago
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! https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/hgroup https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

368 points by soheilpro 2y ago

[flagged]

> The plan is to roll out to 5% of users on the Firefox 138 stable release, ramp up to 50% of users 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.

spcebar 2y ago
In theory a web developer is already overriding these styles, and if they're not, they can. Default browser styles are never to be taken for granted.
- roenxi 2y ago
  Mozilla doesn't agree with you; if they thought that was true they wouldn't do the weird phased rollout to stable. Although I agree with codedokode insofar as I don't see how the phased rollout in stable could possibly help. Hopefully they've thought of something I haven't otherwise it is silly.
- econ 2y ago
  You shouldn't but there are many sites that assume the default font is black and the default background is white. (I'm sure I forgot to set them myself.) There are [to] many ways to set the font size. I don't even know which on is the correct choice, if there is such a thing. Maybe not trying to control it is the best approach? How can one tell?
- rendaw 2y ago
  The fact that every webdev carries around/trades personal "reset" stylesheets to undo everything the browser does by default is insane. It really highlights the disconnect between W3C and reality.
  - ryandrake 2y ago
    I think the fact that every webdev feels the need to override the user's agent and impose their own idea of what size a H1 should be is, well, kind of imposing. I might want to make H1 be 50 point comic sans. This should not matter to the web developer.
    - TylerE 2y ago
      It matters because we’re the one that has to deal with ticket when user complains that their tweaked-to-within-an-inch-of-its life system inevitably breaks the world. The problem isn’t you per say, it’s the 5000 people that mis-follow some YouTube video because it looks cool without it actually understanding what they’re changing , how to undo it, or what the implications are.
    - codedokode 2y ago
      I don't understand how one can design a website that would survive arbitrary style changes. I think that is unrealistic, so the designer should expect all default styles to be standard. And if the user has too much free time to change the font size then it is their own problem; my suggestion is that they simply use reader mode and change the styles there. I would like to remind that some time ago browsers allowed to change the default font size; it never worked well so Opera started to scale the whole page instead. Other browsers followed it. Android browsers seem to repeat the same mistake by the way: they override developer's styles when the user changes font size in OS accessibility settings.
      - ryandrake 2y ago
        I mean, it's my computer. I should ultimately be in control of how a document renders. I might need larger text due to poor eyesight, or need to use a screen reader. Or I might just be irritated that the web developer just up and decided that light gray on dark gray text looked cool (it doesn't, it barely can be read). Or I might want to scroll with my keyboard because a mouse is painful to my RSI. If I go out of the way and set up accessibility settings, I would expect all applications on my device (including the web browser) to respect those settings.
beeflet 2y ago
I guess you could override the styles to whatever you want to keep it consistent, and then once the update rolls out to enough users you can stop overriding the styles if you want.
- zcorpan 2y ago
  Yes.
wnevets 2y ago
> How is a web developer supposed to test the website when he and user might have different browser behaviour? Any web developer that would have an issue with this is already overriding the default styling.
ack_complete 2y ago
Bigger problem is when users run into a problem and can't find information about it because others can't reproduce it. I ran into this when they ran an A/B test on removing the search box and it drove me crazy that no one else seemingly had the same behavior, until I found and disabled the A/B test plugin.
foolfoolz 2y ago
this is clearly an edge case and most (all?) modern websites will not run into any problems. this is a very reasonable change given the impact
mmis1000 2y ago
In practice, it's like not even one web developer would have problem. The default h1 style on web is quite disgusting in general, mostly with extremely big font size and wide padding. Made it very unusable on mobile devices. Without overriding it, you should already have problems.
kmijyiyxfbklao 2y ago
That situation will happen no matter how they do the release. There just has to be an easy way to tell if you have the change or not.
rvba 2y ago
Those in charge of Firefox / Mozilla foundation look as if they are trying to make Firefox irrelevant
not_a_bot_4sho 2y ago
> Firefox is not a server-side software and this style of deployment doesn't make much sense. How does safe velocity not apply to client apps? We've been doing this for decades.
- benatkin 2y ago
  It shouldn't. It's part of an anti-feature called "studies": https://support.mozilla.org/en-US/kb/shield https://support.mozilla.org/en-US/kb/shield
  - not_a_bot_4sho 2y ago
    I'm still not following. I get studies and exp. But that's different than rolling out a default behavior to all users, which still requires safe velocity guardrails so you don't Crowdstrike yourself.
    - benatkin 2y ago
      They shouldn’t be tinkering around in my computer.
eschaton 2y ago
A web page’s behavior should be independent of any particular styling of the hierarchical elements used to represent the document it’s presenting. Just like any web page should work perfectly with JavaScript disabled, it should work perfectly with a user-supplied style sheet. If you’re making a web page that has this problem, what you’re making should not be a web page, and you should feel bad about the choices that led you to that point in your life. It will take a while to fix this problem in our industry since we’ve waited so long on it, but the best time to start is now.
- grandempire 2y ago
  > Just like any web page should work perfectly with JavaScript disabled And the problem is neither of those things are true in reality. So in real life a change like this can cost the economy millions of dollars.
  - eschaton 2y ago
    Sure they are, they’re just not sexy. And making this change will ultimately save orders of magnitude more than the cost.
    - grandempire 2y ago
      There are real websites people rely on that don’t work without JavaScript - and ones that depend on the h1 size too.
      - eschaton 2y ago
        And that’s a bad thing, and the people involved in making those sites should feel bad and do something about their mistakes rather than just shrug. And we should call them what they are: Mistakes, abuses of the web.
        toast0 2y ago
        Sure, the people making these things should feel bad about it, and ideally change their choices... But if 5% of Firefox users can't use your page, and your page is important, they'll consider Firefox broken and go use something else. Firefox isn't doing so well on market share, and appearing to be broken isn't going to help.
arp242 2y ago
> How is a web developer supposed to test the website when he and user might have different browser behaviour? So that is always going to be the case with a change like this, simply because people use older versions, use different browsers, etc. If this change breaks popular-site.com then it will continue work fine for 95% of people, and it breaks for "only" 5%, one of whom will (hopefully) report it. This allows the Firefox people to test the waters to make sure it's not going to horrible break things and break things for too many people.
- lynx97 2y ago
  Yay, "our users are our beta-testers" hard at work. How about devs evaluate a change by doing some testing, instead of using users as guinea pigs? I agree with parent, this is an awful approach.
  - anon7000 2y ago
    The scale is far too big. You cannot take into account the millions of permutations of websites and browser extensions when testing changes like this.
  - frosted-flakes 2y ago
    They're not testing the browser, they're testing the Web. Testing in the real world with real users is the only way to adequately probe the effects of potentially breaking changes like this. This is not new either. Many such changes have been reverted after discovering that they broke more things than expected. One example is the Object.groupBy static method, which was initially Array.prototype.group.
    - lynx97 2y ago
      > They're not testing the browser, they're testing the Web. That sounds like a pretty lame excuse. So if a self-driving car manufacturer does testing, they are not testing the car, they are testing the environment? Sounds like a pretty neat trick, maybe marketing should adopt this attitude.
  - 2y ago
deleted 2y ago
[deleted]
notatoad 2y ago
if you're a web developer, it's always a good idea to keep a copy of the beta release installed to test your sites on, so you can see these changes before it hits the stable release.
- warpech 2y ago
  What surprised me that they roll it out to 50% of the beta channel users. So you might or might not see the change until they roll it out for all
  - zcorpan 2y ago
    Good point! We've adjusted the plan so that it's 100% of beta (starting today). Thanks.
Borgz 2y ago
From the linked article: >To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config.
tshaddox 2y ago
Isn’t this how many features are rolled out for Chrome and Firefox? Chrome’s feature flag system is called Finch: https://developer.chrome.com/docs/web-platform/chrome-finch https://developer.chrome.com/docs/web-platform/chrome-finch This is a list of variations: https://chromeenterprise.google/policies/ https://chromeenterprise.google/policies/
paulddraper 2y ago
1. Users are already going to see different behaviors, depending on their browser version. It will have to work for both. 2. Anyone that cares a lot how h1 looks is going to set the style themselves, rather than relying on whatever the browser default happens to be. 3. Bad browser defaults have (not inaccurately) been blamed for people excessively crapping out CSS.
ramesh31 2y ago
Nobody tell him about the experiments tab
jiggawatts 2y ago
Even on the server side it can be annoying. For example, I tested something in my own private Azure Subscription, but the feature was simply missing in the customer subscription. Microsoft was enabling features randomly without even documenting this or showing any kind of user-visible indicator of what feature set was available or not.
input_sh 2y ago
> How is a web developer supposed to test the website when he and user might have different browser behaviour? If only there was like a Developer version, perhaps one version ahead of stable: https://www.mozilla.org/en-US/firefox/developer/ https://www.mozilla.org/en-US/firefox/developer/
- jeroenhd 2y ago
  Firefox dev edition is nice but when changes are rolled out gradually like this, forcing the setting in about:config is the only reliable way. Firefox runs experiments on its users in dev edition as much as it does in stable.
jeroenhd 2y ago
In case you were actually looking for an answer to your question, it's in the article: > To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config. Gbd article doesn't specify how to test in Chrome (probably something in chrome://flags), but you can read the deprecation warnings dumped into your console. You may need to enable them in your default log level. If so, there may be a lot of other behaviour that you'll probably want to fix.
- zcorpan 2y ago
  Chrome doesn't implement the change yet, only the deprecation warning. So you can check the console in devtools or run a Lighthouse check.
tempay 2y ago
From the article: > Since Firefox 136, developers will see a console warning for h1s in article/aside/nav/section without author-defined font-size or margins Seems like it should be fairly obvious for any dev that tries to look into it even if they're not part of the cohort with the new behavoir.
zcorpan 2y ago
To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config. Rolling out potentially risky changes in this way is not new, and is also a strategy that other browsers employ. It allows for course-correcting if necessary and is less disruptive than shipping to 100% of users directly.
zx8080 2y ago
For gradual feature roll out there should be a clear success or failure criteria and also the feedback loop. What are they?
- zcorpan 2y ago
  The feedback loop is Firefox's "report broken site" in the Help menu. Success is there are no reports about broken sites due to this change, or the breakage is minor -- differently sized headings and different margins on some pages is expected and is acceptable. Sites becoming unusable is not acceptable.
onion2k 2y ago
Test what exactly? If your test is "The page renders how I expect when using the browser's default styling" then that's a terrible test, because that can change at any time without your control. You just have to accept what that is. There isn't a valid test for it. The fix for this is to define your own H1 margin and font size and then to test that the site looks correct with those values. Your test is should be that your styling works, not that Firefox's styling works. That'd be like testing a dependency. You shouldn't be doing that.
donnachangstein 2y ago
Easy, spin up 20 VMs, find the one that's different.
badgersnake 2y ago
Replacing doing actual testing with ‘just give it to 5% of users and see who screams’ is not an industry trend I’m on board with. Sure, it’s a lot cheaper but also, you’re supposed to ship things that actually work.
K0nserv 2y ago
The indignation in this thread and from OP is ridiculous, especially when all the ire is aimed at Firefox, who are doing the same thing all browser makers do. When you are changing the very fabric of the whole web, rolling things out in a gradual, controlled way is paramount. Not just because people can find and report issues before roll-out reaches 100%, but also because browsers collect telemetry on features and how they work in the wild that can be used to gauge the effect.
- jrvieira 2y ago
  you are both right. the decision to make this change is wrong in the first place
  - diggan 2y ago
    All three of you are wrong, computers were a mistake.
    - acheron 2y ago
      In the beginning, the universe was created. This has made a lot of people very angry and is widely regarded as a bad move.
oblio 2y ago
How do you think the other browsers roll out changes...?
- oblio 2y ago
  To the downvoter: they do A/B testing and staged rollouts... nobody at that scale updates 100% in one go.
WhyNotHugo 2y ago
Even if they rolled out to 100% of the users on day 1, you'd sill have an heterogeneous audience with all the folks using older versions of Firefox. It likely takes (at least) many months before 99% of Firefox users upgrade to a any specific release.

tony-allan 2y ago

I haven't really thought about sectioning elements (<section>, <aside>, <nav>, and <article>) and the cool behaviour of a tag like <h1> when these tags are nested.

pests 2y ago
Well it’s getting removed so only useful if you want to recreate the css they are removing.
- tony-allan 2y ago
  Oops. Perhaps I need to read the article again!
radicalriddler 2y ago
Validation tools will also tell you if you have an H1 in a <section>, but no H1 outside of the section, because the <section> actually creates it's own scope, thus your page has no H1.
- ricardobeat 2y ago
  Looks like that kind of validation was premature. They mention in this article that the “creates its own scope” part was never actually implemented for accessibility, this change brings the display rules back inline with reality.
  - radicalriddler 1y ago
    Nice, I didn't know that. The difference between W3C and what browsers actually implement, if you don't laugh, you'll cry.

superkuh 2y ago

Good. <h1> tag should be <h1> no matter where it is. It shouldn'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.

mjevans 2y ago
I agree with this. Further <h1> with only the default style SHOULD NOT BE A WARNING. At least make it only warn if 'h1's are nested.
- sfink 2y ago
  The article seemed to repeatedly suggest that any <h1> without a font size set would be a warning, but reading more closely I'm pretty sure it's only talking about <h1> nested within <section> etc. (So I believe Lighthouse and Firefox are both already doing what you describe in the last sentence.)
  - alexpetros 2y ago
    I'd love the article to clarify this, because it stuck out to me as well. But as you pointed out, I think that's what they meant: the lighthouse warning is called "H1UserAgentFontSizeInSection"
  - mjevans 2y ago
    I still think even one within a section (or even div like nested sections) shouldn't be a warning... but I hadn't heard of <section> until today (seemingly it's been in browsers for decades, I just hadn't seen it USED anywhere) so I'm not sure if that implies something other than a logical structural block. From the context it seemed like a different type of div or span.
    - Cthulhu_ 2y ago
      "decades" I had to look it up, it's been 15 years apparently, with HTML5 being 17 years old... I quipped to my colleague that I'm still stuck at XHTML. Mind you, that's also because in 2008 we still had to support Internet Explorer 6.

TZubiri 2y ago

I always thought the headers in html were kind of dumb. I always think of book sections as: <section name="Animals"> <section name="Mammals"> Mammals are blabla </section> <section name="Reptiles"> Reptiles are blabla </section> </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.

mikepurvis 2y ago
I dunno about this. Attributes are supposed to be metadata, not displayed textual content. Like it's fine to give the anchor for a section as an attr: <section id="animals"> <h2>Animals</h2> <p>Here are my animal facts</p> </section> I would feel strange if a browser's built in CSS were reaching into an element's attribute and rendering the text therein as something visible to the reader.
- flowerthoughts 2y ago
  I don't think that matters to GP's point. It's the fact that then "name" attribute stays the same no matter the nesting level. There's already <figure><figcaption></figure> and <table><caption></table> as examples of embedded heading. The difference there being that figure and table elements very rarely nest. So allowing h in <section><h><section><h></section></section> to become h1 and h2 would make sense.
- paulddraper 2y ago
  <input type="button" value="Submit">
  - Skeime 2y ago

Osmose 2y ago

Some fun historical context behind the outline algorithm and why it didn't catch on: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 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.

skerit 2y ago
I thought it was a good idea and liked using it. I do not see how the old "global" h1, h2, h3... system we still have to use is any better.
- mvdtnz 2y ago
  It's better because it's explicit. That's it.
  - qw 2y ago
    I would prefer to use a neutral <h> tag, that was proposed in the xhtml2 specs. It always made more sense to let the browser infer the place in the hierarchy.
    - dspillett 2y ago
      I've seen this done with one of the existing tags and appropriate nesting. <h1> for masthead, <h2> for major subdivisions in a huge page (essentially sub-mastheads), then <h3> for everything else with styling (and nesting in ToCs and such) being dictated either by how nested they are in <section> tags (or <div>s with an appropriate class). H3 here becomes a neutral header, and h4+ are just not used (nor is H2 in short/medium pages).
      - Popeyes 2y ago

MBCook 2y ago

When did that H1 behavior become part of the spec? 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.

jeroenhd 2y ago
AFAIK it's one of those W3C versus WHATWG/browser vendor things. The spec has an algorithm, no browser actually implements it faithfully, and when browsers were still competing with each other nobody was going to break half the web to be spec compliant. The problem started decades ago (https://html5accessibility.com/stuff/2022/04/05/12-years-beyond-a-html-joke/ https://html5accessibility.com/stuff/2022/04/05/12-years-bey...).
- currysausage 2y ago
  If I remember correctly, W3C’s XHTML2 working group wanted a generic <h> tag [1], and WHATWG, focused on evolving HTML in a backwards-compatible manner, repurposed <h1> as a context-dependent heading tag instead. [1] https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structural.html#sec_8.5 https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structur....
zcorpan 2y ago
It has been in the spec since 2009: https://github.com/whatwg/html/commit/0ed655652d52f0ab068fcb2003ffcd1b6bbed249 https://github.com/whatwg/html/commit/0ed655652d52f0ab068fcb...
_joel 2y ago
Perhaps to address screen-readers and broken semantics of a page?
GavinAnderegg 2y ago
It changed with the introduction of HTML5. It was one of those ideas that’s great for spec nerds, but flew in the face of previous standards compliance. It’s something I used on a lot of sites in the 2010s, but that I no longer have access to change. I’m betting this will make some old sites built by standards fiends look weird in spots, but not break things too badly. https://mattryall.net/blog/html-5-headings-and-sections https://mattryall.net/blog/html-5-headings-and-sections

quotemstr 2y ago

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

zarzavat 2y ago
The outline algorithm didn't succeed because it was too complicated and hard to understand for the common case. You can define your own styles and have a similar behaviour.
teo_zero 2y ago
While I agree on hierarchical headings, I don't think H1...H6 are the right tools. These represent absolute levels, we would need a means to express "level+1". I think a H tag with no digit would better convey the meaning "heading of the right level as defined by the surrounding SECTION tags".
- lblume 2y ago
  But they don't have to represent absolute levels. They could just as easily have represented relative levels, with h2 in a doubly nested section to describe the level today expressed as h4. Dependent on your usecase, this could either be very useful or just mess up your styles a lot.
- pjerem 2y ago
  Well I totally agree with you but we don’t have that. h1 was that, but not anymore. 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.
- brewmarche 2y ago

russellbeattie 2y ago

Craziness like this is why many designers say screw it and use <div>s for everything. Make sure to use the role attribute and it's even accessible.

babhinav 2y ago

[dead]

tommica 2y ago

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.

penguin_booze 2y ago

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

zcorpan 2y ago
Good point. Now fixed!
- leakycap 2y ago
  The screenshots helped me understand it... turns out the "change" will work how my brain already thought it worked.

successful23 2y ago

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. 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.

thund 2y ago

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

zcorpan 2y ago
Fixed, thanks.

ricardobeat 2y ago

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

Cthulhu_ 2y ago
? No, this removes some magic default behaviour; if the outline is broken, the website you're viewing uses default styles and relies on behaviour that was removed in 2022. It's better to take ownership of styling instead of relying on defaults, this has been true since... the 90's? 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.
- ricardobeat 2y ago
  > if the outline is broken, the website you're viewing uses default styles and relies on behaviour that was removed in 2022 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.
Skeime 2y ago
Trying to shoehorn this onto the existing headings was a mistake. They should have introduced a new <h> or maybe <ha> (heading-automatic) element for this. Plus, support in the form of a CSS pseudoclass like :heading(n), which matches <hn> headings and <h> elements nested in n articles/sections/..., would have been great. 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.)

donnachangstein 2y ago

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

zuhsetaqi 2y ago
So your assumption is that non bugfix changes in a software are only allowed when all bugs are fixed, or what?
lexicality 2y ago
Good news! Firefox is open source and you can provide your own fixes if you feel the official triage process is taking too long.
zcorpan 2y ago
What is your bug?

blahyawnblah 2y ago

I've always been under the impression that there was only one <h1> per page

MindTooth 2y ago
Yeah. Came to ask the same. Always been my understanding.
moebrowne 2y ago
I believe it is still best practice to have a single h1 per page but the spec allows many: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/Heading_Elements#avoid_using_multiple_h1_elements_on_one_page https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
reddalo 2y ago
It's just a SEO "good practice", but it's perfectly fine to have more than one <h1> tag.

ssl232 2y ago

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

schindlabua 2y ago
Not that I would know but I'd assume it's just one of those early internet things. Like somebody decided that 6 levels of headers were good enough hence h1 through h6, and well you need to be able to distinguish them by size but also h1 shouldn't be too big so h5 and h6 being smaller than body text is a good compromise? 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.

bslalwn 2y ago

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

jpc0 2y ago

> Preferably, you should use a single <h1> per page—this is the top level heading, and all others sit below this in the hierarchy 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_development/Core/Structuring_content/Headings_and_paragraphs# https://developer.mozilla.org/en-US/docs/Learn_web_developme...

jillesvangurp 2y ago
It's a weird one. HTML does have a TITLE tag. But it's supposed to go in the HEAD. The BODY does not have a TITLE. Any word processor uses something called a Title (and Subtitle) at the top of your document and then things Heading1 for sections. HTML originally didn't have dedicated tags for this; just h1-h6 (because surely six is enough for anyone). So you get this weird off by one error that arises from the notion that HTML just lacks essential tags. So you use H2 to mean Heading1. Because H1 is reserved for the title. Never mind about sub titles. Not a thing in HTML. Mostly this is because Tim Berners Lee probably didn't think this one through properly decades ago. And it was never really fixed. These days you can just invent your own tag names and style them of course. Which is a useful trick that is a bit underused. The structural semantics are nice for things like accessibility, SEO, and a few other things but otherwise HTML is a really poor choice of a format to exchange structural information. You generate it from other formats preferably. Writing it manually is a PITA. Even if you are a developer. Things like Markdown exist for a reason (and perpetuate the problem).
- Ferret7446 2y ago
  I don't think it's fair to blame Tim Berners Lee for this. The WWW was supposed to serve documents. The TITLE would have been rendered by your browser, and in fact, it still kind of is, in the window title bar. The Web has long departed from that vision however; very few pages, if any, could still be considered documents.

p4bl0 2y ago

Seems like the proper fix would be to introduce a <h> element with heading level dictated only by the number of <section> nesting. But it's too late for that now I guess. 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.

JohnHaugeland 2y ago
that exists https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/header https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- p4bl0 2y ago
  I don't understand <header> to be a heading element (i.e., a section title). Instead it is a semantic container for heading elements: title, date, author, maybe category/tags, etc. To me, the heading level used inside a given <header> is a distinct, somewhat orthogonal thing (at least in how it is decided, from the nesting level or the tag name).

ralferoo 2y ago

Stuff like "Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice." make me pretty certain this is the wrong change to make. 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.

zozbot234 2y ago
Looks like this change only applies to literal <h1> elements, such that <h2> ... <h6> still preserve the old behavior. If so you can just use the <h2> tag in section-like contexts in place of the older <h1>, and get the same or a very similar outcome.
- jrvieira 2y ago
  completely defeating the purpose of html semantics in the first place
  - maccard 2y ago
    Honestly that ship has long since sailed.
    - ramses0 2y ago
      There is hope! I was going to point to my favorite example of the [menu] element being deprecated, but it looks like it's been un-deprecated! 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 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 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-elements.html#menus https://www.w3.org/TR/2011/WD-html5-20110405/interactive-ele... Other Commentary: https://dpogue.ca/articles/html5-menu.html https://dpogue.ca/articles/html5-menu.html Random bug report: https://github.com/IBMa/equal-access/issues/752#issuecomment-1088926294 https://github.com/IBMa/equal-access/issues/752#issuecomment...

JohnHaugeland 2y ago

ah, that mozilla commitment to unnecessary changes and backwards breakage

K0nserv 2y ago
All browser makers are making the change together, why are your singling out Mozilla?
- zcorpan 2y ago
  Someone has to be first. :-)

Ferret7446 2y ago

Wow, this will actually break my site. https://www.felesatra.moe/about 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.

pyinstallwoes 2y ago
Yeah exactly. It makes a lot more sense to treat headers automatically.
zcorpan 2y ago
It only worked visually. For screen reader users, all headings are level 1. If you switch to using h2 etc, it will be more accessible.
- Ferret7446 2y ago
  That's a problem with the screen reader implementation. At least, according to the previous semantics.
  - AlienRobot 2y ago
    It was a problem with the screen reader implementation in 2009 when the semantics were introduced. In 2025 if no screen reader works right it's a problem with the spec.
  - zcorpan 2y ago
    As of 2022 (when the outline algorithm was removed from the spec), it's a problem with your website implementation.

deleted 2y ago

[deleted]

cassepipe 2y ago

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

littlestymaar 2y ago

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

eek2121 2y ago

Terrible idea. Why is it that all the big browser makers are doing stupid stuff? 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…

MyOutfitIsVague 2y ago
Then do so. If you want specific styles, then style your content. If you don't, then you get whatever the defaults are. I really don't think there's much worth complaining about here.

WhyNotHugo 2y ago

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

zcorpan 2y ago
They do if you include <meta name="color-scheme" content="light dark"> Also see https://github.com/whatwg/html/issues/5426 https://github.com/whatwg/html/issues/5426

mediumsmart 2y ago

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 ...

ryao 2y ago

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

zcorpan 2y ago
There is no warning in that case.
- ryao 2y ago
  It is a shame the article did not explain that.

MyOutfitIsVague 2y ago

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

zcorpan 2y ago
Nested lists have 0 block-margin and different list-style-type. But that seems to be about it...

dimava 2y ago

tl;dr for those who didn't read the actual article: They are changing to x h1 { warning: semantically questionable } from /* 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 } which was removed from spec in 2022 So anyone who doesn't place H1s where they shouldn't have been anyways is fine

sayheytozoe 2y ago

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! https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/hgroup https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...