Top
Best
New

Posted by soheilpro 4/11/2025

Default styles for h1 elements are changing(developer.mozilla.org)
368 points | 264 commentspage 2
tommica 4/11/2025|
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 4/12/2025||
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/...

Ferret7446 4/11/2025||
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.

zcorpan 4/11/2025||
It only worked visually. For screen reader users, all headings are level 1. If you switch to using h2 etc, it will be more accessible.
Ferret7446 4/11/2025||
That's a problem with the screen reader implementation. At least, according to the previous semantics.
AlienRobot 4/11/2025|||
It was a problem with the screen reader implementation in 2009 when the semantics were introduced.

In 2025 if no screen reader works right it's a problem with the spec.

zcorpan 4/11/2025|||
As of 2022 (when the outline algorithm was removed from the spec), it's a problem with your website implementation.
pyinstallwoes 4/11/2025||
Yeah exactly. It makes a lot more sense to treat headers automatically.
thund 4/11/2025||
Interesting stuff, great for Accessibility! Maybe some screenshots could have made the article more... accessible.
zcorpan 4/11/2025|
Fixed, thanks.
jpc0 4/11/2025||
> 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...

jillesvangurp 4/11/2025||
It's a weird one. HTML does have a TITLE tag. But it's supposed to go in the HEAD. The BODY does not have a TITLE. Any word processor uses something called a Title (and Subtitle) at the top of your document and then things Heading1 for sections. HTML originally didn't have dedicated tags for this; just h1-h6 (because surely six is enough for anyone). So you get this weird off by one error that arises from the notion that HTML just lacks essential tags. So you use H2 to mean Heading1. Because H1 is reserved for the title. Never mind about sub titles. Not a thing in HTML.

Mostly this is because Tim Berners Lee probably didn't think this one through properly decades ago. And it was never really fixed. These days you can just invent your own tag names and style them of course. Which is a useful trick that is a bit underused. The structural semantics are nice for things like accessibility, SEO, and a few other things but otherwise HTML is a really poor choice of a format to exchange structural information. You generate it from other formats preferably. Writing it manually is a PITA. Even if you are a developer. Things like Markdown exist for a reason (and perpetuate the problem).

Ferret7446 4/11/2025||
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.

chuckadams 4/11/2025||
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.
zcorpan 4/11/2025||
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.

jpc0 4/13/2025||
The argument I was making was what is why would

    <main>
    
    <h1>Main Heading</h1>

    section..h2... Etc

    </main>
    
    <aside>
    
    <h1>Aside heading</h1>

    section...h2...

    </aside>
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.
zcorpan 4/13/2025||
The spec allows multiple top-level headings: https://html.spec.whatwg.org/multipage/sections.html#heading...
MyOutfitIsVague 4/11/2025||
Are there any other elements that change their styling based on position in the document? I've been doing web development for over a decade and I've never even known about this behavior. Seems like a bad default, and I'm not bothered seeing it go away.
zcorpan 4/11/2025|
Nested lists have 0 block-margin and different list-style-type. But that seems to be about it...
WhyNotHugo 4/11/2025||
If we're making breaking changes to the default CSS styles, I wish we'd include default styles for dark mode as well.

Mainly, I'd love for pages without any CSS to render in dark mode when the system+browser are set to dark mode.

zcorpan 4/11/2025|
They do if you include <meta name="color-scheme" content="light dark">

Also see https://github.com/whatwg/html/issues/5426

TZubiri 4/11/2025||
I always thought the headers in html were kind of dumb. I always think of book sections as:

<section name="Animals">

  <section name="Mammals"> Mammals are blabla </section>

  <section name="Reptiles"> Reptiles are blabla </section>
</section>

<section name="Plants">

</section>

<section name="Minerals">

</section>

In this case Animals, Plants and Minerals would be h1, and Mammals and Reptiles would be h2. If you truly wanted to separate representation from content you would do that, as it is you are not really doing that, the h1 and h2 would be creating some kind of explicit open and close tags and hierarchy in a format different than the rest of html.

If someone goes back in time could you kick that Berner's Lee on your way back from killing hitler, correcting the sign on electricity? Thanks. Also send a message to Douglas Crockford if you've got time.

mikepurvis 4/11/2025||
I dunno about this. Attributes are supposed to be metadata, not displayed textual content. Like it's fine to give the anchor for a section as an attr:

    <section id="animals">
      <h2>Animals</h2>
      <p>Here are my animal facts</p>
    </section>
I would feel strange if a browser's built in CSS were reaching into an element's attribute and rendering the text therein as something visible to the reader.
flowerthoughts 4/11/2025|||
I don't think that matters to GP's point. It's the fact that then "name" attribute stays the same no matter the nesting level.

There's already <figure><figcaption></figure> and <table><caption></table> as examples of embedded heading. The difference there being that figure and table elements very rarely nest.

So allowing h in <section><h><section><h></section></section> to become h1 and h2 would make sense.

paulddraper 4/11/2025||||

  <input type="button" value="Submit">
Skeime 4/11/2025||
Yes, and this is also a mistake, hence the <button> element.
econ 4/11/2025|||
::after { content: attr(id) }
sureIy 4/11/2025|||
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
Ericson2314 4/11/2025||
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.

ks2048 4/11/2025||
> 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.

Ericson2314 4/11/2025||
OK yes, fair. Anything that is displayed needs its own attributes, and therefore must be its own tagged thing. Good point.
TZubiri 4/11/2025||
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.

ryao 4/11/2025||
Am I the only one who had no idea that these sectioning elements existed?

  Lighthouse will flag a warning if <h1> is used without a specified font-size.
This seems like a silly warning to give if there are no sectioning elements affecting <h1>.
zcorpan 4/11/2025|
There is no warning in that case.
ryao 4/11/2025||
It is a shame the article did not explain that.
littlestymaar 4/11/2025|
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.

More comments...