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 <jyass...@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 <slightly...@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: >>> >>>> The spec for the new syntax hasn't been merged yet, I haven't finished >>>> implementing it in chromium yet, and I don't have estimated milestones yet, >>>> but I'd like to get the API owners thoughts on whether this deprecation >>>> would be acceptable to help guide the spec discussion. >>>> >>>> I did some analysis of the top 8 websites on the chromestatus entry to >>>> see what the breakage would be like: >>>> https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing >>>> I found that most of them had the affected custom elements behind >>>> display:none rules that I had to manually remove in order to use them. >>>> There was only one website where there was actual breakage by default, in >>>> which case the carousel buttons didn't work on firefox and safari. If the >>>> new syntax is just for the CSS property and we keep CustomStateSet the >>>> same, then the affected website's buttons would continue to work but >>>> whatever custom styles they have (which I couldn't trigger) wouldn't apply >>>> anymore. >>>> >>>> Personally, I think that this breakage would not be bad especially if >>>> we keep CustomStateSet the same, and I kind of like :state(foo) more than >>>> :--foo. However, I might have not made it clear in the spec discussions yet >>>> that we have already shipped :--foo by default for several years. >>>> >>>> On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar <jar...@chromium.org> wrote: >>>> >>>>> Contact emailsjar...@chromium.org >>>>> >>>>> ExplainerNone >>>>> >>>>> Specificationhttps://github.com/whatwg/html/pull/8467 >>>>> >>>>> Summary >>>>> >>>>> CSS custom state, which allows custom elements to expose their own >>>>> pseudo-classes, was shipped here: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ >>>>> >>>>> This feature has not been implemented in gecko or webkit yet. I >>>>> recently made an effort to spec this feature in CSSWG and WHATWG, but >>>>> there >>>>> was pushback to change the syntax back from :--foo to :state(foo), and the >>>>> CSSWG has resolved to do this as well: >>>>> https://github.com/w3c/csswg-drafts/issues/4805 >>>>> >>>>> The UseCounter is currently at 0.03% >>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3796 >>>>> >>>>> This deprecation will have a window where we support both the old >>>>> syntax and the new syntax so websites can switch to the new one. >>>>> >>>>> >>>>> Blink componentBlink>HTML>CustomElements >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3ECustomElements> >>>>> >>>>> TAG reviewNone >>>>> >>>>> TAG review statusNot applicable >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> Websites which are currently using the old syntax and don't migrate to >>>>> the new syntax will have CSS selectors which become invalid which would >>>>> impact the styling of their custom elements. >>>>> >>>>> >>>>> *Gecko*: No signal >>>>> >>>>> *WebKit*: No signal ( >>>>> https://github.com/whatwg/html/pull/8467#issuecomment-1381645661) >>>>> >>>>> *Web developers*: No signals >>>>> >>>>> *Other signals*: >>>>> >>>>> Activation >>>>> >>>>> Switching to the new syntax should be quite easy. >>>>> >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> None >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> None >>>>> >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?Yes >>>>> >>>>> Flag name on chrome://flagsNone >>>>> >>>>> Finch feature nameNone >>>>> >>>>> Non-finch justificationNone >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> Estimated milestones >>>>> >>>>> No milestones specified >>>>> >>>>> >>>>> Anticipated spec changes >>>>> >>>>> Open questions about a feature may be a source of future web compat or >>>>> interop issues. Please list open issues (e.g. links to known github issues >>>>> in the project for the feature specification) whose resolution may >>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>> of >>>>> the API in a non-backward-compatible way). >>>>> None >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/5140610730426368 >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>> -- 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/CANh-dXmO6TQQ9gv%3D_hUtj1MSBTeht8oUv0M684KDt8-XH90Kgg%40mail.gmail.com.
