Thanks for the answers! LGTM1 to deprecate. This console message may be interpreted as noise if the author decides that they are OK with the deprecation, but would not be able to silence the warning. Because of this, the API owners strongly suggest that we try to limit the deprecation to 3 milestones and either proceed with removal or re-evaluate.
Thanks! Vlad On Thu, Mar 20, 2025 at 7:22 AM Simon Pieters <zcor...@mozilla.com> wrote: > 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/CADsXd2N3Vu8nd2Haeqsf5mdkmXY5MnKutMBhHS7vb%3DN_zMSSHg%40mail.gmail.com.
