LGTM1 to ship. On Tue, Dec 26, 2023, 10:10 AM Joey Arhar <jar...@chromium.org> wrote:
> Thanks Luke! > Now that WebKit is shipping, can I get approval to implement and ship > :state(foo) alongside :--foo, then deprecate and remove :--foo? > > On Sat, Dec 23, 2023 at 12:17 PM Luke <lukewarlow...@gmail.com> wrote: > >> Fwiw CustomStateSets with the :state() syntax is now enabled by default >> on WebKit trunk. >> https://github.com/WebKit/WebKit/compare/8faf2e8d8d0c...26f4507be15d >> >> On Tuesday 24 October 2023 at 01:47:10 UTC+1 sligh...@chromium.org wrote: >> >>> For the avoidance of doubt, would just like to re-emphasise that landing >>> a new syntax is less attractive than compatible additions to the existing >>> one. If there are new problems being solved by the new syntax, it might be >>> helpful to explain what they are in a short summary somewhere, with bonus >>> points for why they cannot be addressed with compatible additions to the >>> shipped syntax. >>> >>> Best, >>> >>> Alex >>> >>> >>> On Mon, Oct 23, 2023, 3:47 PM Chris Wilson <cwi...@google.com> wrote: >>> >>>> I'll raise this at the next WHATWG SG meeting (tomorrow) as a working >>>> mode question, but I would be willing to say that "we will agree to make >>>> this change if someone else commits via shipping" would fulfill "we would >>>> like to implement this soon". The WHATWG Working Mode doesn't go into >>>> great detail about what happens if support is withdrawn prior to >>>> implementation - my informal understanding is that such features would end >>>> up getting pulled. I think this particular situation ends up effectively >>>> putting double the "supports" emphasis on another implementer; merging of >>>> the spec PR would be strongly driven by understanding of Apple's (in this >>>> case) commitment to support. This is personal opinion, of course, and I'll >>>> reflect back the discussion with the SG. >>>> >>>> On Mon, Oct 23, 2023 at 2:15 PM Daniel Bratell <brat...@gmail.com> >>>> wrote: >>>> >>>>> From my API owner hat: I don't mind the change in general but don't >>>>> think we should change from something that exists to something different >>>>> unless it brings more interoperability, which is why I think it is a >>>>> reasonable decision to not ship until at least another browser does the >>>>> same. >>>>> >>>>> The suggestion to avoid further massaging of the spec until another >>>>> browser has caught up was a suggestion, and not a MUST, and was not >>>>> intended to prevent anything already in the pipeline from landing. >>>>> >>>>> /Daniel >>>>> On 2023-10-23 16:46, Chris Harrelson wrote: >>>>> >>>>> >>>>> >>>>> On Sun, Oct 22, 2023 at 9:32 PM Domenic Denicola <dom...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 21, 2023 at 1:10 AM Chris Harrelson <chri...@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 < >>>>>>>> chri...@chromium.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Oct 19, 2023 at 6:48 PM Domenic Denicola < >>>>>>>>> dom...@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 < >>>>>>>>>> chri...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson < >>>>>>>>>>> chri...@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 < >>>>>>>>>>>> sligh...@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: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- > 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/CAK6btwJ5%3DbeekOhSGVSURGGD6U7Lm6AE5wbxvUNOq7FwFg92sg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJ5%3DbeekOhSGVSURGGD6U7Lm6AE5wbxvUNOq7FwFg92sg%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%2Bw-kDs29ZaGQPFEQC8oyWCYg7CBxz7AhOsGvKn5txwcDGg%40mail.gmail.com.
