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.
