On Sun, Oct 22, 2023 at 9:32 PM Domenic Denicola <dome...@chromium.org> wrote:
> > > On Sat, Oct 21, 2023 at 1:10 AM Chris Harrelson <chris...@chromium.org> > wrote: > >> >> >> 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! >> > > I'd like to get confirmation from this from the API Owners as a whole > before moving forward. This is the first time that Chromium, or indeed any > implementer, has said "we will not ship the contents of this PR" (until > some future condition, outside your control, comes to pass). But, supports > merging the PR. Indeed, this goes against the "should" in the WHATWG > working mode <https://whatwg.org/working-mode#additions> for feature > additions; "we would be willing to implement this after another implementer > ships to stable" is very different from "we would like to implement this > soon". > Chromium support already meets the "must" part of the definition you linked to. It also meets the "should" part as written. "We would like to implement this soon" is true. > So I'd appreciate it if the API Owners could, in their next discussion of > this topic, resolve whether or not Chromium supports :state() being added > to the HTML Standard, even before any other engine ships it. > The API owners are not in charge of the kind of decision. My API owner hat off, I (and Mason) have provided support as owners of the relevant part of Chromium. > >> >>> >>> 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/CAM0wra936hzGxQT%2BRvnXqtsS8CL6OHdiPCkBO%2BXaGL1hKucLgA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra936hzGxQT%2BRvnXqtsS8CL6OHdiPCkBO%2BXaGL1hKucLgA%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%2Bw8zRq6Ua6Ut9P40xN4bQm8zMUwmoEDD_zGZSmDHqqJ77w%40mail.gmail.com.
