Remove UA style for h1-h6 in section (et. al.) and hgroup #7867
Comments
|
Seems extremely unlikely. |
|
Unlikely, but also quite unfortunate. I'd certainly support someone investigating this. cc @whatwg/css |
|
The Demo: Maybe it's possible to remove the other rules also; author CSS to set the font-size was needed to get consistent style in older browsers (in particular IE8). But this would need some research. |
Not including the special styling of h2-h5 in hgroup which is not implemented in browsers. See whatwg/html#7867
|
|
|
Adding |
|
We didn't get to this issue in the triage meeting today. Optimistically tagging @mfreed7 :) |
|
Sorry for the delay responding here. +@lilles because such an applied-styles use counter (at least in Chromium) would fall more onto his domain. |
This was introduced in f729a76 but was not implemented in browsers. Part of whatwg#7867.
|
@mfreed7 I need an executive summary of what to respond to. I'm totally out of context. |
|
Summary: If it's web-compatible, I think we should remove this part of the spec:
To determine web compatibility, is there interest in adding a use counter for When such a use counter exists on Stable, I can query for pages in httparchive that hit the use counter and analyze the compat impact. |
|
Thanks! Looking at the UA sheet and our impl it seems that a counter shouldn't be too tricky to add. Reported: https://crbug.com/1334570 |
|
Counter landed (for M105):
https://chromium-review.googlesource.com/c/chromium/src/+/3698090
ons. 8. jun. 2022 kl. 11:44 skrev Simon Pieters ***@***.***>:
… Summary:
If it's web-compatible, I think we should remove this part of the spec:
In the following CSS block, x is shorthand for the following selector: :is(article,
aside, nav, section)
@namespace url(http://www.w3.org/1999/xhtml);
x h1 { margin-block-start: 0.83em; margin-block-end: 0.83em; font-size: 1.50em; }
x x h1 { margin-block-start: 1.00em; margin-block-end: 1.00em; font-size: 1.17em; }
x x x h1 { margin-block-start: 1.33em; margin-block-end: 1.33em; font-size: 1.00em; }
x x x x h1 { margin-block-start: 1.67em; margin-block-end: 1.67em; font-size: 0.83em; }
x x x x x h1 { margin-block-start: 2.33em; margin-block-end: 2.33em; font-size: 0.67em; }
To determine web compatibility, is there interest in adding a use counter
for h1 with a sectioning element ancestor and no Author Origin style for
font-size? (I assume that changes to margin are more acceptable than
font-size.)
When such a use counter exists on Stable, I can query for pages in
httparchive that hit the use counter and analyze the compat impact.
—
Reply to this email directly, view it on GitHub
<#7867 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGZFVLC77YL2SOELQRPHPLVOBTPTANCNFSM5USM32CQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Rune Lillesveen
|
|
Thanks @lilles! Per https://chromiumdash.appspot.com/schedule it should reach stable on August 30. With some luck it will be included in the September 1st HTTP Archive run. |
|
Data so far is not that encouraging: https://chromestatus.com/metrics/feature/timeline/popularity/4272 |
Removes the idea of sectioning content influencing the document's outline. Instead, the outline is derived from all of the document's h1-h6 elements. (Sectioning content still plays a role in scoping header and footer elements.) This ensures that the outline generated by the outline algorithm, i.e. the document's semantics for authors, better aligns with the way screen reader users navigate through headings and the corresponding normative requirements for implementations in the HTML-AAM specification. Updates the hgroup element to have a new content model, to use p elements for related content such as subheadings, alternative titles, or taglines (instead of using heading elements for those). Updates all of the spec's examples to have proper outlines, according to the new outline algorithm. This includes preferring h2 to h1 in markup fragment cases, so as to better suggest that they are part of a larger document whose outline contains a h1. Closes #83. Closes #3499 by superseding it. Closes #6462 by updating hgroup's suggested usage instead of obsoleting it. See #7867 for potential followup work in avoiding sectioning content and hgroup influencing the style of h1-h6 elements. Co-authored-by: Anne van Kesteren <[email protected]> Co-authored-by: Domenic Denicola <[email protected]>
|
Hi, I'm a teacher, and the other day I talked about the section element and the outline algorithm that was in the spec but never implemented. I also showed students how the font size of nested section headings still decreases visually. They found that confusing. Is this the right place to keep track of the progress? The last comment was a year ago. Are there any updates? Thank you, |
|
Thanks for pinging this thread. Per the above data, it looks like removing this would break about 0.6% of the web. I suspect no browsers are enthusiastic about doing that. So, shall we close this? |
|
Make sense, thank you for clarifying! |
|
I'd like to still do an analysis of impact for the affected pages. If the difference is minor for the vast majority of pages then it's not a breaking change. |
|
I've analyzed the first 30 URLs from top sites listed in https://chromestatus.com/metrics/feature/timeline/popularity/4272 with a custom build of Firefox with this change applied and compared to regular Firefox Nightly. Findings: The sites are either unaffected or the change looks OK (I wouldn't expect browser bug reports for these), or in some cases revert to author-intended size. 0.5-0.6% of pages and page loads is still a lot, so there could of course be something that breaks more substantially. Still, I think it's worth it to try to make this change, to make HTML default styling make more sense for the long term. Notes (updated 2024-05-14 to group by impact and add info for arstechnica.com):
|
|
I've landed a patch now that only affects Firefox Nightly. I'll let it sit for a bit and see if we get bug reports. If it seems OK, I plan to submit a spec PR. |
|
Could this change be causing this issue https://webcompat.com/issues/134857 ? |
|
Firefox has had this change in Nightly for about 2 months now, and we've received 2 bugs about arstechnica.com having too much spacing (on mobile only). Looking back at my previous analysis above, 11 out of 29 pages had some visual difference. Even though my assessment is generally "looks OK", we did get bugs about arstechnica.com, and 38% of 0.6% is still ~0.23% of sites potentially being affected. I wonder at this point if there's interest from WebKit and/or Chromium to also pursue this change? If so, we might want to do something to get the numbers down, e.g. console warning in devtools, check in Lighthouse, etc., before shipping to stable. |
|
In principle this seems fine to try from WebKit's point of view. |
|
In principle, Chromium is supportive of this a11y-enhancing change. We are more than a bit concerned about the compat impact, and whether it'll be landable, but I'm glad it sounds like Gecko is going to blaze the trail there and hopefully report back here with successes and failures? I'm in the process of landing my own breaking change, and we only have so much bandwidth available to break things. I'd be happy to help with console warnings and such, but... is there really a way to do that? I'm not sure how you'd disambiguate "good/expected" usage with "unexpected" usage. I definitely don't think it'd be good to just spam the console for anyone using a header tag. Help me understand what you end up doing in Gecko and we can try to follow suit. |
|
Hi, I don't see why people would want only h1 headings be smaller in articles and sections. It makes h1 and h2 tags the same size and a bit confusing and also leads to necessity to override font sizes. Maybe there was some logic behind that? |
@PaulineNemchak There was an idea once to use only h1s for headings, determining level by nesting into specific elements. This dream is long gone, but styles are still there. You brought up a good point about h1 and h2 looking unexpectedly the same. |
|
Update: We've shipped this change in Nightly only for about 9 months (https://bugzilla.mozilla.org/show_bug.cgi?id=1883896), and only one page reported as regressed, which has since been fixed (https://bugzilla.mozilla.org/show_bug.cgi?id=1886480).
We haven't implemented any console message yet, but I envisioned logging a message when |
|
The use counter seems to be flat or possibly trending slowly in the wrong direction. I queried httparchive for all pages that trigger the use counter, and analyzed the top-ranked pages (23 pages with rank bucket 1000). https://docs.google.com/spreadsheets/d/1YfrbqE-lJRN0cEq0SC-cQs5FC6XvvyhdVEsrhjwpOy8/edit?usp=sharing One page has an improved rendering (current behavior is h1 and h2 have the same size). Two pages from one site (1, 2) has a difference in font size but it's minor and probably not noticeable. The rest had no visual difference. I'll try to move this forward for Firefox, probably with a staged rollout A/B experiment or maybe shipping to early beta. I'll look into console warning also. @mfreed7 is there some integration between Chromium API deprecations and Lighthouse? Maybe the use counter code path could log a deprecation signal also? I found https://developer.chrome.com/docs/lighthouse/best-practices/deprecations |
I've anecdotally observed a phenomenon wherein deprecating something causes its use counter to go up. I think it's a variation on "there no such thing as bad publicity". 😆
Good luck!
+@lilles who added the use counter. Yes, marking something deprecated in Chromium will lower the Lighthouse score for "Best Practices" by enough to guarantee that the overall Lighthouse score isn't "green". (I pushed for that as part of the mutation events deprecation.) |
|
Stylesheet for web developers to opt in to the new (or original) styling now: If you want to add this to a reset stylesheet but don't want to override any other style rule, use |
* Suggest specifying font-size and margin-block on h1 See whatwg/html#7867 * Apply suggestions from code review Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Chris Mills <[email protected]> * Update files/en-us/web/html/element/heading_elements/index.md Co-authored-by: Simon Pieters <[email protected]> * Update files/en-us/web/html/element/heading_elements/index.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Chris Mills <[email protected]> Co-authored-by: Estelle Weyl <[email protected]>
|
Gecko will now show a console warning when there's no author-specified font-size or margin: https://bugzilla.mozilla.org/show_bug.cgi?id=1937568
I've filed https://issues.chromium.org/issues/394111284 |
If/when #7829 is merged, the following UA style doesn't make sense. Can it be removed?
https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings
The text was updated successfully, but these errors were encountered: