Hi! Suggestions for web developers:
* Use h1 only for the page's top-level heading. Use h2-h6 for other headings. * Specify font-size and margin for h1 in your CSS. Firefox has a similar console warning which reads: Found a sectioned h1 element with no specified font-size or margin properties. More information: https://developer.mozilla.org/docs/Web/HTML/Element/Heading_Elements#specifying_a_uniform_font_size_for_h1 cheers, On Thu, Mar 20, 2025 at 12:37 AM Mason Freed <mas...@chromium.org> wrote: > > On Tue, Mar 18, 2025 at 7:25 PM Vladimir Levin <vmp...@chromium.org> > wrote: > >> The thing that gives me pause is the nature of the console warning. It >> isn't that <h1> within, say, <article> is deprecated, it's the fact that >> the special rules will be removed and thus the font size may look >> different. I'm not sure what action would be suggested for the authors. Can >> you comment on that? Is the recommendation to switch to <h2> to keep the >> current look? Or to just be aware of the change? >> > > Great question. So the current text (at least the English version) says > this: > > The website has an <h1> tag within an <article>, <aside>, <nav>, or > <section>, and relies on deprecated UA stylesheet rules for the resulting > font size. See the second block of 'x h1' styles in > https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings. > These special rules are deprecated and will be removed. See > https://github.com/whatwg/html/issues/7867. > > > So it does go to some length to try to explain the exact thing that is > being changed, but still it can be a bit confusing. And it doesn't make > specific suggestions for how to fix it, since I think those will be very > site-specific. Suggestions appreciated for how to improve the effectiveness > and clarity of the message! I do agree it would help to have a very clear > message to avoid folks making changes they don't need to make. > > Thanks, > Mason > > > >> On Tuesday, March 18, 2025 at 5:50:10 PM UTC-4 Mason Freed wrote: >> >>> On Mon, Mar 17, 2025 at 11:15 AM Alex Russell <slightly...@chromium.org> >>> wrote: >>> >>>> This looks good, but I'm not sure I understand the plan. Is it to >>>> deprecate (w/ console warnings) for some period of time? Are you going to >>>> propose a reverse-OT? Or removal once usage falls below some threshold? >>>> >>> >>> Yep, it's a good question. The plan is to show console warnings starting >>> now (M136) for a period of time, and wait for Mozilla to start/complete >>> their removal. They are starting an experiment soon >>> <https://github.com/whatwg/html/issues/7867#issuecomment-2711723856> to >>> assess the risk and compat, and my plan is to follow their lead. So I would >>> say that once they've moved forward with a general removal, I'd send an I2R >>> (remove) and turn it off in Chrome. I'd likely do that slowly via Finch, to >>> ensure no breakage. I've historically found it tough to assess actual risk >>> via use counters alone, and the only true test is to use Finch and >>> slowly/carefully test a removal. Once that process is successful, we would >>> disable it by default in code for all browsers. >>> >>> Thanks, >>> Mason >>> >>> >>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Thursday, March 6, 2025 at 5:20:03 PM UTC-8 Mason Freed wrote: >>>> >>>>> On Tue, Mar 4, 2025 at 7:46 PM Vladimir Levin <vmp...@chromium.org> >>>>> wrote: >>>>> >>>>>> Re TAG: I don't believe we need a TAG review for deprecations or >>>>>> removals. >>>>> >>>>> >>>>> Great, thanks for confirming. >>>>> >>>>> >>>>>> On Tuesday, March 4, 2025 at 8:54:00 PM UTC-5 Domenic Denicola wrote: >>>>>> >>>>>> It wasn't clear to me that this was just in the initial "deprecate" >>>>>> stage, not the "remove" stage: I wish ChromeStatus tooling separated >>>>>> those >>>>>> more cleanly (like it does Dev Trial vs. Ship). Given that you're still >>>>>> in >>>>>> the preparatory deprecation stage, this level of detail seems fine! >>>>>> >>>>>> >>>>> +1. I used to edit the subject like to say "Intent to Deprecate" (i.e. >>>>> remove the "and Remove") but that broke some of the tooling, so now I >>>>> don't >>>>> touch it. But I do wish the descriptions changed to say "deprecation" >>>>> instead of "dev trial" and "remove" instead of "ship". >>>>> >>>>> >>>>>> I do think a short explainer-like thing will be desirable before we >>>>>> get to the removal stage. Maybe just a few paragraphs detailing what's >>>>>> changing, what impact it might have on developers, and how they can >>>>>> adapt. >>>>>> Hopefully Mozilla can help put that together. A reasonable place for that >>>>>> to live would be the top message of the spec PR. >>>>>> >>>>>> >>>>> Sure, that makes sense. I think at that point there might be more data >>>>> to pull into the explainer also. >>>>> >>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> Use counters are relatively high: https://chromestatus.com/ >>>>>> metrics/feature/timeline/popularity/4272 However, analysis from >>>>>> Mozilla shows that perhaps the impact is not as large as the use counters >>>>>> would suggest: https://github.com/whatwg/ >>>>>> html/issues/7867#issuecomment-2595987424 >>>>>> >>>>>> >>>>>> For posterity, it looks like about 0.6% of page loads would be >>>>>> affected, and that seems to have a gradual trend up. >>>>>> >>>>>> A deprecation seems fine here. What do you estimate a removal >>>>>> timeline to be? Ideally we can reduce the usecounters as much as we can >>>>>> before a removal. >>>>>> >>>>> >>>>> I agree, it'd be nice to see the use counters go down before that, but >>>>> I always notice that deprecating things seems to make usage go up. I don't >>>>> have a great estimate for the removal timeline - I'm following Mozilla's >>>>> lead on this, and ideally they turn it off by default first for a while, >>>>> before Blink does. Sorry I don't have a more definite schedule! >>>>> >>>>> >>>>>> Again for posterity, it seems like there was a single report about >>>>>> this, which was fixed on the author's side: >>>>>> https://mastodon.social/@zcorpan/113843744254923492 >>>>>> >>>>> >>>>> Yep, thanks. >>>>> >>>>> On Wed, Mar 5, 2025 at 8:00 AM Daniel Bratell <bratel...@gmail.com> >>>>> wrote: >>>>> >>>>>> Use counter is 0.6% but judging from the comment >>>>>> https://github.com/whatwg/html/issues/7867#issuecomment-1977647444 the >>>>>> effect seems smaller. Of 30-ish sites investigated there, 15 were >>>>>> unaffected and the rest had seemingly minor changes. >>>>>> >>>>>> The high counter might be because linkedin triggers it, and linkedin >>>>>> was seemingly not affected. >>>>>> >>>>>> This does not mean that it's safe to remove the slightly (to me) >>>>>> unexpected quirk, but it might be. >>>>>> >>>>> Unclear to me also, but I'm hopeful. >>>>> >>>>> Thanks, everyone! >>>>> >>>>> Mason >>>>> >>>>> >>>>>> *WebKit*: Positive (https://github.com/whatwg/ >>>>>> html/issues/7867#issuecomment-2124317504) This isn't a standards >>>>>> position, just a github comment. >>>>>> >>>>>> *Web developers*: No signals No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ?Yes >>>>>> >>>>>> https://wpt.fyi/results/html/rendering/non-replaced- >>>>>> elements/sections-and-headings >>>>>> >>>>>> >>>>>> Flag name on about://flagsNone >>>>>> >>>>>> Finch feature nameNone >>>>>> >>>>>> Non-finch justification >>>>>> >>>>>> No Finch flag yet - this is just at the "Intent to Deprecate" stage, >>>>>> not the "Removal" stage. Only warnings will be shown for now. >>>>>> >>>>>> >>>>>> Requires code in //chrome?False >>>>>> >>>>>> Tracking bughttps://issues.chromium.org/issues/394111284 >>>>>> >>>>>> Estimated milestonesDevTrial on desktop136DevTrial on Android136 >>>>>> >>>>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/ >>>>>> feature/6192419898654720?gate=5420483144843264 >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> On Tue, Mar 4, 2025 at 3:47 PM Jason Robbins <jrobb...@google.com> >>>>>> wrote: >>>>>> >>>>>> Oh, and to clarify, I was suggesting that you could copy using the >>>>>> small copy-icon button and paste it on this thread as a reply. Don't >>>>>> start >>>>>> a new blink-dev thread or use the "Post directly to blink-dev" button >>>>>> (because that will start a new thread). >>>>>> >>>>>> Thanks, >>>>>> jason! >>>>>> >>>>>> On Tuesday, March 4, 2025 at 3:43:34 PM UTC-8 Jason Robbins wrote: >>>>>> >>>>>> The kicker: the chromestatus tool only gives you one shot at creating >>>>>> the intent email. Now that I've done it once, that button is gone. In >>>>>> order >>>>>> to send another email, it seems that I'd have to create an entirely new >>>>>> chromestatus entry, and I'm loath to do that. Let me know if it's enough >>>>>> to >>>>>> point you to the chromestatus page itself >>>>>> <https://chromestatus.com/feature/6192419898654720> to see the >>>>>> updated sections? Sorry. >>>>>> >>>>>> >>>>>> Mason, here's a link to the intent preview page for this feature >>>>>> entry that you could copy again: >>>>>> https://chromestatus.com/feature/6192419898654720/gate/ >>>>>> 5420483144843264/intent >>>>>> >>>>>> ChromeStatus doesn't offer that button after the intent thread is >>>>>> detected simply because we reuse that UI area to show review status info, >>>>>> which is typically the next step in the process. However, that button is >>>>>> just a link to the intent preview page, and it is always available if you >>>>>> fill in the feature ID and gate ID. Of course, any copy-and-pasted email >>>>>> can fall out of date, and it only has a subset of the feature entry >>>>>> fields, >>>>>> so reviewers should make use of the full feature entry as needed. >>>>>> >>>>>> Thanks, >>>>>> jason! >>>>>> >>>>>> >>>>>> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiq9dDw-po-DKJ-Oh6Bm8Z1sBSio1_KnT-nBN9Z%3D4ESRw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiq9dDw-po-DKJ-Oh6Bm8Z1sBSio1_KnT-nBN9Z%3D4ESRw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Simon Pieters https://www.mozilla.com/ -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC7mYC7AyPVjcarb1k6%3DZ92HLPVY9RhwjDznbUThZnpcpUNioQ%40mail.gmail.com.
