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/baa94fae-6763-4e88-af6b-61e91715b724n%40chromium.org.
