> > 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(). 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.
