[HN Gopher] Default styles for h1 elements are changing
___________________________________________________________________
Default styles for h1 elements are changing
Author : soheilpro
Score : 342 points
Date : 2025-04-11 02:14 UTC (20 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| codedokode wrote:
| > The plan is to roll out to 5% of users on the Firefox 138
| stable release, ramp up to 50% of users
|
| What an awful idea. How is a web developer supposed to test the
| website when he and user might have different browser behaviour?
| It looks like someone read about deployment at Facebook and
| wanted to implement the same thing without any valid reason.
| Firefox is not a server-side software and this style of
| deployment doesn't make much sense.
| spcebar wrote:
| In theory a web developer is already overriding these styles,
| and if they're not, they can. Default browser styles are never
| to be taken for granted.
| roenxi wrote:
| Mozilla doesn't agree with you; if they thought that was true
| they wouldn't do the weird phased rollout to stable.
|
| Although I agree with codedokode insofar as I don't see how
| the phased rollout _in stable_ could possibly help. Hopefully
| they 've thought of something I haven't otherwise it is
| silly.
| econ wrote:
| You shouldn't but there are many sites that assume the
| default font is black and the default background is white.
| (I'm sure I forgot to set them myself.)
|
| There are [to] many ways to set the font size. I don't even
| know which on is the correct choice, if there is such a
| thing.
|
| Maybe not trying to control it is the best approach? How can
| one tell?
| rendaw wrote:
| The fact that every webdev carries around/trades personal
| "reset" stylesheets to undo everything the browser does by
| default is insane. It really highlights the disconnect
| between W3C and reality.
| ryandrake wrote:
| I think the fact that every webdev feels the need to
| override the user's agent and impose their own idea of what
| size a H1 should be is, well, kind of imposing. I might
| want to make H1 be 50 point comic sans. This should not
| matter to the web developer.
| TylerE wrote:
| It matters because we're the one that has to deal with
| ticket when user complains that their tweaked-to-within-
| an-inch-of-its life system inevitably breaks the world.
|
| The problem isn't you per say, it's the 5000 people that
| mis-follow some YouTube video because it looks cool
| without it actually understanding what they're changing ,
| how to undo it, or what the implications are.
| codedokode wrote:
| I don't understand how one can design a website that
| would survive arbitrary style changes. I think that is
| unrealistic, so the designer should expect all default
| styles to be standard. And if the user has too much free
| time to change the font size then it is their own
| problem; my suggestion is that they simply use reader
| mode and change the styles there.
|
| I would like to remind that some time ago browsers
| allowed to change the default font size; it never worked
| well so Opera started to scale the whole page instead.
| Other browsers followed it.
|
| Android browsers seem to repeat the same mistake by the
| way: they override developer's styles when the user
| changes font size in OS accessibility settings.
| ryandrake wrote:
| I mean, it's my computer. I should ultimately be in
| control of how a document renders. I might need larger
| text due to poor eyesight, or need to use a screen
| reader. Or I might just be irritated that the web
| developer just up and decided that light gray on dark
| gray text looked cool (it doesn't, it barely can be
| read). Or I might want to scroll with my keyboard because
| a mouse is painful to my RSI. If I go out of the way and
| set up accessibility settings, I would expect all
| applications on my device (including the web browser) to
| respect those settings.
| beeflet wrote:
| I guess you could override the styles to whatever you want to
| keep it consistent, and then once the update rolls out to
| enough users you can stop overriding the styles if you want.
| zcorpan wrote:
| Yes.
| wnevets wrote:
| > How is a web developer supposed to test the website when he
| and user might have different browser behaviour?
|
| Any web developer that would have an issue with this is already
| overriding the default styling.
| ack_complete wrote:
| Bigger problem is when users run into a problem and can't find
| information about it because others can't reproduce it. I ran
| into this when they ran an A/B test on removing the search box
| and it drove me crazy that no one else seemingly had the same
| behavior, until I found and disabled the A/B test plugin.
| foolfoolz wrote:
| this is clearly an edge case and most (all?) modern websites
| will not run into any problems. this is a very reasonable
| change given the impact
| mmis1000 wrote:
| In practice, it's like not even one web developer would have
| problem. The default h1 style on web is quite disgusting in
| general, mostly with extremely big font size and wide padding.
| Made it very unusable on mobile devices. Without overriding it,
| you should already have problems.
| kmijyiyxfbklao wrote:
| That situation will happen no matter how they do the release.
| There just has to be an easy way to tell if you have the change
| or not.
| rvba wrote:
| Those in charge of Firefox / Mozilla foundation look as if they
| are trying to make Firefox irrelevant
| not_a_bot_4sho wrote:
| > Firefox is not a server-side software and this style of
| deployment doesn't make much sense.
|
| How does safe velocity not apply to client apps? We've been
| doing this for decades.
| benatkin wrote:
| It shouldn't. It's part of an anti-feature called "studies":
| https://support.mozilla.org/en-US/kb/shield
| not_a_bot_4sho wrote:
| I'm still not following.
|
| I get studies and exp. But that's different than rolling
| out a default behavior to all users, which still requires
| safe velocity guardrails so you don't Crowdstrike yourself.
| benatkin wrote:
| They shouldn't be tinkering around in my computer.
| eschaton wrote:
| A web page's behavior should be independent of any particular
| styling of the hierarchical elements used to represent the
| document it's presenting.
|
| Just like any web page should work perfectly with JavaScript
| disabled, it should work perfectly with a user-supplied style
| sheet.
|
| If you're making a web page that has this problem, what you're
| making should not be a web page, and you should feel bad about
| the choices that led you to that point in your life.
|
| It will take a while to fix this problem in our industry since
| we've waited so long on it, but the best time to start is now.
| grandempire wrote:
| > Just like any web page should work perfectly with
| JavaScript disabled
|
| And the problem is neither of those things are true in
| reality. So in real life a change like this can cost the
| economy millions of dollars.
| eschaton wrote:
| Sure they are, they're just not sexy. And making this
| change will ultimately save orders of magnitude more than
| the cost.
| grandempire wrote:
| There are real websites people rely on that don't work
| without JavaScript - and ones that depend on the h1 size
| too.
| eschaton wrote:
| And that's a bad thing, and the people involved in making
| those sites should feel bad and do something about their
| mistakes rather than just shrug. And we should call them
| what they are: Mistakes, abuses of the web.
| toast0 wrote:
| 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.
| moring wrote:
| 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.
| psychoslave wrote:
| 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.
| grandempire wrote:
| 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.
| bowsamic wrote:
| > And that's a bad thing
|
| Why?
|
| You've given no argument that this actually is "abuse"
| mvdtnz wrote:
| 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.
| econ wrote:
| 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?
| savolai wrote:
| 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."
| skydhash wrote:
| 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.
| savolai wrote:
| Yeah, it's just been a while so I felt sketchy advicing
| something that might have changed.
| zdragnar wrote:
| 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.
| moring wrote:
| 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.
| jpc0 wrote:
| > 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?
| moring wrote:
| 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.
| zdragnar wrote:
| 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.
| moring wrote:
| 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.
| zdragnar wrote:
| 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_.
| bowsamic wrote:
| The user you're replying to thinks the web is the wrong
| tool for any app
| hiddencost wrote:
| At a certain point in your career you start realizing how
| little that is.
| grandempire wrote:
| 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.
| tshaddox wrote:
| > 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
| eschaton wrote:
| Nah.
| tshaddox wrote:
| Should Gmail never have been created as a web page? How
| about Google Maps?
| bowsamic wrote:
| And what is your proposed alternative? A bunch of native
| apps? Qt?
| eschaton wrote:
| Yes, apps, which web pages aren't no matter how much web
| designers want to pretend they are.
| bowsamic wrote:
| 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
| eschaton wrote:
| 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.
| bowsamic wrote:
| Okay so you actually have no cross platform suggestion??
| eschaton wrote:
| 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.
| psini wrote:
| HTML + CSS + JS :^)
| ndriscoll wrote:
| 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.
| jpc0 wrote:
| 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.
| pjmlp wrote:
| 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.
| wruza wrote:
| 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.
| codedokode wrote:
| Awful thing. You can recognize sites using it by missing
| margins in lists etc.
| ryandrake wrote:
| 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.
| echelon wrote:
| > 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.
| Incipient wrote:
| >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.
| echelon wrote:
| I'm describing email, RSS, bittorrent, IRC, etc.
| Protocols.
| jrvieira wrote:
| we do have such protocols. gopher and more recently
| gemini are the most popular competing standards
| echelon wrote:
| 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.
| jrvieira wrote:
| 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.
| joquarky wrote:
| https://en.wikipedia.org/wiki/Gopher_(protocol)
| ryandrake wrote:
| 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.
| diggan wrote:
| > 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").
| milesrout wrote:
| Pixel-perfect alignment shouldn't be a goal. The web is
| for documents.
| diggan wrote:
| What I'm talking about isn't just "pixel perfectness" but
| layout of said document which breaks depending on the
| characteristics of the font.
| moring wrote:
| The rest of the world has decided that the web is for
| applications at least as much as it is for documents.
| iamsaitam wrote:
| "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.
| eschaton wrote:
| 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.
| moring wrote:
| 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.
| arp242 wrote:
| > How is a web developer supposed to test the website when he
| and user might have different browser behaviour?
|
| So that is always going to be the case with a change like this,
| simply because people use older versions, use different
| browsers, etc.
|
| If this change breaks popular-site.com then it will continue
| work fine for 95% of people, and it breaks for "only" 5%, one
| of whom will (hopefully) report it. This allows the Firefox
| people to test the waters to make sure it's not going to
| horrible break things and break things for too many people.
| lynx97 wrote:
| Yay, "our users are our beta-testers" hard at work.
|
| How about devs evaluate a change by doing some _testing_ ,
| instead of using users as guinea pigs?
|
| I agree with parent, this is an awful approach.
| anon7000 wrote:
| The scale is far too big. You cannot take into account the
| millions of permutations of websites and browser extensions
| when testing changes like this.
| frosted-flakes wrote:
| They're not testing the browser, they're testing the _Web_.
| Testing in the real world with real users is the only way
| to adequately probe the effects of potentially breaking
| changes like this.
|
| This is not new either. Many such changes have been
| reverted after discovering that they broke more things than
| expected. One example is the Object.groupBy static method,
| which was initially Array.prototype.group.
| lynx97 wrote:
| > 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.
| arp242 wrote:
| 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.
| codedokode wrote:
| You can test on special testing versions. Browser
| instances behaving inconsistently with the same version
| only add more problems to developers.
| eru wrote:
| > 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.
| ozim wrote:
| Second that - I assume that they did asnmuch as they
| could and this is just defense in depth one additional
| step.
| codedokode wrote:
| That is not defence in depth, that is causing annoyance
| to web developers.
| joquarky wrote:
| 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.
| hulitu wrote:
| > How about devs evaluate a change by doing some testing,
| instead of using users as guinea pigs?
|
| "Who would pay for it ?" Sincerely, Microsoft(tm)
| mvdtnz wrote:
| Yeah why didn't the developer simply test every website on
| the internet.
| zcorpan wrote:
| 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-197
| 7... https://github.com/whatwg/html/issues/7867#issuecommen
| t-2595...
|
| The next step is either rollout or ship directly.
| selcuka wrote:
| > 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.
| aarond0623 wrote:
| 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.
| codedokode wrote:
| 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.
| 827a wrote:
| 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.
| zcorpan wrote:
| 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.
| madeofpalk wrote:
| > 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.
| crumpled wrote:
| Usually we can use feature flags. Browser makers also have
| beta versions or their browsers available for devs.
| piokoch wrote:
| 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.
| notatoad wrote:
| if you're a web developer, it's always a good idea to keep a
| copy of the beta release installed to test your sites on, so
| you can see these changes before it hits the stable release.
| warpech wrote:
| 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
| Borgz wrote:
| From the linked article:
|
| >To test in Firefox with the new behavior, set
| layout.css.h1-in-section-ua-styles.enabled to false in
| about:config.
| tshaddox wrote:
| 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/
| paulddraper wrote:
| 1. Users are already going to see different behaviors,
| depending on their browser version. It will have to work for
| both.
|
| 2. Anyone that cares a lot how h1 looks is going to set the
| style themselves, rather than relying on whatever the browser
| default happens to be.
|
| 3. Bad browser defaults have (not inaccurately) been blamed for
| people excessively crapping out CSS.
| ramesh31 wrote:
| Nobody tell him about the experiments tab
| jiggawatts wrote:
| Even on the server side it can be annoying.
|
| For example, I tested something in my own private Azure
| Subscription, but the feature was simply missing in the
| customer subscription.
|
| Microsoft was enabling features randomly without even
| documenting this or showing any kind of user-visible indicator
| of what feature set was available or not.
| input_sh wrote:
| > 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/
| jeroenhd wrote:
| Firefox dev edition is nice but when changes are rolled out
| gradually like this, forcing the setting in about:config is
| the only reliable way. Firefox runs experiments on its users
| in dev edition as much as it does in stable.
| jeroenhd wrote:
| In case you were actually looking for an answer to your
| question, it's in the article:
|
| > To test in Firefox with the new behavior, set
| layout.css.h1-in-section-ua-styles.enabled to false in
| about:config.
|
| Gbd article doesn't specify how to test in Chrome (probably
| something in chrome://flags), but you can read the deprecation
| warnings dumped into your console. You may need to enable them
| in your default log level. If so, there may be a lot of other
| behaviour that you'll probably want to fix.
| zcorpan wrote:
| Chrome doesn't implement the change yet, only the deprecation
| warning. So you can check the console in devtools or run a
| Lighthouse check.
| tempay wrote:
| From the article:
|
| > Since Firefox 136, developers will see a console warning for
| h1s in article/aside/nav/section without author-defined font-
| size or margins
|
| Seems like it should be fairly obvious for any dev that tries
| to look into it even if they're not part of the cohort with the
| new behavoir.
| zcorpan wrote:
| To test in Firefox with the new behavior, set layout.css.h1-in-
| section-ua-styles.enabled to false in about:config.
|
| Rolling out potentially risky changes in this way is not new,
| and is also a strategy that other browsers employ. It allows
| for course-correcting if necessary and is less disruptive than
| shipping to 100% of users directly.
| zx8080 wrote:
| For gradual feature roll out there should be a clear success or
| failure criteria and also the feedback loop.
|
| What are they?
| zcorpan wrote:
| The feedback loop is Firefox's "report broken site" in the
| Help menu. Success is there are no reports about broken sites
| due to this change, or the breakage is minor -- differently
| sized headings and different margins on some pages is
| expected and is acceptable. Sites becoming unusable is not
| acceptable.
| onion2k wrote:
| Test what exactly? If your test is "The page renders how I
| expect when using the browser's default styling" then that's a
| terrible test, because that can change at any time without your
| control. You just have to accept what that is. There isn't a
| valid test for it.
|
| The fix for this is to define your own H1 margin and font size
| and then to test that the site looks correct with those values.
| Your test is should be that _your_ styling works, not that
| Firefox 's styling works. That'd be like testing a dependency.
| You shouldn't be doing that.
| donnachangstein wrote:
| Easy, spin up 20 VMs, find the one that's different.
| badgersnake wrote:
| Replacing doing actual testing with 'just give it to 5% of
| users and see who screams' is not an industry trend I'm on
| board with.
|
| Sure, it's a lot cheaper but also, you're supposed to ship
| things that actually work.
| K0nserv wrote:
| The indignation in this thread and from OP is ridiculous,
| especially when all the ire is aimed at Firefox, who are doing
| the same thing all browser makers do.
|
| When you are changing the very fabric of the whole web, rolling
| things out in a gradual, controlled way is paramount. Not just
| because people can find and report issues before roll-out
| reaches 100%, but also because browsers collect telemetry on
| features and how they work in the wild that can be used to
| gauge the effect.
| jrvieira wrote:
| you are both right. the decision to make this change is wrong
| in the first place
| diggan wrote:
| All three of you are wrong, computers were a mistake.
| acheron wrote:
| In the beginning, the universe was created. This has made
| a lot of people very angry and is widely regarded as a
| bad move.
| oblio wrote:
| How do you think the other browsers roll out changes...?
| oblio wrote:
| To the downvoter: they do A/B testing and staged rollouts...
| nobody at that scale updates 100% in one go.
| WhyNotHugo wrote:
| Even if they rolled out to 100% of the users on day 1, you'd
| sill have an heterogeneous audience with all the folks using
| older versions of Firefox. It likely takes (at least) many
| months before 99% of Firefox users upgrade to a any specific
| release.
| tony-allan wrote:
| I haven't really thought about sectioning elements (<section>,
| <aside>, <nav>, and <article>) and the cool behaviour of a tag
| like <h1> when these tags are nested.
| pests wrote:
| Well it's getting removed so only useful if you want to
| recreate the css they are removing.
| tony-allan wrote:
| Oops. Perhaps I need to read the article again!
| radicalriddler wrote:
| 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 wrote:
| 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.
| superkuh wrote:
| 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 wrote:
| 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 wrote:
| The article seemed to repeatedly suggest that any <h1>
| without a font size set would be a warning, but reading more
| closely I'm pretty sure it's only talking about <h1> nested
| within <section> etc. (So I believe Lighthouse and Firefox
| are both already doing what you describe in the last
| sentence.)
| alexpetros wrote:
| I'd love the article to clarify this, because it stuck out
| to me as well. But as you pointed out, I think that's what
| they meant: the lighthouse warning is called
| "H1UserAgentFontSizeInSection"
| mjevans wrote:
| I still think even one within a section (or even div like
| nested sections) shouldn't be a warning... but I hadn't
| heard of <section> until today (seemingly it's been in
| browsers for decades, I just hadn't seen it USED anywhere)
| so I'm not sure if that implies something other than a
| logical structural block. From the context it seemed like a
| different type of div or span.
| Cthulhu_ wrote:
| "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.
| marcosdumay wrote:
| 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.)
| zcorpan wrote:
| 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.
| TZubiri wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| <input type="button" value="Submit">
| Skeime wrote:
| Yes, and this is also a mistake, hence the <button>
| element.
| econ wrote:
| ::after { content: attr(id) }
| Ericson2314 wrote:
| 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 wrote:
| > 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 wrote:
| OK yes, fair. Anything that is displayed needs its own
| attributes, and therefore must be its own tagged thing.
| Good point.
| sureIy wrote:
| 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
| Osmose wrote:
| 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.
| skerit wrote:
| 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 wrote:
| It's better because it's explicit. That's it.
| qw wrote:
| I would prefer to use a neutral <h> tag, that was proposed
| in the xhtml2 specs. It always made more sense to let the
| browser infer the place in the hierarchy.
| dspillett wrote:
| I've seen this done with one of the existing tags and
| appropriate nesting. <h1> for masthead, <h2> for major
| subdivisions in a huge page (essentially sub-mastheads),
| then <h3> for everything else with styling (and nesting
| in ToCs and such) being dictated either by how nested
| they are in <section> tags (or <div>s with an appropriate
| class). H3 here becomes a neutral header, and h4+ are
| just not used (nor is H2 in short/medium pages).
| Popeyes wrote:
| 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.
| Ferret7446 wrote:
| 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.
| AlienRobot wrote:
| 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.
| AlienRobot wrote:
| 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>.
| MBCook wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| It has been in the spec since 2009:
| https://github.com/whatwg/html/commit/0ed655652d52f0ab068fcb...
| _joel wrote:
| Perhaps to address screen-readers and broken semantics of a
| page?
| GavinAnderegg wrote:
| 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
| quotemstr wrote:
| It's a shame that the outline algorithm didn't succeed. Why
| _shouldn 't_ we be able to compose content from different sources
| arbitrarily? Why shouldn't I be able to write an <h1> fragment
| and have it mean "top-level heading OF MY CONTEXT" instead of
| making an assertion about global document context that I can't
| control?
| zarzavat wrote:
| The outline algorithm didn't succeed because it was too
| complicated and hard to understand for the common case.
|
| You can define your own styles and have a similar behaviour.
| teo_zero wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| XHTML2 had some good ideas.
| zcorpan wrote:
| There's a new proposal to address this:
| https://github.com/whatwg/html/issues/5033
| russellbeattie wrote:
| 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.
| tommica wrote:
| Huh, the change seems reasonable, though changing defaults is
| always going to create friction. I always thought H1 looked the
| same no matter what context.
| penguin_booze wrote:
| So many words but no example screenshot showing what the changes
| might look like?
| zcorpan wrote:
| Good point. Now fixed!
| leakycap wrote:
| The screenshots helped me understand it... turns out the
| "change" will work how my brain already thought it worked.
| successful23 wrote:
| Honestly, this feels like a long-overdue cleanup. The outline
| algorithm always sounded good on paper, but in practice, it just
| created confusion - especially when different tools and screen
| readers treated headings differently.
|
| Dropping the UA styles makes things more predictable: <h1> means
| <h1>, no matter where it lives. Yeah, the partial rollout across
| browsers is going to be rough - debugging across inconsistent
| browser behavior is going to be a nightmare. Still, if this
| pushes devs to rely less on implicit styling and more on their
| own structure, they can now take control of heading semantics
| more properly.
| thund wrote:
| Interesting stuff, great for Accessibility! Maybe some
| screenshots could have made the article more... accessible.
| zcorpan wrote:
| Fixed, thanks.
| ricardobeat wrote:
| Keeping track of heading levels across sections and components is
| a challenge, rarely taken care of in most websites.
|
| Back we go to completely broken document outlines. Not that we
| ever fixed it in reality, as the announcement points out, but
| this is a big admission of defeat for the semantic web.
| Cthulhu_ wrote:
| ? 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 wrote:
| > if the outline is broken, the website you're viewing uses
| default styles and relies on behaviour that was removed in
| 2022
|
| By "outline" in this context I'm referring to the computed
| hierarchy of heading elements in the content. Not the styles.
|
| What I meant is that removing the default styles is an
| admission of defeat, that we are giving up on the whole idea
| of automatically leveled headings - it's now _definitely_ not
| going to be implemented by any software.
| Skeime wrote:
| 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 <h _n_
| > headings and <h> elements nested in _n_ articles
| /sections/..., would have been great.
|
| Essentially, it was hopeless to expect that designers would
| adapt their stylesheets to style headings based on the number
| of sections surrounding them. And if the visual styles don't
| adapt, nobody will use the outline algorithm to choose their
| headings.
|
| (Which is sad, because the algorithm makes content nicely
| nestable. With the algorithm, I can take an article that was
| independent and use it as a section in a larger work, and the
| headings will automatically adapt. Though, as a pet-peeve of
| mine, nested IDs would also be somewhat necessary for this, so
| that it's fine to have two embedded articles which both have a
| section with an ID #introduction.)
| donnachangstein wrote:
| This is great news, because it must mean all bugs in Firefox have
| been fixed!
|
| <checks Bugzilla>
|
| Nope, my two year old bug is still being ignored.
| zuhsetaqi wrote:
| So your assumption is that non bugfix changes in a software are
| only allowed when all bugs are fixed, or what?
| lexicality wrote:
| Good news! Firefox is open source and you can provide your own
| fixes if you feel the official triage process is taking too
| long.
| zcorpan wrote:
| What is your bug?
| blahyawnblah wrote:
| I've always been under the impression that there was only one
| <h1> per page
| MindTooth wrote:
| Yeah. Came to ask the same. Always been my understanding.
| moebrowne wrote:
| 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/...
| reddalo wrote:
| It's just a SEO "good practice", but it's perfectly fine to
| have more than one <h1> tag.
| ssl232 wrote:
| 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 wrote:
| Not that I would know but I'd assume it's just one of those
| early internet things. Like somebody decided that 6 levels of
| headers were good enough hence h1 through h6, and well you need
| to be able to distinguish them by size but also h1 shouldn't be
| too big so h5 and h6 being smaller than body text is a good
| compromise?
|
| It's not like we had decades of UI experience then, so it would
| surprise me if the thought process was much deeper than that.
| bslalwn wrote:
| Does this mean there are people out there who don't use a
| reset.css stylesheet? I find that to be spooky.
| jpc0 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| zcorpan wrote:
| 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.
| p4bl0 wrote:
| 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 wrote:
| that exists
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
| p4bl0 wrote:
| I don't understand <header> to be a heading element (i.e., a
| section title). Instead it is a semantic container for
| heading elements: title, date, author, maybe category/tags,
| etc. To me, the heading level used inside a given <header> is
| a distinct, somewhat orthogonal thing (at least in how it is
| decided, from the nesting level or the tag name).
| ralferoo wrote:
| Stuff like "Alongside the changes in browser styles, page
| auditing tools like Lighthouse now flag cases of <h1>s without
| defined font-size as bad practice." make me pretty certain this
| is the wrong change to make.
|
| HTML is about semantic markup, not visual markup. Features like
| CSS were introduced because people started trying to use the
| semantic markup to achieve specific visual results, and so CSS
| was the solution to allow HTML to continue to be semantic markup
| and CSS to optionally format it if people wanted specific non-
| default things.
|
| As a reader, I don't want page authors to start hard coding sizes
| into these elements, because then they'll be more likely to
| choose non-default values to make their page stand out a bit
| more.
|
| Additionally, the current behaviour (which I'd never particularly
| considered before) sounds entirely reasonable - if I take some
| existing markup and blockquote it in some container, I'd expect
| the headings to shrink as they're now all sub-elements of some
| other section.
| zozbot234 wrote:
| 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 wrote:
| completely defeating the purpose of html semantics in the
| first place
| maccard wrote:
| Honestly that ship has long since sailed.
| ramses0 wrote:
| 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...
| HelloNurse wrote:
| 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>
| galleywest200 wrote:
| > 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.
| tallytarik wrote:
| 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.
| albedoa wrote:
| 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.
| tingletech wrote:
| The error is named `H1UserAgentFontSizeInSection` --
| makes it seems like it would only fire for an H1 used in
| a section?
| TeMPOraL wrote:
| > _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 wrote:
| > "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 wrote:
| > _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 wrote:
| Tailwind feels like the bad old days of style="........".
| And it looks like some weird dialect of Forth code.
| joquarky wrote:
| > 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.
| mryall wrote:
| > 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 wrote:
| 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.
| mykhamill wrote:
| 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.
| joquarky wrote:
| 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.
| marcosdumay wrote:
| 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.
| mhnthrow wrote:
| > 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.
| eadmund wrote:
| > 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.
| drdaeman wrote:
| > 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.
| JohnHaugeland wrote:
| ah, that mozilla commitment to unnecessary changes and backwards
| breakage
| K0nserv wrote:
| All browser makers are making the change together, why are your
| singling out Mozilla?
| zcorpan wrote:
| Someone has to be first. :-)
| Ferret7446 wrote:
| 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.
| pyinstallwoes wrote:
| Yeah exactly. It makes a lot more sense to treat headers
| automatically.
| zcorpan wrote:
| 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 wrote:
| That's a problem with the screen reader implementation. At
| least, according to the previous semantics.
| AlienRobot wrote:
| 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 wrote:
| As of 2022 (when the outline algorithm was removed from the
| spec), it's a problem with your website implementation.
| cassepipe wrote:
| I wish browser embedded something like PicoCSS so that you when
| you would ship a pure html website where you don't care about the
| styling, you'd let the browser figure out styles based on the
| semantics. You choose from a variety of themes and tweak them.
|
| I have checked the websites on CSS naked day. Default styles were
| ok but not great.
| littlestymaar wrote:
| Breaking change to a platform that is ubiquitous like the web are
| always evil.
|
| Sometimes it's a necessary evil (when you have to fix a security
| vulnerability), but here I really fail how it was necessary.
| eek2121 wrote:
| Terrible idea. Why is it that all the big browser makers are
| doing stupid stuff?
|
| I don't want to specify styles for all my content. For some
| content, I want to use browser defaults.
|
| Sure, now it is just H1, but just wait...
| MyOutfitIsVague wrote:
| Then do so. If you want specific styles, then style your
| content. If you don't, then you get whatever the defaults are.
| I really don't think there's much worth complaining about here.
| WhyNotHugo wrote:
| 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 wrote:
| They do if you include <meta name="color-scheme" content="light
| dark">
|
| Also see https://github.com/whatwg/html/issues/5426
| mediumsmart wrote:
| fwiw ... to test the site you can load and read it on a desktop
| and on a phone. if it also passes the validator and jslint
| without error or warning you are half done. It should load within
| 1 second on mobile (pagespeed) have zero errors on wave webaim,
| A+ on securityheaders.com, and full marks on webbkoll.5july.net,
| a proper dmarc reject entry and pass dr-dsgvo webcheck. That
| would be a good start. Oh, and no divs. Not allowed ...
| ryao wrote:
| 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 wrote:
| There is no warning in that case.
| ryao wrote:
| It is a shame the article did not explain that.
| MyOutfitIsVague wrote:
| 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 wrote:
| Nested lists have 0 block-margin and different list-style-type.
| But that seems to be about it...
| dimava wrote:
| tl;dr for those who didn't read the actual article:
|
| They are changing to x h1 { warning:
| semantically questionable }
|
| from /* where x is :is(article, aside, nav,
| section) */ x h1 { font-size: h2 } x x h1 { font-
| size: h3 } x x x h1 { font-size: h4 }
|
| which was removed from spec in 2022
|
| So anyone who doesn't place H1s where they shouldn't have been
| anyways is fine
___________________________________________________________________
(page generated 2025-04-11 23:01 UTC)