On Fri, Oct 20, 2023 at 9:00 AM Joey Arhar <jar...@chromium.org> wrote:
> > > For the purposes of WHATWG's multi-implementer support criteria: I > will assume we cannot check the box for "Chromium supports this feature" > until a different browser has shipped :state() to their stable channel. > (Let me know if that is incorrect.) > > > > Chromium does support the feature, and it should be marked as such in > the WHATWG. (We've shipped it in fact, just with a slightly different name > for the moment.) > > Yeah I'm worried that not merging the spec would be a confusing signal to > Apple and then they might never implement anything. I'd like to see the > HTML spec get merged as :state(). > +1! > > On Fri, Oct 20, 2023 at 8:55 AM Chris Harrelson <chris...@chromium.org> > wrote: > >> >> >> On Thu, Oct 19, 2023 at 6:48 PM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> Thanks Chris and the API Owners for having this discussion! I am >>> sympathetic to this being a hard problem with the strong potential to set a >>> bad precedent. >>> >>> On Fri, Oct 20, 2023 at 3:00 AM Chris Harrelson <chris...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson <chris...@chromium.org> >>>> wrote: >>>> >>>>> The API owners met yesterday and discussed this intent. Our consensus >>>>> was that we would like to wait until another browser has implemented and >>>>> is >>>>> shipping :state before we approve shipping it in Chromium. We also don't >>>>> recommend spending more time on further bikeshet spec discussions for it >>>>> in >>>>> the meantime, and leave the spec as-is. >>>>> >>>> >>>> "bikeshed", that is. >>>> >>> >>> With my HTML spec editor hat on, I have a clarifying point and question. >>> >>> "Leave the spec as-is": right now there are unmerged CSS >>> <https://github.com/w3c/csswg-drafts/pull/8213> and HTML >>> <https://github.com/whatwg/html/pull/8467> spec PRs, plus a WICG spec >>> <https://wicg.github.io/custom-state-pseudo-class/>. So it's not clear >>> exactly which spec you're referring to, but I guess the advice is for >>> Chromium engineers to not invest effort in changing any of these three work >>> items for bikeshed considerations. (Let me know if this is incorrect.) Of >>> course, other community members can continue to work on the spec if they >>> wish. >>> >> >> Those PRs should be finished and landed. My/our comment was only about >> bikeshedding. >> >> For the purposes of WHATWG's multi-implementer support criteria: I will >>> assume we cannot check the box for "Chromium supports this feature" until a >>> different browser has shipped :state() to their stable channel. (Let me >>> know if that is incorrect.) >>> >> >> Chromium does support the feature, and it should be marked as such in the >> WHATWG. (We've shipped it in fact, just with a slightly different name for >> the moment.) >> >> >>> >>> >>>> >>>> >>>>> >>>>> We think this plan is a reasonable approach to reduce work for >>>>> web developers and Chromium implementers in the short term while still >>>>> achieving interop in the future. >>>>> >>>>> On Thu, Oct 12, 2023 at 11:41 AM Alex Russell < >>>>> slightly...@chromium.org> wrote: >>>>> >>>>>> Hey all, >>>>>> >>>>>> We've spent a LOT of time discussing this one in API OWNERS, and my >>>>>> disinclination to allow this to move forward remains. What we're >>>>>> observing >>>>>> in this Intent is an anti-pattern in which: >>>>>> >>>>>> - Chromium engineers follow a process that is designed to put >>>>>> developer needs above implementer preferences >>>>>> >>>>>> <https://www.w3.org/2019/09/17-components-minutes.html#:~:text=chrishtr:%20I%20think%20having%20custom%20states%20was%20the%20%231%20request%20on%20top%20of%20parts>, >>>>>> explore the design space earnestly, work with developers to vet a >>>>>> solution, >>>>>> and work to build interest with other vendors >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/CApU9QIu3TM/m/LPKLLLahDQAJ> >>>>>> . >>>>>> - Other projects fail to implement and/or implement alternatives. >>>>>> - The API OWNERS take a calculated risk to ship first. That is >>>>>> premised on collateral the development team provides that the design >>>>>> solves >>>>>> an important problem well, demonstrating developer support and that >>>>>> our >>>>>> process for open development has given ample time for others to >>>>>> engage and >>>>>> help shape the design. >>>>>> - Time passes (often years). >>>>>> - Without implementing themselves, other vendors demand that the >>>>>> design change to achieve "consensus" within a standards body, but >>>>>> without >>>>>> demonstrating real deficiencies in the shipped API or even feedback >>>>>> from >>>>>> developers that we were wrong in some important way. >>>>>> >>>>>> >>>>>> Or put another way, spec fiction is being allowed to trump real-world >>>>>> problem solving, and that's not what our process is designed to >>>>>> facilitate. >>>>>> >>>>>> Not only does this pattern further escalate the costs involved in the >>>>>> process to deliver a feature where we have already paid treble to >>>>>> ice-break, it potentially breaks applications -- remember that we suffer >>>>>> from enterprise blindness in our use counters, so it's probable that we >>>>>> will also need to reach out to, e.g., Salesforce and ask them to help >>>>>> collect data. This pattern also drags us away from other work that would >>>>>> expand the platform for users and developers in productive ways. >>>>>> >>>>>> These costs may seems small on an individual feature basis, but they >>>>>> add up fast and set terrible precedent. I'm *extremely* unhappy that >>>>>> we seem to be engaging in more of it over the past year, particularly >>>>>> without strong arguments for why the new design is superior. Even the >>>>>> recent debate over this feature is largely about non-committal mild >>>>>> preferences: >>>>>> >>>>>> >>>>>> https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980 >>>>>> >>>>>> At this point I've read substantially all of the minutes related to >>>>>> these design choices, and this is *absolutely *late bikeshedding by >>>>>> folks who haven't implemented either alternative and were widely >>>>>> consulted >>>>>> at the time we backstopped the initial I2S. >>>>>> >>>>>> Per our conversation yesterday, I'm struggling to get to "yes" on >>>>>> this. At a minimum, I need a stronger argument for why we should make >>>>>> this >>>>>> change than that someone in the CSS WG had a mild preference years after >>>>>> the CSS WG was first consulted on the problem. It would help if we had a >>>>>> commitment from the Intent proposers to avoid this sort of change in >>>>>> future. Deciding to ship this would also need to be clearly disclaimed as >>>>>> non-precedent, and I'd be looking from support of the managers of these >>>>>> teams to prevent this sort of make-work in future. How close are we to >>>>>> agreement on that? >>>>>> >>>>>> Best, >>>>>> >>>>>> Alex >>>>>> >>>>>> On Wednesday, October 11, 2023 at 7:49:09 AM UTC-7 Brian Kardell >>>>>> wrote: >>>>>> >>>>>>> I don't normally weigh in on these but I just wanted to say that I >>>>>>> think this one is pretty unique for a whole bunch of reasons and it's >>>>>>> not >>>>>>> just an example of bikeshedding after shipping by a specific vendor or >>>>>>> something. It's more than that. As much as I think this is important, >>>>>>> and >>>>>>> wanted it, there were a million other things to talk about re: custom >>>>>>> elements that were ahead of it and it just didn't get the level of >>>>>>> oxygen >>>>>>> that it needed from many quarters, it seems to me, in order to surface >>>>>>> the >>>>>>> right thoughts. As it's picked up, over the last few years there were >>>>>>> disagreements, counterpoints, etc at many stages through WHATWG, TAG, >>>>>>> CSSWG... It feels like it would be good to summarize all of it >>>>>>> somewhere - >>>>>>> and I'm not even saying the decision here is "right" or something ... >>>>>>> I'm >>>>>>> just saying that I don't think it is as simple as "bikeshedding after >>>>>>> shipping" implies >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thursday, October 5, 2023 at 4:54:26 PM UTC-4 Chris Harrelson >>>>>>> wrote: >>>>>>> >>>>>>>> Regarding why change to :state() instead of :--: as is typical, it >>>>>>>> was done in order to gain consensus; in particular, the CSSWG >>>>>>>> resolution >>>>>>>> notes indicate >>>>>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980> >>>>>>>> (see >>>>>>>> comment from the chair) one motivation is to align with WHATWG and not >>>>>>>> end >>>>>>>> up with a situation where two standards groups have opposing positions >>>>>>>> in a >>>>>>>> gray-area situation and no progress is made. >>>>>>>> >>>>>>>> I don't think that 0.03% is a big problem to deprecate, and >>>>>>>> recommend we just make the change to match a hard-won consensus and >>>>>>>> move >>>>>>>> on. It's easy enough to support both syntaxes for some amount of time >>>>>>>> before removing the old one. >>>>>>>> >>>>>>>> On Thu, Oct 5, 2023 at 1:49 PM Chris Harrelson < >>>>>>>> chri...@chromium.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Oct 4, 2023 at 2:24 PM Jeffrey Yasskin < >>>>>>>>> jyas...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Apparently +Chris Wilson had part of this discussion with Alan >>>>>>>>>> Stearns in April at >>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1524167658, >>>>>>>>>> and the suggestion was that if a CSS spec for a feature is "unstable" >>>>>>>>>> (meaning 'not at CR'?), then we should either post "we're about to >>>>>>>>>> send an >>>>>>>>>> intent" to the last issue discussing it, or file an "Is X ready to >>>>>>>>>> ship?" >>>>>>>>>> issue. I think +Chris Harrelson is likely to have the strongest >>>>>>>>>> opinions about this: should we add such a rule to our launch process >>>>>>>>>> for >>>>>>>>>> CSS features? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think we generally shouldn't ship CSS features before there is >>>>>>>>> robust discussion and consensus at the CSSWG, and I think Chromium >>>>>>>>> features >>>>>>>>> have done a good job at that. The CSSWG resolution mechanism, and the >>>>>>>>> various stages of W3C standardization help to build confidence about >>>>>>>>> the >>>>>>>>> degree of consensus and commitment, as do signals from other browser >>>>>>>>> vendors. I don't think we should additionally require filing an "is X >>>>>>>>> ready >>>>>>>>> to ship?" issue at the CSSWG for CSS features. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>>> Jeffrey >>>>>>>>>> >>>>>>>>>> On Wed, Oct 4, 2023 at 1:15 PM Jeffrey Yasskin < >>>>>>>>>> jyas...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> On Wed, Oct 4, 2023 at 1:08 PM Joey Arhar <jar...@chromium.org> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>> > I'd like to understand better how we wound up shipping :--foo >>>>>>>>>>>> and then having the CSSWG ask us to change it to :state(foo) >>>>>>>>>>>> instead, and >>>>>>>>>>>> what we could do in the future to avoid it happening again. >>>>>>>>>>>> >>>>>>>>>>>> I think if this was specced before shipping that would have >>>>>>>>>>>> been better and is a practice that I (and we?) currently follow, >>>>>>>>>>>> but this >>>>>>>>>>>> was shipped a number of years ago. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yeah, good point: it's totally possible that our more recent >>>>>>>>>>> process rigor is sufficient, and we don't need anything new to >>>>>>>>>>> prevent this >>>>>>>>>>> in the future. No matter what, we should expect the occasional old >>>>>>>>>>> feature >>>>>>>>>>> to pop up and be an exception. >>>>>>>>>>> >>>>>>>>>>> I do think that it's worth finding a way to write down your >>>>>>>>>>> current practice, so that it doesn't regress if you switch teams. I >>>>>>>>>>> think >>>>>>>>>>> you mean that you do "hold off on shipping CSS features until they >>>>>>>>>>> land in >>>>>>>>>>> an official draft", so let's try to record that if it's our idea of >>>>>>>>>>> the >>>>>>>>>>> solution. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> > As far as I can see, nobody asked for the ergonomic evidence >>>>>>>>>>>> that >>>>>>>>>>>> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews >>>>>>>>>>>> says we can expect after Chrome has shipped a feature. >>>>>>>>>>>> >>>>>>>>>>>> This was my bad, I didn't realize or didn't completely consider >>>>>>>>>>>> usecounters before I presented the name change to the CSSWG. >>>>>>>>>>>> I am hoping that with an answer from the API owners, I can go >>>>>>>>>>>> back to the CSSWG and potentially change it back. >>>>>>>>>>>> There is still no merged spec in HTML or CSS for this feature >>>>>>>>>>>> yet, but I have open PRs in both specs. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> On Wed, Oct 4, 2023 at 1:00 PM Jeffrey Yasskin < >>>>>>>>>>>> jyas...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>> +1 on the API owners discussing this. >>>>>>>>>>>>> >>>>>>>>>>>>> I'd like to understand better how we wound up shipping :--foo >>>>>>>>>>>>> and then having the CSSWG ask us to change it to :state(foo) >>>>>>>>>>>>> instead, and >>>>>>>>>>>>> what we could do in the future to avoid it happening again. >>>>>>>>>>>>> >>>>>>>>>>>>> It looks like the initial proposal was :state(foo); the CSSWG >>>>>>>>>>>>> asked to change it to :--foo in 2020 >>>>>>>>>>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-591547956>; >>>>>>>>>>>>> we shipped that in M90 in 2021 >>>>>>>>>>>>> <https://chromestatus.com/feature/6537562418053120> (with a >>>>>>>>>>>>> feature entry that still says :state 🙃); then Ryosuke >>>>>>>>>>>>> suggested undoing that change in January 2023 >>>>>>>>>>>>> <https://github.com/whatwg/html/pull/8467#issuecomment-1381645661>, >>>>>>>>>>>>> and the CSSWG accepted that suggestion in August >>>>>>>>>>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980>. >>>>>>>>>>>>> As far as I can see, nobody asked for the ergonomic evidence that >>>>>>>>>>>>> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews >>>>>>>>>>>>> says we can expect after Chrome has shipped a feature. It doesn't >>>>>>>>>>>>> seem like >>>>>>>>>>>>> this feature was so contentious that the team needed to use a >>>>>>>>>>>>> name change >>>>>>>>>>>>> as a bargaining chip, so we should probably have insisted on more >>>>>>>>>>>>> evidence >>>>>>>>>>>>> before agreeing with the change. Maybe that's still a "should" >>>>>>>>>>>>> instead of a >>>>>>>>>>>>> "should have": Joey's second email >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/wPAHJzIvAQAJ> >>>>>>>>>>>>> might >>>>>>>>>>>>> say that the CSSWG's resolution >>>>>>>>>>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980> >>>>>>>>>>>>> about this isn't as committed as it appears to an external >>>>>>>>>>>>> observer? >>>>>>>>>>>>> >>>>>>>>>>>>> Should we generally hold off on shipping CSS features until >>>>>>>>>>>>> they land in an official draft, or even in a CR? Should we be >>>>>>>>>>>>> clearer to >>>>>>>>>>>>> the CSSWG when we decide to ship ahead of their consensus that >>>>>>>>>>>>> the bar for >>>>>>>>>>>>> changes is going up? There's not good support for this kind of >>>>>>>>>>>>> per-WG >>>>>>>>>>>>> restriction in Chrome Status yet, but maybe it'll fit near >>>>>>>>>>>>> https://github.com/GoogleChrome/chromium-dashboard/issues/3390. >>>>>>>>>>>>> .. >>>>>>>>>>>>> >>>>>>>>>>>>> Jeffrey >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Sep 29, 2023 at 12:32 PM Alex Russell < >>>>>>>>>>>>> sligh...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>> hrm, this is another instance of bikeshedding after shipping, >>>>>>>>>>>>>> and I'm not inclined to approve. Perhaps we can discuss at next >>>>>>>>>>>>>> week's API >>>>>>>>>>>>>> OWNERs meeting? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adding others who I know are interested in this topic. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>> The spec for the new syntax hasn't been merged yet, I haven't >>>>>>>>>>>>>>> finished implementing it in chromium yet, and I don't have >>>>>>>>>>>>>>> estimated >>>>>>>>>>>>>>> milestones yet, but I'd like to get the API owners thoughts on >>>>>>>>>>>>>>> whether this >>>>>>>>>>>>>>> deprecation would be acceptable to help guide the spec >>>>>>>>>>>>>>> discussion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I did some analysis of the top 8 websites on the >>>>>>>>>>>>>>> chromestatus entry to see what the breakage would be like: >>>>>>>>>>>>>>> https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing >>>>>>>>>>>>>>> I found that most of them had the affected custom elements >>>>>>>>>>>>>>> behind display:none rules that I had to manually remove in >>>>>>>>>>>>>>> order to use >>>>>>>>>>>>>>> them. There was only one website where there was actual >>>>>>>>>>>>>>> breakage by >>>>>>>>>>>>>>> default, in which case the carousel buttons didn't work on >>>>>>>>>>>>>>> firefox and >>>>>>>>>>>>>>> safari. If the new syntax is just for the CSS property and we >>>>>>>>>>>>>>> keep >>>>>>>>>>>>>>> CustomStateSet the same, then the affected website's buttons >>>>>>>>>>>>>>> would continue >>>>>>>>>>>>>>> to work but whatever custom styles they have (which I couldn't >>>>>>>>>>>>>>> trigger) >>>>>>>>>>>>>>> wouldn't apply anymore. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Personally, I think that this breakage would not be bad >>>>>>>>>>>>>>> especially if we keep CustomStateSet the same, and I kind of >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>> :state(foo) more than :--foo. However, I might have not made it >>>>>>>>>>>>>>> clear in >>>>>>>>>>>>>>> the spec discussions yet that we have already shipped :--foo by >>>>>>>>>>>>>>> default for >>>>>>>>>>>>>>> several years. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar < >>>>>>>>>>>>>>> jar...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Contact emailsjar...@chromium.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ExplainerNone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specificationhttps://github.com/whatwg/html/pull/8467 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CSS custom state, which allows custom elements to expose >>>>>>>>>>>>>>>> their own pseudo-classes, was shipped here: >>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This feature has not been implemented in gecko or webkit >>>>>>>>>>>>>>>> yet. I recently made an effort to spec this feature in CSSWG >>>>>>>>>>>>>>>> and WHATWG, >>>>>>>>>>>>>>>> but there was pushback to change the syntax back from :--foo to >>>>>>>>>>>>>>>> :state(foo), and the CSSWG has resolved to do this as well: >>>>>>>>>>>>>>>> https://github.com/w3c/csswg-drafts/issues/4805 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The UseCounter is currently at 0.03% >>>>>>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3796 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This deprecation will have a window where we support both >>>>>>>>>>>>>>>> the old syntax and the new syntax so websites can switch to >>>>>>>>>>>>>>>> the new one. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink componentBlink>HTML>CustomElements >>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3ECustomElements> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG reviewNone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Websites which are currently using the old syntax and don't >>>>>>>>>>>>>>>> migrate to the new syntax will have CSS selectors which become >>>>>>>>>>>>>>>> invalid >>>>>>>>>>>>>>>> which would impact the styling of their custom elements. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Gecko*: No signal >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>>>>>>>> https://github.com/whatwg/html/pull/8467#issuecomment-1381645661 >>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Activation >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Switching to the new syntax should be quite easy. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>>>> Yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>> ?Yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Flag name on chrome://flagsNone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Finch feature nameNone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Non-finch justificationNone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Requires code in //chrome?False >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No milestones specified >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Open questions about a feature may be a source of future >>>>>>>>>>>>>>>> web compat or interop issues. Please list open issues (e.g. >>>>>>>>>>>>>>>> links to known >>>>>>>>>>>>>>>> github issues in the project for the feature specification) >>>>>>>>>>>>>>>> whose >>>>>>>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., >>>>>>>>>>>>>>>> changing to naming >>>>>>>>>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>> https://chromestatus.com/feature/5140610730426368 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>>>> <https://chromestatus.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+...@chromium.org. >>>>>>>>> >>>>>>>>> >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnPrTj5PhthsMfcr5kd340pbfzuCZik1%2B7J7FC-YkKL1g%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnPrTj5PhthsMfcr5kd340pbfzuCZik1%2B7J7FC-YkKL1g%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 on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fa862fff-e9eb-4aad-acc3-ca0849c72b06n%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fa862fff-e9eb-4aad-acc3-ca0849c72b06n%40chromium.org?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 on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_nhUTf5QZWscrcBZ5h6ixUkwLv%2BxKk9temGqPRt%3De_tw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_nhUTf5QZWscrcBZ5h6ixUkwLv%2BxKk9temGqPRt%3De_tw%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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2Bbw61Ekw_4D%3Dw31U_WcDQbOrO0HpbbRSvq7TmTPpFQpA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2Bbw61Ekw_4D%3Dw31U_WcDQbOrO0HpbbRSvq7TmTPpFQpA%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8o-LQsM7R_nyCbDfTnaKNgnjq5v8iV1naPSzMM-j4K1g%40mail.gmail.com.
