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/CAGH7WqFtM4D_MbYo30Cd5%3DS1ZLL3WmGNyfxZWG62Q_%3DFi3Ee%3DA%40mail.gmail.com.
