Stuff like "Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice." make me pretty certain this is the wrong change to make.
HTML is about semantic markup, not visual markup. Features like CSS were introduced because people started trying to use the semantic markup to achieve specific visual results, and so CSS was the solution to allow HTML to continue to be semantic markup and CSS to optionally format it if people wanted specific non-default things.
As a reader, I don't want page authors to start hard coding sizes into these elements, because then they'll be more likely to choose non-default values to make their page stand out a bit more.
Additionally, the current behaviour (which I'd never particularly considered before) sounds entirely reasonable - if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
> As a reader, I don't want page authors to start hard coding sizes into these elements …
They mean h1 elements without a font-size specified in CSS (or style attribute) will be flagged as a warning. User agent styles can still override site styles if you want to set one.
> if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
This logic only applied to the h1 element specifically, as it was an attempt to shoehorn some “clever” logic from the abandoned <h> tag proposed in a early draft of HTML5 (which was going to work the way you’d describe for headings at any level), on to the existing h1 element.
(Source: I used to follow the WHAT-WG mailing list closely during the HTML5 spec development process.)
These shouldn't be a warning. We're supposed to have graceful degradation without any requirement for CSS anywhere. Now the only "correct" way is a slew of media queries to set some designer's idea of the font for every possible viewport size. That is not how HTML is supposed to be rendered.
> Now the only "correct" way is a slew of media queries to set some designer's idea of the font for every possible viewport size.
Nested H1s was never semantically correct in the first place, at least for accessibility purposes.
You can do flexible sizes without media queries (eg, viewport size units + clamp). Designers generally understand the web pretty well these days.
I only see one situation where people might have depended on these styles, but it's a big one - anywhere that you output the plain HTML of a "rich text" component from a CMS or whatever. There, if the stakes are low, it might not have been a big deal to just let the browser do it and headings might look too big sometimes now.
A warning IS graceful degradation, an error or unexpected behaviour would be ungraceful. The channel that warnings come over is separate from the channel the content is being rendered in and it shows, for those that look at it, that the system is degraded and an action would need to be done to restore it to a non-degraded state.
This is not about graceful degradation. An HTML document without any CSS should never be in a degraded state. It should be perfectly usable and perfectly well accepted.
I agree; a HTML document without CSS should be perfectly usable and OK (and ideally CSS should never be required; if CSS is disabled it ought to still work OK, too).
However, if CSS specifies some things and omits others that are related to it (one example is specifying the font size for one heading level but not another one; another example is specifying the background colour without specifying the foreground colour or vice-versa), then it makes sense to be a warning.
I can't articulate it and I could very well be on the wrong vibe, but this feels like the bad practice of relying on the failure mode within a try/catch for normal functioning.
> HTML is about semantic markup, not visual markup.
Yeah... when it was meant for documents. In practice, modern websites are not documents - at best, they have a document or a few (like an article, or a post) embedded somewhere inside something else: an application, a designed page - basically, layout and presentation but not a document. HTML was never truly designed to do anything like this and it will always remain the clay feet part of this colossus.
The reason people still use <h1> or other "semantic" tags is only because of that idea that search engines give more "weight" to text in those tags, not because they care about semantics or other formal stuff. Otherwise they would've kept slapping styled <divs>.
I have always argued that there needs to be an entirely different language for websites, something semantically closer to XUL, XAML or QML. Best we've ever got are various custom DSLs that render to HTML/CSS/JS combo, conveniently hiding the underlying mess under the rug.
Looks like this change only applies to literal <h1> elements, such that <h2> ... <h6> still preserve the old behavior. If so you can just use the <h2> tag in section-like contexts in place of the older <h1>, and get the same or a very similar outcome.
If that is true, then TFA seriously missed the mark:
> Alongside the changes in browser styles, page auditing tools like Lighthouse now flag cases of <h1>s without defined font-size as bad practice.
Then when listing what to expect:
> Lighthouse will flag a warning if <h1> is used without a specified font-size.
And under the section "Fixing the Lighthouse warning":
> Lighthouse has recently inherited a check based on Chromium's DevTools warnings for sites that don't specify a font-size for <h1> elements.
Then it uses top-level h1 selectors in its examples of recommended styles. I mean you might be right about when that warning will appear, but the article doesn't seem to think you are.
> As a reader, I don't want page authors to start hard coding sizes into these elements, because then they'll be more likely to choose non-default values to make their page stand out a bit more.
That ship has already sailed. Whether they do it inline or through CSS, no one cares about the defaults, or your defaults. "Standing out" has been by far the biggest factor in web design ever since there was a web, and continues to drive the development of web technologies - that's because most websites are marketing products, either entirely, or in non-functional aspects (branding).
> HTML is about semantic markup, not visual markup.
Hard disagree here. HTML is too low-level to be semantic. "Separation of content and presentation" is a fundamentally flawed idea, because in many cases presentation is core to the semantics, and this is especially true for the Web, as in marketing, presentation is the content.
I remember the times when the CSS Zen Garden appeared, and everyone went on to meditate there and get high on the "separation of concerns" fumes emitted by the stylesheet selector widget. It was a great trip, but like with all such experiences, the effects are transient and don't carry to the adult reality.
Still, many a webdev tried to hold on to this ideal, many still do today. The results speak for themselves. What does "semantic HMTL" look like? A thick soup of nested divs with more or less meaningful class names, that only loosely resembles the natural structure of the content, because it's written specifically for its companion stylesheets, and only looks well with those particular stylesheets.
Here's a thought many still don't seem to realize: "semantics" in HTML isn't just about tag names, it's also about the shape of your tree. Your document isn't purely semantic, when the entire structure of the document is determined by needs of a specific presentation.
</rant>
You do have a good point about blockquotes. It's one of my main annoyances with markup / outliner formats used in many applications: they treat headline levels as absolute instead of relative, which doesn't play well with attempts at nesting documents inside documents.
In fact, to the extent HTML elements are supposed to be semantic, we shouldn't have headline levels in the first place! Instead of <h1>, <h2>, ... we should just have <header> - the headline level is implicit in the nesting anyway, and it naturally supports quoting/embedding documents in documents (and arbitrarily deep). As they are, <hN> are predominantly about presentation.
Same applies to Microsoft Word, too - the decision to have explicit named styles for headings (1 thru 9) as well as lists and others, causes problems more often than one would expect - at least for the few of us who insist on styling the document semantically, instead of applying specific looks to text by hand like most people do.
> "Standing out" has been by far the biggest factor in web design ever since there was a web,
I don't think that's true or at least as strongly as you suggest. When Bootstrap first came along, all websites that used it clearly looked the same, with minor differences. We see the same today but instead of Bootstrap, people use Tailwind or other libraries/frameworks but the effect is the same, most landing pages look the same, even if the images have different colors.
Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches. Very different from the web in the 90s/early 00s, where every website worked and looked very different from each other.
> When Bootstrap first came along, all websites that used it clearly looked the same, with minor differences. We see the same today but instead of Bootstrap, people use Tailwind or other libraries/frameworks but the effect is the same, most landing pages look the same, even if the images have different colors.
There's a logic to this phenomena, and it involves few people/companies trying something new to stand out (sometimes by being flashy, sometimes by being more ergonomic or less assaulting on the senses), some others following suit, and then if that "sticks", you'll see everyone else adopting the same design too. In particular, when some design reaches enough adoption, people who don't use it start to stand out, negatively - visitors start to see them as quaint, or worse, weird and therefore untrustworthy.
(It's not a bad heuristic, either. You can avoid a lot of Internet scams if you pay attention to how the website comes across to you at a visceral level. It's kind of a "spidey sense" many of us Internet dwellers have :).)
This is not Internet-specific either, it's also a thing in branding and product design spaces in general.
> Most websites today look like each other one way or another, as they're all mostly using the same libraries and frameworks that kind of pushes people into specific approaches.
That applies to products/services. Those tend to stand out subtler, but usually there's still a marketing department having strong influence (if not final say) on the design, and they make sure the branding is clear and the site is still easy to distinguish from any other site built with the same libraries and frameworks.
(The other category of websites is just glorified posters and magazines, and those are much weirder and unique, though even there you'll find fashion trends.)
EDIT:
The more general point is, presentation is always a core concern in commercial software, because branding is a core concern for companies. This has been true even before the Web; I recall some old UI Design Guidelines from Microsoft, IIRC for Windows 95, where this is acknowledged explicitly - the OS is pressured to provide ways to customize look&feel of UI elements, because software vendors demand it for branding, and so we can forget about having uniform UIs between applications. This is the unfortunate reality that drives UI standards.
> In fact, to the extent HTML elements are supposed to be semantic, we shouldn't have headline levels in the first place! Instead of <h1>, <h2>, ... we should just have <header> - the headline level is implicit in the nesting anyway
The <header> vs <h#> decision often ends up being a flow-breaking exception in my development process.
It also bugs me that we have exactly six hardcoded heading levels. Something about that feels like it violates a deep, lizard-brain-level DRY principle.
My main concern is how well screen readers and assistive tech would handle a semantic-only approach, as the <h#> elements go all the way back to the beginning of HTML and are pretty deeply rooted in standard practices.
I also think that not specifying the font size should not be called bad practice (unless you defined the font sizes for everything else and omitted some of them; if you do that then it is inconsistent). If you do not specify any CSS at all, that should not be a warning or error (it might not be displayed the same on all computers, but it shouldn't need to be anyways, so it is OK).
> As a reader, I don't want page authors to start hard coding sizes into these elements
I also, would rather they don't hard-code sizes (and also fonts, margins, etc); use whatever size is configured in the browser which is suitable for that display and that user.
> Additionally, the current behaviour (which I'd never particularly considered before) sounds entirely reasonable - if I take some existing markup and blockquote it in some container, I'd expect the headings to shrink as they're now all sub-elements of some other section.
Maybe. It is unclear that there should be a first-level heading inside of something else anyways.
> As a reader, I don't want page authors to start hard coding sizes into these elements, because then they'll be more likely to choose non-default values to make their page stand out a bit more.
Completely agree. In fact, this is what auditing tools should flag.
Let HTML be HTML!
Frankly, I think that the existing algorithm sounds correct, but I could be wrong.
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.