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 <annevk@annevk.nl> Co-authored-by: Domenic Denicola <d@domenic.me>
|
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. |
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: