In short, the W3C adopted it because they thought it was a good idea, while browsers and screen readers both refused to adopt it for various reasons like ambiguity with existing web content or concerns about screen readers having to implement and maintain their own independent outline algorithm implementations. 8 years and an entire standards organization after the thread above, the WHATWG finally dropped it.
I'm not going to lie, I don't have a lot of faith in the people making markup decisions for HTML these days. It was obvious that none of these tags made any sense and anyone who knows what semantics mean knows they would get semantically bleached the instant they hit end users. Wordpress still uses B and I buttons for <em> and <strong>. That's never going to change because emphasis and strong are just not a thing that users understand so it can't be on the UI. In fact, I don't even understand the difference between the documentation fails to explicitly assert it. Screen readers and web browsers render them the same way as <b> and <i>. At this point I have to wonder for whom exactly what this markup created, and what problem did it seek to solve. I have no idea what was going on with the committee to take years of <h1> and <h2> meaning completely different things and think "what if <h1> meant the same thing as <h2> sometimes if it's in a <section>?" or "what if we <h3> didn't mean <h3> when it's in a <hgroup>?" This was a great place to introduce an <h> tag. Did they just want to avoid breaking backwards compatibility while at the same time not caring about it? I just don't understand...
Meanwhile everybody from users, to search engines, to social media platforms, to forums, to article writers are still waiting for a <spoiler>.
I think, if I remember correctly, that b and i are used to only alter the style of text, while strong and em are used for emphasis in something like a paragraph of text.
So you could use b in something like UI breadcrumbs, but of you wanted to strongly highlight something as an author of some text, you'd use strong.
I'm not really sure we need these though. As for my breadcrumbs example, I think everyone would use CSS rather than a b element.
So, I kinda understand the idea, but I've never needed it.
A thing that maybe comes to mind is that inner monologue in books uses italics sometimes. So using i would make sense more than em. But when wanting to emphasize/stress a word or phrase an em would make more sense than i.
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.
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).
How does that help with a document structure if everything on the h3 level is the same?
I wish there was a neutral <h> element that could then be specified at an arbitrary <h~n~> sometimes I have documents that have headings 8 levels deep.
Going back a lil further to 2011… We had a lil fight[1][2] about the value of using perfect HTML semantics in the community. The outline algorithm was the big defense for <section>, but its problems were clear then: https://www.smashingmagazine.com/2011/11/pursuing-semantic-v...
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.
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.
> As a reader, I don't want page authors to start hard coding sizes into these elements …
They mean h1 elements without a font-size specified in CSS (or style attribute) will be flagged as a warning. User agent styles can still override site styles if you want to set one.
> if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
This logic only applied to the h1 element specifically, as it was an attempt to shoehorn some “clever” logic from the abandoned <h> tag proposed in a early draft of HTML5 (which was going to work the way you’d describe for headings at any level), on to the existing h1 element.
(Source: I used to follow the WHAT-WG mailing list closely during the HTML5 spec development process.)
These shouldn't be a warning. We're supposed to have graceful degradation without any requirement for CSS anywhere. Now the only "correct" way is a slew of media queries to set some designer's idea of the font for every possible viewport size. That is not how HTML is supposed to be rendered.
> Now the only "correct" way is a slew of media queries to set some designer's idea of the font for every possible viewport size.
Nested H1s was never semantically correct in the first place, at least for accessibility purposes.
You can do flexible sizes without media queries (eg, viewport size units + clamp). Designers generally understand the web pretty well these days.
I only see one situation where people might have depended on these styles, but it's a big one - anywhere that you output the plain HTML of a "rich text" component from a CMS or whatever. There, if the stakes are low, it might not have been a big deal to just let the browser do it and headings might look too big sometimes now.
A warning IS graceful degradation, an error or unexpected behaviour would be ungraceful. The channel that warnings come over is separate from the channel the content is being rendered in and it shows, for those that look at it, that the system is degraded and an action would need to be done to restore it to a non-degraded state.
This is not about graceful degradation. An HTML document without any CSS should never be in a degraded state. It should be perfectly usable and perfectly well accepted.
I agree; a HTML document without CSS should be perfectly usable and OK (and ideally CSS should never be required; if CSS is disabled it ought to still work OK, too).
However, if CSS specifies some things and omits others that are related to it (one example is specifying the font size for one heading level but not another one; another example is specifying the background colour without specifying the foreground colour or vice-versa), then it makes sense to be a warning.
I can't articulate it and I could very well be on the wrong vibe, but this feels like the bad practice of relying on the failure mode within a try/catch for normal functioning.
> HTML is about semantic markup, not visual markup.
Yeah... when it was meant for documents. In practice, modern websites are not documents - at best, they have a document or a few (like an article, or a post) embedded somewhere inside something else: an application, a designed page - basically, layout and presentation but not a document. HTML was never truly designed to do anything like this and it will always remain the clay feet part of this colossus.
The reason people still use <h1> or other "semantic" tags is only because of that idea that search engines give more "weight" to text in those tags, not because they care about semantics or other formal stuff. Otherwise they would've kept slapping styled <divs>.
I have always argued that there needs to be an entirely different language for websites, something semantically closer to XUL, XAML or QML. Best we've ever got are various custom DSLs that render to HTML/CSS/JS combo, conveniently hiding the underlying mess under the rug.
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.
If that is true, then TFA seriously missed the mark:
> Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice.
Then when listing what to expect:
> Lighthouse will flag a warning if <h1> is used without a specified font-size.
And under the section "Fixing the Lighthouse warning":
> Lighthouse has recently inherited a check based on Chromium's DevTools warnings for sites that don't specify a font-size for <h1> elements.
Then it uses top-level h1 selectors in its examples of recommended styles. I mean you might be right about when that warning will appear, but the article doesn't seem to think you are.
> 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.
That ship has already sailed. Whether they do it inline or through CSS, no one cares about the defaults, or your defaults. "Standing out" has been by far the biggest factor in web design ever since there was a web, and continues to drive the development of web technologies - that's because most websites are marketing products, either entirely, or in non-functional aspects (branding).
> HTML is about semantic markup, not visual markup.
Hard disagree here. HTML is too low-level to be semantic. "Separation of content and presentation" is a fundamentally flawed idea, because in many cases presentation is core to the semantics, and this is especially true for the Web, as in marketing, presentation is the content.
I remember the times when the CSS Zen Garden appeared, and everyone went on to meditate there and get high on the "separation of concerns" fumes emitted by the stylesheet selector widget. It was a great trip, but like with all such experiences, the effects are transient and don't carry to the adult reality.
Still, many a webdev tried to hold on to this ideal, many still do today. The results speak for themselves. What does "semantic HMTL" look like? A thick soup of nested divs with more or less meaningful class names, that only loosely resembles the natural structure of the content, because it's written specifically for its companion stylesheets, and only looks well with those particular stylesheets.
Here's a thought many still don't seem to realize: "semantics" in HTML isn't just about tag names, it's also about the shape of your tree. Your document isn't purely semantic, when the entire structure of the document is determined by needs of a specific presentation.
</rant>
You do have a good point about blockquotes. It's one of my main annoyances with markup / outliner formats used in many applications: they treat headline levels as absolute instead of relative, which doesn't play well with attempts at nesting documents inside documents.
In fact, to the extent HTML elements are supposed to be semantic, we shouldn't have headline levels in the first place! Instead of <h1>, <h2>, ... we should just have <header> - the headline level is implicit in the nesting anyway, and it naturally supports quoting/embedding documents in documents (and arbitrarily deep). As they are, <hN> are predominantly about presentation.
Same applies to Microsoft Word, too - the decision to have explicit named styles for headings (1 thru 9) as well as lists and others, causes problems more often than one would expect - at least for the few of us who insist on styling the document semantically, instead of applying specific looks to text by hand like most people do.
> "Standing out" has been by far the biggest factor in web design ever since there was a web,
I don't think that's true or at least as strongly as you suggest. When Bootstrap first came along, all websites that used it clearly looked the same, with minor differences. We see the same today but instead of Bootstrap, people use Tailwind or other libraries/frameworks but the effect is the same, most landing pages look the same, even if the images have different colors.
Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches. Very different from the web in the 90s/early 00s, where every website worked and looked very different from each other.
> When Bootstrap first came along, all websites that used it clearly looked the same, with minor differences. We see the same today but instead of Bootstrap, people use Tailwind or other libraries/frameworks but the effect is the same, most landing pages look the same, even if the images have different colors.
There's a logic to this phenomena, and it involves few people/companies trying something new to stand out (sometimes by being flashy, sometimes by being more ergonomic or less assaulting on the senses), some others following suit, and then if that "sticks", you'll see everyone else adopting the same design too. In particular, when some design reaches enough adoption, people who don't use it start to stand out, negatively - visitors start to see them as quaint, or worse, weird and therefore untrustworthy.
(It's not a bad heuristic, either. You can avoid a lot of Internet scams if you pay attention to how the website comes across to you at a visceral level. It's kind of a "spidey sense" many of us Internet dwellers have :).)
This is not Internet-specific either, it's also a thing in branding and product design spaces in general.
> Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches.
That applies to products/services. Those tend to stand out subtler, but usually there's still a marketing department having strong influence (if not final say) on the design, and they make sure the branding is clear and the site is still easy to distinguish from any other site built with the same libraries and frameworks.
(The other category of websites is just glorified posters and magazines, and those are much weirder and unique, though even there you'll find fashion trends.)
EDIT:
The more general point is, presentation is always a core concern in commercial software, because branding is a core concern for companies. This has been true even before the Web; I recall some old UI Design Guidelines from Microsoft, IIRC for Windows 95, where this is acknowledged explicitly - the OS is pressured to provide ways to customize look&feel of UI elements, because software vendors demand it for branding, and so we can forget about having uniform UIs between applications. This is the unfortunate reality that drives UI standards.
> In fact, to the extent HTML elements are supposed to be semantic, we shouldn't have headline levels in the first place! Instead of <h1>, <h2>, ... we should just have <header> - the headline level is implicit in the nesting anyway
The <header> vs <h#> decision often ends up being a flow-breaking exception in my development process.
It also bugs me that we have exactly six hardcoded heading levels. Something about that feels like it violates a deep, lizard-brain-level DRY principle.
My main concern is how well screen readers and assistive tech would handle a semantic-only approach, as the <h#> elements go all the way back to the beginning of HTML and are pretty deeply rooted in standard practices.
I also think that not specifying the font size should not be called bad practice (unless you defined the font sizes for everything else and omitted some of them; if you do that then it is inconsistent). If you do not specify any CSS at all, that should not be a warning or error (it might not be displayed the same on all computers, but it shouldn't need to be anyways, so it is OK).
> As a reader, I don't want page authors to start hard coding sizes into these elements
I also, would rather they don't hard-code sizes (and also fonts, margins, etc); use whatever size is configured in the browser which is suitable for that display and that user.
> Additionally, the current behaviour (which I'd never particularly considered before) sounds entirely reasonable - if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
Maybe. It is unclear that there should be a first-level heading inside of something else anyways.
> 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.
Completely agree. In fact, this is what auditing tools should flag.
Let HTML be HTML!
Frankly, I think that the existing algorithm sounds correct, but I could be wrong.
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-bey...).
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.
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.
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.
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.)
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.
Sections are a very good idea for a tag that embedded a document in a lower hierarchy inside your document. The way that it should be from the beginning instead of having the global h1, h2... and hacking a structure out of them.
But then screen readers universally decided that no, instead of using sections to navigate a page, they will just ignore the spec and flatten everything into the top of the hierarchy. So nobody uses them.
(And yes, it shouldn't be a warning to use an h1 in a section with the default style either. They are just making a non-backwards-compatible change to the default style, fucking own it and have the old pages change.)
"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.
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"
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.
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).
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?
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".
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.
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.
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.
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.)
? 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.
> 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.
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.
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.
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.
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!
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.
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.
> 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...
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).
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.
I think it is fair to say TBL didn't come up with a perfect design, and he never set out to. He solved a simpler problem than the ones we have now, and that's just fine. He might be the last person to imagine HTML would have continued on with so much of its original design intact.
> Do not rely on default browser styles for conveying a heading hierarchy. Explicitly define your document hierarchy using <h2> for second-level headings, <h3> for third-level, etc.
Be incorrect? The original html standard clearly stated this was acceptable but now there should only be a single H1 which is the page heading and all other headings should be H2 and lower. What if the page content doesn't actually have a single main heading? This change fundamentally changes the semantics of something which has had unclear semantics for decades and which actually rendered what I typed above correctly in the past. Now it would not be rendered correctly anymore.
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.
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.
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.
People should not be downvoting you. You are absolutely write: numbered heading level is a non-modular abomination.
edit: Oh I see, yes the title shouldn't just attribute, but there is no deep reason for that, just HTML convention. I would rather what you wrote than the status quo.
Au contraire, displaying is a concern for CSS, not for HTML which is supposed to show content. In the only sense that bold or italics are appropriate in HTML is in that they sometimes transmit a meaning that can be reduced to "italic" or "bold", it would be more expressive to transmit however that <!>something is important<!/> or that it has <foreign>gravitas</foreign>.
Similarly the title of a section can be displayed with bold, or not at all, or as part of the index in the front page, or at the index at the end, or in a hovering table of contents that displays while you scroll the page, and it may be bold, big, or blue or small. All of that is a matter for the styling document, not for the content document.
The content only cares that this part is the Reptile part, not whether the R in reptile will look like a dinosaur, that's a job for style="ornamented-initial:dinosaur where the loop of the R is a mouth, and the two lower lines are the feet and the tiny t rex arms.", which would probably only be interpretable by a browser connected with a stable diffussion model.
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.
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'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.
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.
> 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.
> 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.
Remember: The people who would supposed to benefit from a rollout like this are the website operators, not Firefox. The change is happening; I doubt Mozilla is going to reverse course because a couple websites look a little wonky (totally reasonable).
How would they report it? "Hey, your website looks weird. Yeah I'm running Firefox 138 stable and I'm in the 5% experimental group who received the default h1 styling change"?
What is more likely to happen is: A website might get a report, the dev goes to reproduce it, and they're in the control group, so they can't; and because it was only one or two reports, it gets closed.
Firefox also has a built-in "broken website" reporter in the Help menu, which sends a report to Mozilla. The WebCompat team analyzes those reports and can decide to report a Gecko bug if it has a bug, contact the website if they have a bug, or apply a sitepatch. We're also monitoring the broken website reports for regressions from this change in particular.
I understand that a rollout makes reproduction harder, and not everyone will be aware of the change. It's a tradeoff when deciding whether to do a rollout or ride the trains normally.
You should first investigate the cause of the bug before spamming Firefox developers with potentially invalid reports. And it is difficult to investigate when your browser and user's browser behave different.
Yeah that makes no sense. Versions are meaningless if they don't represent standard defaults. But then, evergreen software makes versions something like an implementation detail anyway.
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.
> 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.
Some testing has already happened before starting the rollout.
The change has been shipping in Firefox Nightly for a year. I have analyzed impact of affected pages in the HTTP Archive dataset (about 12,000,000 pages), twice:
You can't test against the entire web, especially internationally. Do you know what the most popular Vietnamese sites are? I don't either. Do that for >200 languages. Never mind of course there's tons of non-public stuff.
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.
Yes, the user should ultimately have the final say about what colors, fonts, and sizes are used by their browser. We've handed way too much control over to the web developers. Web sites don't have to be pixel perfect. If I want to render text using Comic Sans by default, that shouldn't "break" anything.
> We've handed way too much control over to the web developers.
We lost this battle by 1999. And again when we started to deliver full web applications instead of documents.
I wish we had a second protocol that was more document and information focused. Something that gave zero control over programming or layout to providers.
I just want to exchange information P2P in a dense swarm approximating modern social media. I want to use my own client configured how I like it to choose what to ingest and how to flag it and present it.
Who are we kidding. With those as our choices, it's no wonder most people just use the face book.
Hyper scale businesses captured most of the internet's value and humans and turned tech into a series of walled gardens for eyeball attention doom scroll maximization. Retweeting the for you page is what some committee of product managers decided was best for us all. Who are we to question the architectures of power?
It almost sounds like a perverse weird utopia to imagine a world where we controlled all of the information flows ourselves. I can't think why we should have all the power.
the internet has become more accessible both to consumers and people trying to sell a product. it has become crowded in "the market" you refer to. but all the good things all still there, and are doing much better than they were. i still use all of those protocols and a bunch of newer ones.
I remember when the web came out, I said "This is just a prettier gopher." Seeing the end result of 30 years of web development, I kind of wish it stayed just a prettier gopher.
> If I want to render text using Comic Sans by default, that shouldn't "break" anything
Not sure how we could expect users to switch between whatever font they want, and things not breaking.
Different fonts both appear and have different sizes, so what might look perfect with one font (a button where the text is aligned in the center vertically/horizontally), can look massively different with another (say the font's characters are wider, so now the text either overflows or breaks into two parts, making the button "broken").
The fix is called reset.css. Allows you to skip headlines like subj and only emotionally react to the "but you already have an app platform, it's web, shtupid" and "you should feel bad about your choices" split around your practical needs.
"you should feel bad about the choices that led you to that point in your life" - I suggest you find help to deal with the bitterness you have inside of you.
I suggest you examine the state of the industry and the garbage that’s passed off as reasonable these days and ask yourself whether what you perceive in my comments is bitterness.
The garbage that dominates the web has everything to do with centralization of power, and nothing with HTML vs JS. The former is a people problem and the latter is just tech.
For many places where apps would previously be accepted users don't want native applications anymore.
For work other than some very industry specific high performance software most businesses software is web based, and users ( those paying the bills anyways ) want them to be web based because it is much more portable and easy to deploy.
They actually are though, in reality. Your point is what should they be, not what they actually are. The truth of the situation is that webpages _actually are_ applications now, due to the new features the browsers have added to facilitate that
I actually work at Qt and many of our new products are web apps
Web pages mostly aren't applications though. Like people will sometimes post links to corporate engineering blogs here that require javascript (Uber comes to mind). It's purely a document; there's no interactivity at all. Making it an "application" is just incompetence (it's more expensive to develop and gives a worse user experience).
It might be true that applications actually are web pages now (e.g. Slack, WebEx), but I almost never encounter web pages that are actually applications.
That’s too bad, but not unexpected given that Qt’s itself a non-native toolkit anywhere other than Linux that developers on those other platforms shouldn’t touch.
Cross-platform frameworks are inevitably crap. If you really need to run an application on multiple platforms, write a cross-platform core and implement the human interface atop it for each platform using each platform’s native frameworks and languages.
The result is always a better product with happier users. If you don’t want to invest in that, you should at minimum be willing to admit to yourself that you’re OK with giving your users something subpar because it’s to your advantage to do so.
I got stuck trying that. To facilitate non JS by default my products are checkboxes and the checkout button submits the form (it is a spa). This works well but navigating back the user is presented with an "error" page asking if they want to submit the form again. Is there a solution for that?
I have done this in projects with POST forms: ”To avoid the resubmit warning when hitting back, use the Post/Redirect/Get pattern: after a POST, redirect with a 303 to a normal GET page. The browser skips saving the POST in history, so back just takes you to the form without complaining.”
The usual way to deal with it is to respond to form submissions with an HTTP redirect to another page. The user can still hit the back button, but the scary popup won't occur.
However, you run the risk of the user re-submitting the form anyway. Since this is involving orders and money, you may want the order confirmation / submit page to have a nonce or temporary ID representing the checkout session in the URL such that, upon revisiting that page, you can lookup the order status on the backend and redirect them to the order success page again.
This will prevent re-submission but still be confusing for the user. Why even allow submitting when navigating back? If the order has been submitted already, the submit button should be greyed out with a message saying that the order has been submitted already.
The original task was to do this without JS, so my first guess would be: Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server.
This is why I suggested the URL for the submission page be unique- having a session nonce / token or similar. That way, once the user checks out you invalidate the checkout session, and if the user hits the back button you redirect them to the appropriate page.
I specifically called out the issue of re-submitting certain forms and proposed the above solution. I don't think relying on cache headers is going to be sufficiently reliable.
I'm not arguing against a re-submission check. You'll need that anyway to prevent attackers from bypassing the browser and messing up your data.
But even with a nonce and a re-submission check, the cache headers are essential to make sure that when the user presses the back button, they'll see a greyed-out submit button. If the browser does not reload that page, the button will still be clickable. It won't work correctly because the re-submission check will fail, but a clickable and guaranteed non-functional button is very bad UI.
The latter is one of the main reasons that we have so much JS/SPAs. Sure, you can build an application without it that is somewhat functional, but the UI will be low-quality -- even if this particular example might be fixable with cacheability headers.
There is no re-submission check. When the user hits the back button, and requests the HTML from the server, the serve responds with a redirect. The user never sees the expired cart.
> Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server
Re-loading the page on navigating back would be done using cacheability headers. This is the most shaky part, and I'm not sure if it is possible today. If this does indeed not work, then this would be one of the "things that Javascript has solved that the non-JS web is still stuck with" I meantioned in my other post, i.e. one of the reasons that JS is more popular than non-JS pages today.
Identifying the order using an ID in the URL is standard practice everywhere.
When the order page gets requested, the server would take that ID, look the order up in the database and see that it is already submitted, responding with a page that has its submit button disabled.
The must have js part for me starts where one can open the store in multiple tabs then add and remove things on the first two and check out on the 3rd tab.
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.
You have now stated that "those people should feel bad" for the second time. Personal attacks will hardly bring any change into this world. I'd instead suggest that you propose actual ways to solve the same problems that Javascript-based SPAs have solved which the non-JS web is still stuck with.
Just add a matter of precision, personal attacks won't generally improve the world on the overwhole aftermaths. But they do generally change the world into a less pleasant place to live in.
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.
I made a web game that's simply not possible without js. Is it your contention the it simply shouldn't exist? Lots of people seem to enjoy it and I think they'd be disappointed.
Actually the more I’ve gone in my career the more I’ve realized we underestimate the cost of changes. Getting vendors to change a single line of code can be incredible amounts of money.
> 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.
The web is explicitly and intentionally a software distribution platform. JavaScript is a web standard and is no less “part of the web” than HTML and CSS. You’re f
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
And <hgroup>, and <em>, and <strong>...
I'm not going to lie, I don't have a lot of faith in the people making markup decisions for HTML these days. It was obvious that none of these tags made any sense and anyone who knows what semantics mean knows they would get semantically bleached the instant they hit end users. Wordpress still uses B and I buttons for <em> and <strong>. That's never going to change because emphasis and strong are just not a thing that users understand so it can't be on the UI. In fact, I don't even understand the difference between the documentation fails to explicitly assert it. Screen readers and web browsers render them the same way as <b> and <i>. At this point I have to wonder for whom exactly what this markup created, and what problem did it seek to solve. I have no idea what was going on with the committee to take years of <h1> and <h2> meaning completely different things and think "what if <h1> meant the same thing as <h2> sometimes if it's in a <section>?" or "what if we <h3> didn't mean <h3> when it's in a <hgroup>?" This was a great place to introduce an <h> tag. Did they just want to avoid breaking backwards compatibility while at the same time not caring about it? I just don't understand...
Meanwhile everybody from users, to search engines, to social media platforms, to forums, to article writers are still waiting for a <spoiler>.
I think, if I remember correctly, that b and i are used to only alter the style of text, while strong and em are used for emphasis in something like a paragraph of text.
So you could use b in something like UI breadcrumbs, but of you wanted to strongly highlight something as an author of some text, you'd use strong.
I'm not really sure we need these though. As for my breadcrumbs example, I think everyone would use CSS rather than a b element.
So, I kinda understand the idea, but I've never needed it.
A thing that maybe comes to mind is that inner monologue in books uses italics sometimes. So using i would make sense more than em. But when wanting to emphasize/stress a word or phrase an em would make more sense than i.
+1 regarding <spoiler>!
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.
It's better because it's explicit. That's it.
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.
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).
How does that help with a document structure if everything on the h3 level is the same?
I wish there was a neutral <h> element that could then be specified at an arbitrary <h~n~> sometimes I have documents that have headings 8 levels deep.
It's worse because you need knowledge of the entire rendered page even when you're creating a subsection that may get templated into the overall page.
It's like if you removed relative paths and working directories from all OSes. A lot of things become really annoying to do.
In practice you're really never going to go below <h3> unless you're writing an actual document, in which case you probably should have a good editor.
Going back a lil further to 2011… We had a lil fight[1][2] about the value of using perfect HTML semantics in the community. The outline algorithm was the big defense for <section>, but its problems were clear then: https://www.smashingmagazine.com/2011/11/pursuing-semantic-v...
[1] https://www.smashingmagazine.com/2011/11/our-pointless-pursu...
[2] https://www.smashingmagazine.com/2011/11/pursuing-semantic-v...
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-h....
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.
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.
> As a reader, I don't want page authors to start hard coding sizes into these elements …
They mean h1 elements without a font-size specified in CSS (or style attribute) will be flagged as a warning. User agent styles can still override site styles if you want to set one.
> if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
This logic only applied to the h1 element specifically, as it was an attempt to shoehorn some “clever” logic from the abandoned <h> tag proposed in a early draft of HTML5 (which was going to work the way you’d describe for headings at any level), on to the existing h1 element.
(Source: I used to follow the WHAT-WG mailing list closely during the HTML5 spec development process.)
These shouldn't be a warning. We're supposed to have graceful degradation without any requirement for CSS anywhere. Now the only "correct" way is a slew of media queries to set some designer's idea of the font for every possible viewport size. That is not how HTML is supposed to be rendered.
> Now the only "correct" way is a slew of media queries to set some designer's idea of the font for every possible viewport size.
Nested H1s was never semantically correct in the first place, at least for accessibility purposes.
You can do flexible sizes without media queries (eg, viewport size units + clamp). Designers generally understand the web pretty well these days.
I only see one situation where people might have depended on these styles, but it's a big one - anywhere that you output the plain HTML of a "rich text" component from a CMS or whatever. There, if the stakes are low, it might not have been a big deal to just let the browser do it and headings might look too big sometimes now.
A warning IS graceful degradation, an error or unexpected behaviour would be ungraceful. The channel that warnings come over is separate from the channel the content is being rendered in and it shows, for those that look at it, that the system is degraded and an action would need to be done to restore it to a non-degraded state.
The GP didn't find the right words.
This is not about graceful degradation. An HTML document without any CSS should never be in a degraded state. It should be perfectly usable and perfectly well accepted.
I agree; a HTML document without CSS should be perfectly usable and OK (and ideally CSS should never be required; if CSS is disabled it ought to still work OK, too).
However, if CSS specifies some things and omits others that are related to it (one example is specifying the font size for one heading level but not another one; another example is specifying the background colour without specifying the foreground colour or vice-versa), then it makes sense to be a warning.
I've been a pro web dev since 1995.
I can't articulate it and I could very well be on the wrong vibe, but this feels like the bad practice of relying on the failure mode within a try/catch for normal functioning.
> HTML is about semantic markup, not visual markup.
Yeah... when it was meant for documents. In practice, modern websites are not documents - at best, they have a document or a few (like an article, or a post) embedded somewhere inside something else: an application, a designed page - basically, layout and presentation but not a document. HTML was never truly designed to do anything like this and it will always remain the clay feet part of this colossus.
The reason people still use <h1> or other "semantic" tags is only because of that idea that search engines give more "weight" to text in those tags, not because they care about semantics or other formal stuff. Otherwise they would've kept slapping styled <divs>.
I have always argued that there needs to be an entirely different language for websites, something semantically closer to XUL, XAML or QML. Best we've ever got are various custom DSLs that render to HTML/CSS/JS combo, conveniently hiding the underlying mess under the rug.
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.
completely defeating the purpose of html semantics in the first place
Why? Just use different h1...h6 family tags depending on your structure.
The example in the article
<body> <h1>Level 1</h1> <section> <h1>Level 2</h1> <section> <h1>Level 3</h1> <section> <h1>Level 4</h1> </section> </section> </section> </body>
can become
<body> <h1>Level 1</h1> <section> <h2>Level 2</h1> <section> <h3>Level 3</h1> <section> <h4>Level 4</h1> </section> </section> </section> </body>
> tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice.
You forgot to include a font size in your h1's which is what people are complaining about needing to do.
The warning is only for <h1>s inside a section, so GP’s example — where the only h1 is at the top level — would not be flagged.
If that is true, then TFA seriously missed the mark:
> Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice.
Then when listing what to expect:
> Lighthouse will flag a warning if <h1> is used without a specified font-size.
And under the section "Fixing the Lighthouse warning":
> Lighthouse has recently inherited a check based on Chromium's DevTools warnings for sites that don't specify a font-size for <h1> elements.
Then it uses top-level h1 selectors in its examples of recommended styles. I mean you might be right about when that warning will appear, but the article doesn't seem to think you are.
The error is named `H1UserAgentFontSizeInSection` -- makes it seems like it would only fire for an H1 used in a section?
TFA has been fixed to make this clearer. Thanks!
Honestly that ship has long since sailed.
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
Menu Deprecated in HTML 4: https://www.w3.org/TR/html401/struct/lists.html#h-10.4
Menu Part of HTML 5 Spec: https://www.w3.org/TR/2011/WD-html5-20110405/interactive-ele...
Other Commentary: https://dpogue.ca/articles/html5-menu.html
Random bug report: https://github.com/IBMa/equal-access/issues/752#issuecomment...
> As a reader, I don't want page authors to start hard coding sizes into these elements, because then they'll be more likely to choose non-default values to make their page stand out a bit more.
That ship has already sailed. Whether they do it inline or through CSS, no one cares about the defaults, or your defaults. "Standing out" has been by far the biggest factor in web design ever since there was a web, and continues to drive the development of web technologies - that's because most websites are marketing products, either entirely, or in non-functional aspects (branding).
> HTML is about semantic markup, not visual markup.
Hard disagree here. HTML is too low-level to be semantic. "Separation of content and presentation" is a fundamentally flawed idea, because in many cases presentation is core to the semantics, and this is especially true for the Web, as in marketing, presentation is the content.
I remember the times when the CSS Zen Garden appeared, and everyone went on to meditate there and get high on the "separation of concerns" fumes emitted by the stylesheet selector widget. It was a great trip, but like with all such experiences, the effects are transient and don't carry to the adult reality.
Still, many a webdev tried to hold on to this ideal, many still do today. The results speak for themselves. What does "semantic HMTL" look like? A thick soup of nested divs with more or less meaningful class names, that only loosely resembles the natural structure of the content, because it's written specifically for its companion stylesheets, and only looks well with those particular stylesheets.
Here's a thought many still don't seem to realize: "semantics" in HTML isn't just about tag names, it's also about the shape of your tree. Your document isn't purely semantic, when the entire structure of the document is determined by needs of a specific presentation.
</rant>
You do have a good point about blockquotes. It's one of my main annoyances with markup / outliner formats used in many applications: they treat headline levels as absolute instead of relative, which doesn't play well with attempts at nesting documents inside documents.
In fact, to the extent HTML elements are supposed to be semantic, we shouldn't have headline levels in the first place! Instead of <h1>, <h2>, ... we should just have <header> - the headline level is implicit in the nesting anyway, and it naturally supports quoting/embedding documents in documents (and arbitrarily deep). As they are, <hN> are predominantly about presentation.
Same applies to Microsoft Word, too - the decision to have explicit named styles for headings (1 thru 9) as well as lists and others, causes problems more often than one would expect - at least for the few of us who insist on styling the document semantically, instead of applying specific looks to text by hand like most people do.
> "Standing out" has been by far the biggest factor in web design ever since there was a web,
I don't think that's true or at least as strongly as you suggest. When Bootstrap first came along, all websites that used it clearly looked the same, with minor differences. We see the same today but instead of Bootstrap, people use Tailwind or other libraries/frameworks but the effect is the same, most landing pages look the same, even if the images have different colors.
Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches. Very different from the web in the 90s/early 00s, where every website worked and looked very different from each other.
> When Bootstrap first came along, all websites that used it clearly looked the same, with minor differences. We see the same today but instead of Bootstrap, people use Tailwind or other libraries/frameworks but the effect is the same, most landing pages look the same, even if the images have different colors.
There's a logic to this phenomena, and it involves few people/companies trying something new to stand out (sometimes by being flashy, sometimes by being more ergonomic or less assaulting on the senses), some others following suit, and then if that "sticks", you'll see everyone else adopting the same design too. In particular, when some design reaches enough adoption, people who don't use it start to stand out, negatively - visitors start to see them as quaint, or worse, weird and therefore untrustworthy.
(It's not a bad heuristic, either. You can avoid a lot of Internet scams if you pay attention to how the website comes across to you at a visceral level. It's kind of a "spidey sense" many of us Internet dwellers have :).)
This is not Internet-specific either, it's also a thing in branding and product design spaces in general.
> Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches.
That applies to products/services. Those tend to stand out subtler, but usually there's still a marketing department having strong influence (if not final say) on the design, and they make sure the branding is clear and the site is still easy to distinguish from any other site built with the same libraries and frameworks.
(The other category of websites is just glorified posters and magazines, and those are much weirder and unique, though even there you'll find fashion trends.)
EDIT:
The more general point is, presentation is always a core concern in commercial software, because branding is a core concern for companies. This has been true even before the Web; I recall some old UI Design Guidelines from Microsoft, IIRC for Windows 95, where this is acknowledged explicitly - the OS is pressured to provide ways to customize look&feel of UI elements, because software vendors demand it for branding, and so we can forget about having uniform UIs between applications. This is the unfortunate reality that drives UI standards.
Tailwind feels like the bad old days of style="........". And it looks like some weird dialect of Forth code.
> In fact, to the extent HTML elements are supposed to be semantic, we shouldn't have headline levels in the first place! Instead of <h1>, <h2>, ... we should just have <header> - the headline level is implicit in the nesting anyway
The <header> vs <h#> decision often ends up being a flow-breaking exception in my development process.
It also bugs me that we have exactly six hardcoded heading levels. Something about that feels like it violates a deep, lizard-brain-level DRY principle.
My main concern is how well screen readers and assistive tech would handle a semantic-only approach, as the <h#> elements go all the way back to the beginning of HTML and are pretty deeply rooted in standard practices.
I also think that not specifying the font size should not be called bad practice (unless you defined the font sizes for everything else and omitted some of them; if you do that then it is inconsistent). If you do not specify any CSS at all, that should not be a warning or error (it might not be displayed the same on all computers, but it shouldn't need to be anyways, so it is OK).
> As a reader, I don't want page authors to start hard coding sizes into these elements
I also, would rather they don't hard-code sizes (and also fonts, margins, etc); use whatever size is configured in the browser which is suitable for that display and that user.
> Additionally, the current behaviour (which I'd never particularly considered before) sounds entirely reasonable - if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
Maybe. It is unclear that there should be a first-level heading inside of something else anyways.
> 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.
Completely agree. In fact, this is what auditing tools should flag.
Let HTML be HTML!
Frankly, I think that the existing algorithm sounds correct, but I could be wrong.
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.
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-bey...).
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-structur....
It has been in the spec since 2009: https://github.com/whatwg/html/commit/0ed655652d52f0ab068fcb...
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
Perhaps to address screen-readers and broken semantics of a page?
So many words but no example screenshot showing what the changes might look like?
Good point. Now fixed!
The screenshots helped me understand it... turns out the "change" will work how my brain already thought it worked.
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.
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.
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.)
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.
Sections are a very good idea for a tag that embedded a document in a lower hierarchy inside your document. The way that it should be from the beginning instead of having the global h1, h2... and hacking a structure out of them.
But then screen readers universally decided that no, instead of using sections to navigate a page, they will just ignore the spec and flatten everything into the top of the hierarchy. So nobody uses them.
(And yes, it shouldn't be a warning to use an h1 in a section with the default style either. They are just making a non-backwards-compatible change to the default style, fucking own it and have the old pages change.)
"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.
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"
This is already the case, the warning is only for h1 in article/aside/nav/section. I'll fix the article to make this clearer, thanks.
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.
that exists
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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).
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?
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".
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.
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.
XHTML2 had some good ideas.
There's a new proposal to address this: https://github.com/whatwg/html/issues/5033
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.
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.
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.)
? 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.
> 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.
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.
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.
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.
Nice, I didn't know that.
The difference between W3C and what browsers actually implement, if you don't laugh, you'll cry.
Well it’s getting removed so only useful if you want to recreate the css they are removing.
Oops. Perhaps I need to read the article again!
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!
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Wow, this will actually break my site.
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.
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.
That's a problem with the screen reader implementation. At least, according to the previous semantics.
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.
As of 2022 (when the outline algorithm was removed from the spec), it's a problem with your website implementation.
Yeah exactly. It makes a lot more sense to treat headers automatically.
Interesting stuff, great for Accessibility! Maybe some screenshots could have made the article more... accessible.
Fixed, thanks.
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.
Nested lists have 0 block-margin and different list-style-type. But that seems to be about it...
> 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_developme...
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).
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.
I think it is fair to say TBL didn't come up with a perfect design, and he never set out to. He solved a simpler problem than the ones we have now, and that's just fine. He might be the last person to imagine HTML would have continued on with so much of its original design intact.
The article says
> Do not rely on default browser styles for conveying a heading hierarchy. Explicitly define your document hierarchy using <h2> for second-level headings, <h3> for third-level, etc.
The argument I was making was what is why would
Be incorrect? The original html standard clearly stated this was acceptable but now there should only be a single H1 which is the page heading and all other headings should be H2 and lower. What if the page content doesn't actually have a single main heading? This change fundamentally changes the semantics of something which has had unclear semantics for decades and which actually rendered what I typed above correctly in the past. Now it would not be rendered correctly anymore.The spec allows multiple top-level headings: https://html.spec.whatwg.org/multipage/sections.html#heading...
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.
They do if you include <meta name="color-scheme" content="light dark">
Also see https://github.com/whatwg/html/issues/5426
I always thought the headers in html were kind of dumb. I always think of book sections as:
<section name="Animals">
</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.
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:
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.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.
Yes, and this is also a mistake, hence the <button> element.
::after { content: attr(id) }
What you're looking for is a <heading> tag. It would have been the right solution to this issue without introducing changes for h1-h6
People should not be downvoting you. You are absolutely write: numbered heading level is a non-modular abomination.
edit: Oh I see, yes the title shouldn't just attribute, but there is no deep reason for that, just HTML convention. I would rather what you wrote than the status quo.
> Oh I see, yes the title shouldn't just attribute, but there is no deep reason for that
A reason is that you might want formatting (bold, italics, etc) on the text of a title.
OK yes, fair. Anything that is displayed needs its own attributes, and therefore must be its own tagged thing. Good point.
Au contraire, displaying is a concern for CSS, not for HTML which is supposed to show content. In the only sense that bold or italics are appropriate in HTML is in that they sometimes transmit a meaning that can be reduced to "italic" or "bold", it would be more expressive to transmit however that <!>something is important<!/> or that it has <foreign>gravitas</foreign>.
Similarly the title of a section can be displayed with bold, or not at all, or as part of the index in the front page, or at the index at the end, or in a hovering table of contents that displays while you scroll the page, and it may be bold, big, or blue or small. All of that is a matter for the styling document, not for the content document.
The content only cares that this part is the Reptile part, not whether the R in reptile will look like a dinosaur, that's a job for style="ornamented-initial:dinosaur where the loop of the R is a mouth, and the two lower lines are the feet and the tiny t rex arms.", which would probably only be interpretable by a browser connected with a stable diffussion model.
Am I the only one who had no idea that these sectioning elements existed?
This seems like a silly warning to give if there are no sectioning elements affecting <h1>.There is no warning in that case.
It is a shame the article did not explain that.
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.
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…
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.
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'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.
I've always been under the impression that there was only one <h1> per page
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/...
It's just a SEO "good practice", but it's perfectly fine to have more than one <h1> tag.
Yeah. Came to ask the same. Always been my understanding.
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.
tl;dr for those who didn't read the actual article:
They are changing to
from which was removed from spec in 2022So anyone who doesn't place H1s where they shouldn't have been anyways is fine
Does this mean there are people out there who don't use a reset.css stylesheet? I find that to be spooky.
ah, that mozilla commitment to unnecessary changes and backwards breakage
All browser makers are making the change together, why are your singling out Mozilla?
Someone has to be first. :-)
> 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.
> 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.
Remember: The people who would supposed to benefit from a rollout like this are the website operators, not Firefox. The change is happening; I doubt Mozilla is going to reverse course because a couple websites look a little wonky (totally reasonable).
How would they report it? "Hey, your website looks weird. Yeah I'm running Firefox 138 stable and I'm in the 5% experimental group who received the default h1 styling change"?
What is more likely to happen is: A website might get a report, the dev goes to reproduce it, and they're in the control group, so they can't; and because it was only one or two reports, it gets closed.
Firefox also has a built-in "broken website" reporter in the Help menu, which sends a report to Mozilla. The WebCompat team analyzes those reports and can decide to report a Gecko bug if it has a bug, contact the website if they have a bug, or apply a sitepatch. We're also monitoring the broken website reports for regressions from this change in particular.
I understand that a rollout makes reproduction harder, and not everyone will be aware of the change. It's a tradeoff when deciding whether to do a rollout or ride the trains normally.
> I doubt Mozilla is going to reverse course because a couple websites look a little wonky (totally reasonable).
This is totally possible. Many changes to the web platform we abandoned or changed significantly because a couple of websites look a little wonky.
> simply because people use older versions, use different browsers, etc.
Yes, but in this case asking the user to update to the latest version won't fix the problem either. I agree it's a terrible idea.
You would direct the user to submit a bug to Firefox if the latest version doesn't fix the issue. That's how they learn if this change causes issues.
You should first investigate the cause of the bug before spamming Firefox developers with potentially invalid reports. And it is difficult to investigate when your browser and user's browser behave different.
It's a beta version. Betas don't roll out evenly. Asking the user to update to a beta version has never been a good idea.
They are doing it for the stable release as well:
> The plan is to roll out to 5% of users on the Firefox 138 stable release, ramp up to 50% of users, then ship on all platforms in Firefox 140.
Yeah that makes no sense. Versions are meaningless if they don't represent standard defaults. But then, evergreen software makes versions something like an implementation detail anyway.
Usually we can use feature flags. Browser makers also have beta versions or their browsers available for devs.
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.
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.
> 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.
Some testing has already happened before starting the rollout.
The change has been shipping in Firefox Nightly for a year. I have analyzed impact of affected pages in the HTTP Archive dataset (about 12,000,000 pages), twice:
https://github.com/whatwg/html/issues/7867#issuecomment-1977... https://github.com/whatwg/html/issues/7867#issuecomment-2595...
The next step is either rollout or ship directly.
You can't test against the entire web, especially internationally. Do you know what the most popular Vietnamese sites are? I don't either. Do that for >200 languages. Never mind of course there's tons of non-public stuff.
You can test on special testing versions. Browser instances behaving inconsistently with the same version only add more problems to developers.
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.
> How about devs evaluate a change by doing some testing, instead of using users as guinea pigs?
Presumably they have done as much of that evaluation as is reasonable already.
Second that - I assume that they did asnmuch as they could and this is just defense in depth one additional step.
That is not defence in depth, that is causing annoyance to web developers.
In my experience, that's probably not a good presumption anymore.
It feels to me like usability testing and quality assurance have both joined security and accessibility on the back burner now.
Yeah why didn't the developer simply test every website on the internet.
> Yay, "our users are our beta-testers" hard at work.
That is kind of part of the bargain when you download a version of the browser explicitly labeled as a beta.
> How about devs evaluate a change by doing some testing, instead of using users as guinea pigs?
"Who would pay for it ?" Sincerely, Microsoft™
Even Microsoft managed to figure that out and if Teams or Outlook get new look, there is an option to use it or switch back to the old one.
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.
Yes, the user should ultimately have the final say about what colors, fonts, and sizes are used by their browser. We've handed way too much control over to the web developers. Web sites don't have to be pixel perfect. If I want to render text using Comic Sans by default, that shouldn't "break" anything.
> We've handed way too much control over to the web developers.
We lost this battle by 1999. And again when we started to deliver full web applications instead of documents.
I wish we had a second protocol that was more document and information focused. Something that gave zero control over programming or layout to providers.
I just want to exchange information P2P in a dense swarm approximating modern social media. I want to use my own client configured how I like it to choose what to ingest and how to flag it and present it.
>Something that gave zero control over programming or layout to providers.
Without layout or programming (functionality)...is that not just json??
And if you consider "structure" to be "layout"...then...a txt file?
Unf I don't see the point here. You're basically just describing an api endpoint and a custom client.
I'm describing email, RSS, bittorrent, IRC, etc. Protocols.
we do have such protocols. gopher and more recently gemini are the most popular competing standards
Who are we kidding. With those as our choices, it's no wonder most people just use the face book.
Hyper scale businesses captured most of the internet's value and humans and turned tech into a series of walled gardens for eyeball attention doom scroll maximization. Retweeting the for you page is what some committee of product managers decided was best for us all. Who are we to question the architectures of power?
It almost sounds like a perverse weird utopia to imagine a world where we controlled all of the information flows ourselves. I can't think why we should have all the power.
the internet has become more accessible both to consumers and people trying to sell a product. it has become crowded in "the market" you refer to. but all the good things all still there, and are doing much better than they were. i still use all of those protocols and a bunch of newer ones.
https://en.wikipedia.org/wiki/Gopher_(protocol)
I remember when the web came out, I said "This is just a prettier gopher." Seeing the end result of 30 years of web development, I kind of wish it stayed just a prettier gopher.
> If I want to render text using Comic Sans by default, that shouldn't "break" anything
Not sure how we could expect users to switch between whatever font they want, and things not breaking.
Different fonts both appear and have different sizes, so what might look perfect with one font (a button where the text is aligned in the center vertically/horizontally), can look massively different with another (say the font's characters are wider, so now the text either overflows or breaks into two parts, making the button "broken").
Pixel-perfect alignment shouldn't be a goal. The web is for documents.
What I'm talking about isn't just "pixel perfectness" but layout of said document which breaks depending on the characteristics of the font.
the point is that there should be no layout to be broken in the first place.
The rest of the world has decided that the web is for applications at least as much as it is for documents.
The fix is called reset.css. Allows you to skip headlines like subj and only emotionally react to the "but you already have an app platform, it's web, shtupid" and "you should feel bad about your choices" split around your practical needs.
Awful thing. You can recognize sites using it by missing margins in lists etc.
"you should feel bad about the choices that led you to that point in your life" - I suggest you find help to deal with the bitterness you have inside of you.
I suggest you examine the state of the industry and the garbage that’s passed off as reasonable these days and ask yourself whether what you perceive in my comments is bitterness.
The garbage that dominates the web has everything to do with centralization of power, and nothing with HTML vs JS. The former is a people problem and the latter is just tech.
And what is your proposed alternative? A bunch of native apps? Qt?
Definitely, even though Web + distributed computing pays the bills, I rather have apps + distributed computing when given the option.
It worked perfectly fine until browser companies decided they wanted more than to be renders for hypertext documents.
Yes, apps, which web pages aren’t no matter how much web designers want to pretend they are.
For many places where apps would previously be accepted users don't want native applications anymore.
For work other than some very industry specific high performance software most businesses software is web based, and users ( those paying the bills anyways ) want them to be web based because it is much more portable and easy to deploy.
They actually are though, in reality. Your point is what should they be, not what they actually are. The truth of the situation is that webpages _actually are_ applications now, due to the new features the browsers have added to facilitate that
I actually work at Qt and many of our new products are web apps
Web pages mostly aren't applications though. Like people will sometimes post links to corporate engineering blogs here that require javascript (Uber comes to mind). It's purely a document; there's no interactivity at all. Making it an "application" is just incompetence (it's more expensive to develop and gives a worse user experience).
It might be true that applications actually are web pages now (e.g. Slack, WebEx), but I almost never encounter web pages that are actually applications.
That’s too bad, but not unexpected given that Qt’s itself a non-native toolkit anywhere other than Linux that developers on those other platforms shouldn’t touch.
Okay so you actually have no cross platform suggestion??
Cross-platform frameworks are inevitably crap. If you really need to run an application on multiple platforms, write a cross-platform core and implement the human interface atop it for each platform using each platform’s native frameworks and languages.
The result is always a better product with happier users. If you don’t want to invest in that, you should at minimum be willing to admit to yourself that you’re OK with giving your users something subpar because it’s to your advantage to do so.
HTML + CSS + JS :^)
> 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.
Sure they are, they’re just not sexy. And making this change will ultimately save orders of magnitude more than the cost.
I got stuck trying that. To facilitate non JS by default my products are checkboxes and the checkout button submits the form (it is a spa). This works well but navigating back the user is presented with an "error" page asking if they want to submit the form again. Is there a solution for that?
I have done this in projects with POST forms: ”To avoid the resubmit warning when hitting back, use the Post/Redirect/Get pattern: after a POST, redirect with a 303 to a normal GET page. The browser skips saving the POST in history, so back just takes you to the form without complaining.”
I thought that was the normal pattern, either rendering the form again when there's an error or redirect to the correct page in case of success.
Yeah, it's just been a while so I felt sketchy advicing something that might have changed.
The usual way to deal with it is to respond to form submissions with an HTTP redirect to another page. The user can still hit the back button, but the scary popup won't occur.
However, you run the risk of the user re-submitting the form anyway. Since this is involving orders and money, you may want the order confirmation / submit page to have a nonce or temporary ID representing the checkout session in the URL such that, upon revisiting that page, you can lookup the order status on the backend and redirect them to the order success page again.
This will prevent re-submission but still be confusing for the user. Why even allow submitting when navigating back? If the order has been submitted already, the submit button should be greyed out with a message saying that the order has been submitted already.
The original task was to do this without JS, so my first guess would be: Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server.
This is why I suggested the URL for the submission page be unique- having a session nonce / token or similar. That way, once the user checks out you invalidate the checkout session, and if the user hits the back button you redirect them to the appropriate page.
I specifically called out the issue of re-submitting certain forms and proposed the above solution. I don't think relying on cache headers is going to be sufficiently reliable.
I'm not arguing against a re-submission check. You'll need that anyway to prevent attackers from bypassing the browser and messing up your data.
But even with a nonce and a re-submission check, the cache headers are essential to make sure that when the user presses the back button, they'll see a greyed-out submit button. If the browser does not reload that page, the button will still be clickable. It won't work correctly because the re-submission check will fail, but a clickable and guaranteed non-functional button is very bad UI.
The latter is one of the main reasons that we have so much JS/SPAs. Sure, you can build an application without it that is somewhat functional, but the UI will be low-quality -- even if this particular example might be fixable with cacheability headers.
There is no re-submission check. When the user hits the back button, and requests the HTML from the server, the serve responds with a redirect. The user never sees the expired cart.
> Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server
And how would one do that without using JS?
Which part exactly?
Re-loading the page on navigating back would be done using cacheability headers. This is the most shaky part, and I'm not sure if it is possible today. If this does indeed not work, then this would be one of the "things that Javascript has solved that the non-JS web is still stuck with" I meantioned in my other post, i.e. one of the reasons that JS is more popular than non-JS pages today.
Identifying the order using an ID in the URL is standard practice everywhere.
When the order page gets requested, the server would take that ID, look the order up in the database and see that it is already submitted, responding with a page that has its submit button disabled.
The must have js part for me starts where one can open the store in multiple tabs then add and remove things on the first two and check out on the 3rd tab.
The user you’re replying to thinks the web is the wrong tool for any app
There are real websites people rely on that don’t work without JavaScript - and ones that depend on the h1 size too.
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.
You have now stated that "those people should feel bad" for the second time. Personal attacks will hardly bring any change into this world. I'd instead suggest that you propose actual ways to solve the same problems that Javascript-based SPAs have solved which the non-JS web is still stuck with.
Just add a matter of precision, personal attacks won't generally improve the world on the overwhole aftermaths. But they do generally change the world into a less pleasant place to live in.
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.
I made a web game that's simply not possible without js. Is it your contention the it simply shouldn't exist? Lots of people seem to enjoy it and I think they'd be disappointed.
And you are failing to observe a difference between what should happen and what has actually happened.
Changing the latter costs money - time from people’s lives.
> And that’s a bad thing
Why?
You’ve given no argument that this actually is “abuse”
At a certain point in your career you start realizing how little that is.
Actually the more I’ve gone in my career the more I’ve realized we underestimate the cost of changes. Getting vendors to change a single line of code can be incredible amounts of money.
> 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.
The web is explicitly and intentionally a software distribution platform. JavaScript is a web standard and is no less “part of the web” than HTML and CSS. You’re f
Nah.
Should Gmail never have been created as a web page? How about Google Maps?
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.
you are both right. the decision to make this change is wrong in the first place
All three of you are wrong, computers were a mistake.
In the beginning, the universe was created. This has made a lot of people very angry and is widely regarded as a bad move.
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.
Chrome doesn't implement the change yet, only the deprecation warning. So you can check the console in devtools or run a Lighthouse check.
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.
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.
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.
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.
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.
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.
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.
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?
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.
> 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.
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
This is a list of variations:
https://chromeenterprise.google/policies/
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.
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.
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.
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.
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.
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.
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.
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.
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
Good point! We've adjusted the plan so that it's 100% of beta (starting today). Thanks.
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
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.
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.
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.
Yes.
> 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.
It shouldn't. It's part of an anti-feature called "studies": https://support.mozilla.org/en-US/kb/shield
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.
They shouldn’t be tinkering around in my computer.
> 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/
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.
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.
Nobody tell him about the experiments tab
For gradual feature roll out there should be a clear success or failure criteria and also the feedback loop.
What are they?
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.
How do you think the other browsers roll out changes...?
To the downvoter: they do A/B testing and staged rollouts... nobody at that scale updates 100% in one go.
Easy, spin up 20 VMs, find the one that's different.
Those in charge of Firefox / Mozilla foundation look as if they are trying to make Firefox irrelevant
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.
Good news! Firefox is open source and you can provide your own fixes if you feel the official triage process is taking too long.
So your assumption is that non bugfix changes in a software are only allowed when all bugs are fixed, or what?
What is your bug?
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.