LGTM2 (Note: this LGTM is just for deprecation, please come back again for approval to remove.)
On Thu, Mar 20, 2025 at 8:25 AM Vladimir Levin <vmp...@chromium.org> wrote: > 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 Status >>>>>>>> https://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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2N3Vu8nd2Haeqsf5mdkmXY5MnKutMBhHS7vb%3DN_zMSSHg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw-H55GLWGy0u_ZTNv6HjxnVfzJsdq9aNVpCAA-_3Btatw%40mail.gmail.com.
