Intent to Ship: Custom state pseudo class

963 views
Skip to first unread message

TAMURA, Kent

unread,
Feb 21, 2020, 3:55:00 AM2/21/20
to blink-dev
tk...@chromium.org, rakina@chromium.org, dom...@chromium.org https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md https://wicg.github.io/custom-state-pseudo-class/ https://github.com/w3ctag/design-reviews/issues/428 A concern about extensibility for non-boolean states was raised. We think we can add non-boolean support without breaking existing behavior. WICG/custom-state-pseudo-class#4

The feature lets custom elements to expose their states via the :state() CSS pseudo class. https://groups.google.com/a/chromium.org/d/msg/blink-dev/CApU9QIu3TM/jCR5dyZFDAAJ
No compatibility risk. This is a new feature, and won't break existing behavior. Low interoperability risk.
This feature was discussed several times in face-to-face meetings with Apple, Mozilla, and other web developer companies. We agreed on the current API. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive (https://github.com/w3c/webcomponents/issues/738) This feature is a part of Custom Element API. We don't think this could make it hard for Chrome to maintain good performance. 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. None. This feature has no security implication.
Yes Yes.

Dominic Farolino

unread,
Feb 21, 2020, 8:13:38 AM2/21/20
to blink-dev


On Friday, February 21, 2020 at 5:55:00 PM UTC+9, Kent Tamura wrote:
tk...@chromium.org, rakina@chromium.org, domenic@chromium.org https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md https://wicg.github.io/custom-state-pseudo-class/ https://github.com/w3ctag/design-reviews/issues/428 A concern about extensibility for non-boolean states was raised. We think we can add non-boolean support without breaking existing behavior. WICG/custom-state-pseudo-class#4

The feature lets custom elements to expose their states via the :state() CSS pseudo class. https://groups.google.com/a/chromium.org/d/msg/blink-dev/CApU9QIu3TM/jCR5dyZFDAAJ
No compatibility risk. This is a new feature, and won't break existing behavior. Low interoperability risk.
This feature was discussed several times in face-to-face meetings with Apple, Mozilla, and other web developer companies. We agreed on the current API. Firefox: No public signals Edge: No public signals Safari: No public signals

As mentioned in the Intent to Prototype thread, Firefox has expressed interest (though I didn't see a mozilla/standards-positions issue).

Mounir Lamouri

unread,
Feb 21, 2020, 4:46:51 PM2/21/20
to Dominic Farolino, blink-dev
On Fri, 21 Feb 2020 at 05:13, Dominic Farolino <d...@chromium.org> wrote:


On Friday, February 21, 2020 at 5:55:00 PM UTC+9, Kent Tamura wrote:
tk...@chromium.org, rakina@chromium.org, dom...@chromium.org https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md https://wicg.github.io/custom-state-pseudo-class/ https://github.com/w3ctag/design-reviews/issues/428 A concern about extensibility for non-boolean states was raised. We think we can add non-boolean support without breaking existing behavior. WICG/custom-state-pseudo-class#4

The feature lets custom elements to expose their states via the :state() CSS pseudo class. https://groups.google.com/a/chromium.org/d/msg/blink-dev/CApU9QIu3TM/jCR5dyZFDAAJ
No compatibility risk. This is a new feature, and won't break existing behavior. Low interoperability risk.
This feature was discussed several times in face-to-face meetings with Apple, Mozilla, and other web developer companies. We agreed on the current API. Firefox: No public signals Edge: No public signals Safari: No public signals

As mentioned in the Intent to Prototype thread, Firefox has expressed interest (though I didn't see a mozilla/standards-positions issue).

Are there bugs open or a place where we asked for feedback to Mozilla or Apple on this? It sounds like they were part of the discussions face-to-face. Is there a link to those discussions?
 
Web developers: Positive (https://github.com/w3c/webcomponents/issues/738) This feature is a part of Custom Element API. We don't think this could make it hard for Chrome to maintain good performance. 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. None. This feature has no security implication.
Yes Yes.

--
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/51302c1f-dc64-429f-bb8a-c37641f18fea%40chromium.org.

ayad181372537

unread,
Feb 27, 2020, 5:05:31 PM2/27/20
to TAMURA, Kent, blink-dev, ayad18...@gmail.com, عائض هداف مبارك ال عائذ, عائض هداف العايذ, البريد التقني, ayyad1 Alayaz‎




من: "TAMURA, Kent" <tk...@chromium.org>
التاريخ: ٢١‏/٢‏/٢٠٢٠ ١١:٥٤ ص (GMT+03:00)
إلى: blink-dev <blin...@chromium.org>
الموضوع: [blink-dev] Intent to Ship: Custom state pseudo class

AEDH HADDAF ALAEDH@LSS:/ /

--
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.

TAMURA, Kent

unread,
Feb 28, 2020, 3:52:55 AM2/28/20
to Mounir Lamouri, blink-dev
On Sat, Feb 22, 2020 at 6:46 AM 'Mounir Lamouri' via blink-dev <blin...@chromium.org> wrote:
On Fri, 21 Feb 2020 at 05:13, Dominic Farolino <d...@chromium.org> wrote:


On Friday, February 21, 2020 at 5:55:00 PM UTC+9, Kent Tamura wrote:
tk...@chromium.org, rakina@chromium.org, dom...@chromium.org https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md https://wicg.github.io/custom-state-pseudo-class/ https://github.com/w3ctag/design-reviews/issues/428 A concern about extensibility for non-boolean states was raised. We think we can add non-boolean support without breaking existing behavior. WICG/custom-state-pseudo-class#4

The feature lets custom elements to expose their states via the :state() CSS pseudo class. https://groups.google.com/a/chromium.org/d/msg/blink-dev/CApU9QIu3TM/jCR5dyZFDAAJ
No compatibility risk. This is a new feature, and won't break existing behavior. Low interoperability risk.
This feature was discussed several times in face-to-face meetings with Apple, Mozilla, and other web developer companies. We agreed on the current API. Firefox: No public signals Edge: No public signals Safari: No public signals

As mentioned in the Intent to Prototype thread, Firefox has expressed interest (though I didn't see a mozilla/standards-positions issue).

Are there bugs open or a place where we asked for feedback to Mozilla or Apple on this? It sounds like they were part of the discussions face-to-face. Is there a link to those discussions?

I have no plan to file bugs to ask for feedback because I don't think they have objections.  I'll file feature request bugs.
https://www.w3.org/2019/09/17-components-minutes.html#item01 is the minutes of the last F2F discussion.  You can confirm an Apple engineer and a Mozilla engineer made some non-negative comments.
 
 
Web developers: Positive (https://github.com/w3c/webcomponents/issues/738) This feature is a part of Custom Element API. We don't think this could make it hard for Chrome to maintain good performance. 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. None. This feature has no security implication.
Yes Yes.

--
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/51302c1f-dc64-429f-bb8a-c37641f18fea%40chromium.org.

--
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.

Mounir Lamouri

unread,
Feb 28, 2020, 1:04:54 PM2/28/20
to TAMURA, Kent, blink-dev
non-owner LGTM. It looks like this feature has good support. It sounds that it may be hard for web developers to benefit from it as long as it's not widely shipped but hopefully Firefox and Safari will follow and implement it too. Someone has to implement it first and given that there are no foreseeable backward incompatible changes, it sounds safe to go first.

-- Mounir

Joe Medley

unread,
Feb 28, 2020, 1:18:34 PM2/28/20
to TAMURA, Kent, blink-dev
Kent,

What version are you hoping to ship this in?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


--
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/CAGH7WqFqU%2B3PVoh4SGa_xr9tjGO8ACnKE3Wzoxng%2BknEUqyJ%3DA%40mail.gmail.com.

Mathias Bynens

unread,
Mar 1, 2020, 4:34:55 AM3/1/20
to TAMURA, Kent, blink-dev
What would DevTools support for this feature look like? I imagine the Styles pane could get an additional checkbox with a free-form input next to it, here:

image.png

But y’all have probably spent more time thinking about this, so… any ideas?

TAMURA, Kent

unread,
Mar 2, 2020, 1:46:59 AM3/2/20
to Mathias Bynens, blink-dev
Yeah, It's nice to have such functionality. I filed a feature-request issue; crbug.com/1057539

However, "Force element state" doesn't support element-type-specific pseudo classes at all. e.g. ':checked' for <input type=checkbox>
There might be a reason not to support them.


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgaBahUTkhUemZuo5sBPtb8zhVY7sYnR_RiJx%3D4iH6cykQ%40mail.gmail.com.

TAMURA, Kent

unread,
Jan 22, 2021, 2:37:23 AM1/22/21
to blink-dev
Hi,

After the I2S,
 - The TAG review finished.
 - CSSWG made a decision to change the syntax from :state(foo) to :--foo.
 - Updated the specification and the implementation for the CSSWG decision

I think it's ready to ship this feature.  API Owners, please review this.

Alex Russell

unread,
Jan 28, 2021, 3:04:23 PM1/28/21
to blink-dev, Kent Tamura
LGTM1

Mike West

unread,
Jan 28, 2021, 3:25:53 PM1/28/21
to blink-dev, Alex Russell, Kent Tamura
LGTM2.

yo...@yoav.ws

unread,
Jan 29, 2021, 7:34:25 AM1/29/21
to blink-dev, mk...@chromium.org, Alex Russell, Kent Tamura
LGTM3
Reply all
Reply to author
Forward
0 new messages