> The plan looks good, but I think chromestatus.com can't handle the removal of the old syntax and the addition of the new syntax in a single entry. > Joey, can you create a new entry for shipping the new syntax?
Sure: https://chromestatus.com/feature/5586433790443520 Should I start another intent to ship thread for it as well? On Wed, Dec 27, 2023 at 9:15 PM TAMURA, Kent <tk...@chromium.org> wrote: > The plan looks good, but I think chromestatus.com can't handle the > removal of the old syntax and the addition of the new syntax in a single > entry. > Joey, can you create a new entry for shipping the new syntax? > > On Wed, Dec 27, 2023 at 3:54 AM Chris Harrelson <chris...@chromium.org> > wrote: > >> 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> >>> . >>> >> > > -- > TAMURA Kent > Software Engineer, Google > > > -- 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/CAK6btwK42RLxygrC5wLdt25_658xSjwoknrUfAAQV5y%2BSokVWw%40mail.gmail.com.
