Intent to Implement: Custom state pseudo class

[TAMURA, Kent]

Contact emails tk...@chromium.org,rak...@chromium.org Explainer https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md Design docs/spec N/A

TAG review https://github.com/w3ctag/design-reviews/issues/428 Summary The feature enables custom elements to expose their states via :state() CSS pseudo class. Motivation Built-in elements have certain “states” that can change over time depending on user interaction and other factors, and are exposed to web authors through pseudo classes. For example, some form controls have the “invalid” state, which is exposed through the :invalid pseudo class. Like built-in elements, custom elements can have various states to be in too, and web authors want to expose these states in a similar fashion as the built-in elements. Risks

Interoperability and Compatibility No compatibility risk. This is a new feature, and won't break existing behavior. Low interoperability risk. Other browser vendors participated in the standardization discussion, and they didn't oppose. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive (https://github.com/w3c/webcomponents/issues/738) Ergonomics This feature is a part of Custom Element API. We don't think this could make it hard for Chrome to maintain good performance. Activation It's hard for developers to apply this feature until all major browsers ship it. It's difficult to make a polyfill for this feature. Security None. This feature has no security implication.

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? No WPT yet. This feature can be tested with the current WPT capability. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6537562418053120

--

TAMURA Kent
Software Engineer, Google

[Rakina Zata Amni]

Just want to add to the "Interoperability" point here, most recently this proposal was discussed in the TPAC 2019 WebComponents session (minutes here, it's the first topic discussed - search for "custom state").

Mozilla & Apple representatives, plus a few web devs were there and engaged in the discussion quite positively. In addition to the discussions before (in the issue and previous F2Fs), "No public signals" listed above is probably a bit conservative :)

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFW%2Bi%3DR4shZHfsxkoQ%2Bf9-%2BNZQ17f6kierzqWemF%2BD%3D6Q%40mail.gmail.com.

[Anne van Kesteren]

On Fri, Oct 11, 2019 at 12:50 PM Rakina Zata Amni <rak...@chromium.org> wrote:
> "No public signals" listed above is probably a bit conservative :)

Indeed, Mozilla is interested, FWIW.