Default styles for h1 elements are changing
developer.mozilla.org
developer.mozilla.org
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>.
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 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 like if you removed relative paths and working directories from all OSes. A lot of things become really annoying to do.
[1] https://www.smashingmagazine.com/2011/11/our-pointless-pursu...
[2] https://www.smashingmagazine.com/2011/11/pursuing-semantic-v...
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.
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.
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.)
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.
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.
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.
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.
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>
You forgot to include a font size in your h1's which is what people are complaining about needing to do.
> 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.
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...
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.
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.
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.
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.
> 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.
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.
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.
[1] https://www.w3.org/TR/2010/NOTE-xhtml2-20101216/mod-structur....
Further <h1> with only the default style SHOULD NOT BE A WARNING. At least make it only warn if 'h1's are nested.
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.)
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.
You can define your own styles and have a similar behaviour.
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.
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.
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.)
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.
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.
The difference between W3C and what browsers actually implement, if you don't laugh, you'll cry.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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.
In 2025 if no screen reader works right it's a problem with the spec.
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...
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).
The Web has long departed from that vision however; very few pages, if any, could still be considered documents.
> 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.
<main>
<h1>Main Heading</h1>
section..h2... Etc
</main>
<aside>
<h1>Aside heading</h1>
section...h2...
</aside>
Mainly, I'd love for pages without any CSS to render in dark mode when the system+browser are set to dark mode.
<section name="Animals">
<section name="Mammals"> Mammals are blabla </section>
<section name="Reptiles"> Reptiles are blabla </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.
<section id="animals">
<h2>Animals</h2>
<p>Here are my animal facts</p>
</section>
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.
<input type="button" value="Submit">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.
A reason is that you might want formatting (bold, italics, etc) on the text of a title.
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.
Lighthouse will flag a warning if <h1> is used without a specified font-size.
Sometimes it's a necessary evil (when you have to fix a security vulnerability), but here I really fail how it was necessary.
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…
I have checked the websites on CSS naked day. Default styles were ok but not great.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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.
They are changing to
x h1 { warning: semantically questionable }
/* where x is :is(article, aside, nav, section) */
x h1 { font-size: h2 }
x x h1 { font-size: h3 }
x x x h1 { font-size: h4 }
So anyone who doesn't place H1s where they shouldn't have been anyways is fine
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.
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.
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.
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.
This is totally possible. Many changes to the web platform we abandoned or changed significantly because a couple of websites look a little wonky.
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.
> 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.
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.
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.
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.
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.
Presumably they have done as much of that evaluation as is reasonable already.
It feels to me like usability testing and quality assurance have both joined security and accessibility on the back burner now.
That is kind of part of the bargain when you download a version of the browser explicitly labeled as a beta.
"Who would pay for it ?" Sincerely, Microsoft™
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.
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.
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.
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.
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").
It worked perfectly fine until browser companies decided they wanted more than to be renders for hypertext documents.
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.
I actually work at Qt and many of our new products are web apps
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.
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.
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.
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.
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.
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.
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.
And how would one do that without using JS?
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.
Firefox isn't doing so well on market share, and appearing to be broken isn't going to help.
Changing the latter costs money - time from people’s lives.
Why?
You’ve given no argument that this actually is “abuse”
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
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.
> 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.
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.
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.
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.
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?
Any web developer that would have an issue with this is already overriding the default styling.
https://developer.chrome.com/docs/web-platform/chrome-finch
This is a list of variations:
>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.
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.
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.
> 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.
Sure, it’s a lot cheaper but also, you’re supposed to ship things that actually work.
How does safe velocity not apply to client apps? We've been doing this for decades.
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.
If only there was like a Developer version, perhaps one version ahead of stable: https://www.mozilla.org/en-US/firefox/developer/
What are they?
<checks Bugzilla>
Nope, my two year old bug is still being ignored.