Default styles for h1 elements are changing
271 comments
·April 11, 2025Osmose
AlienRobot
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>.
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>!
skerit
I thought it was a good idea and liked using it. I do not see how the old "global" h1, h2, h3... system we still have to use is any better.
mvdtnz
It's better because it's explicit. That's it.
qw
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.
Ferret7446
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.
paulirish
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...
ssl232
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....
schindlabua
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.
ralferoo
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.
mryall
> 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.)
kevin_thibedeau
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.
mhnthrow
> 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.
mykhamill
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.
drdaeman
> 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.
zozbot234
Looks like this change only applies to literal <h1> elements, such that <h2> ... <h6> still preserve the old behavior. If so you can just use the <h2> tag in section-like contexts in place of the older <h1>, and get the same or a very similar outcome.
jrvieira
completely defeating the purpose of html semantics in the first place
HelloNurse
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>
maccard
Honestly that ship has long since sailed.
TeMPOraL
> 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.
diggan
> "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.
TeMPOraL
> 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.
davidw
Tailwind feels like the bad old days of style="........". And it looks like some weird dialect of Forth code.
joquarky
> 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.
zzo38computer
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.
eadmund
> 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.
MBCook
When did that H1 behavior become part of the spec?
I’ve been writing HTML since around ‘95 and don’t remember ever hearing of it before.
I suspect it would confuse the hell out of me if I had run into it. Sounds like a good thing to remove.
jeroenhd
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...).
currysausage
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....
zcorpan
It has been in the spec since 2009: https://github.com/whatwg/html/commit/0ed655652d52f0ab068fcb...
GavinAnderegg
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.
_joel
Perhaps to address screen-readers and broken semantics of a page?
penguin_booze
So many words but no example screenshot showing what the changes might look like?
superkuh
Good. <h1> tag should be <h1> no matter where it is. It shouldn't change; at least not by default. Even better that this change back to the old way will fix a problem for accessibility for screen readers.
mjevans
I agree with this.
Further <h1> with only the default style SHOULD NOT BE A WARNING. At least make it only warn if 'h1's are nested.
sfink
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.)
mjevans
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.
alexpetros
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"
zcorpan
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.
p4bl0
Seems like the proper fix would be to introduce a <h> element with heading level dictated only by the number of <section> nesting. But it's too late for that now I guess.
Anyway, I'm quite surprised to learn all this about <h1> while I've always read everywhere up until today and including on MDN (Mozilla's documentation), that one should use only one <h1> per page.
Now I wonder if and how <section> nesting affects <h2>, <h3>, etc.
JohnHaugeland
p4bl0
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).
quotemstr
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?
teo_zero
While I agree on hierarchical headings, I don't think H1...H6 are the right tools. These represent absolute levels, we would need a means to express "level+1". I think a H tag with no digit would better convey the meaning "heading of the right level as defined by the surrounding SECTION tags".
lblume
But they don't have to represent absolute levels. They could just as easily have represented relative levels, with h2 in a doubly nested section to describe the level today expressed as h4. Dependent on your usecase, this could either be very useful or just mess up your styles a lot.
pjerem
Well I totally agree with you but we don’t have that. h1 was that, but not anymore.
It’s a shame that we basically can’t rely on default styling to structure a simple document .
There are tons of moments in my life and in my career where I wanted to "just publish" some web page with content while not really caring for aesthetics. But even if you write semantically correct HTML without styling, what you get is not neutral and coherent as it should be, on the contrary, it’s all over the place and inconsistent.
brewmarche
XHTML2 had some good ideas.
zcorpan
There's a new proposal to address this: https://github.com/whatwg/html/issues/5033
zarzavat
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.
ricardobeat
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.
Skeime
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.)
Cthulhu_
? No, this removes some magic default behaviour; if the outline is broken, the website you're viewing uses default styles and relies on behaviour that was removed in 2022. It's better to take ownership of styling instead of relying on defaults, this has been true since... the 90's?
The algorithm changed the visuals of headers used in semantics, that is, H1's in lower sections. But software beyond browsers like screen readers would need to add support for this logic too, so that H1's in a section were semantically treated as a H2.
ricardobeat
> 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.
tony-allan
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.
radicalriddler
Validation tools will also tell you if you have an H1 in a <section>, but no H1 outside of the section, because the <section> actually creates it's own scope, thus your page has no H1.
ricardobeat
Looks like that kind of validation was premature. They mention in this article that the “creates its own scope” part was never actually implemented for accessibility, this change brings the display rules back inline with reality.
radicalriddler
Nice, I didn't know that.
The difference between W3C and what browsers actually implement, if you don't laugh, you'll cry.
pests
Well it’s getting removed so only useful if you want to recreate the css they are removing.
tony-allan
Oops. Perhaps I need to read the article again!
tommica
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.
sayheytozoe
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/...
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.