The new syntax is shipping in the milestone on the chromestatus, and at that time both syntaxes will work at the same time. To fix the deprecation message, just migrate to the new syntax.
I will put down a milestone for the removal when I have everything ready including an enterprise policy to re-enable the old syntax for a while. On Fri, Apr 5, 2024 at 3:38 AM Nils Intfeld <n.intf...@googlemail.com> wrote: > Is it possible to refresh the chrome status sites? > > So far I see two status tickets: > > The feature of the new Syntax: > https://chromestatus.com/feature/5586433790443520 > The removal of the old Syntax: > https://chromestatus.com/feature/5140610730426368 > > There are some things which are misleading for me: > - The removal ticket has no active development and no estimated shipping > milestone. > - The feature ticket says, the estimated shipping milestone is 125, but > what does that mean? Removal or add of the new syntax or both? > - I see deprecation warnings in 123 which lets me suggest that there will > be a removal soon? > - The chromestatus roadmap does not include that tickets (just an entry > in 122 for "behind a flag") > > Can you help me get those things clear? > > > > Mike Taylor schrieb am Dienstag, 2. Januar 2024 um 16:04:08 UTC+1: > >> If you don't mind - that way it will show up in our review queue. >> On 12/28/23 4:01 PM, Joey Arhar 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? >> >> 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 <chri...@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 <lukewa...@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 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- 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/CAK6btwKgNaZbR2JDQZWi6rC-G_%2BpbbykTYxVs1b2DaMG44BGrg%40mail.gmail.com.
