Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[PhistucK]

Sounds good!

> Debuggability

> These new pseudo-classes will be supported by the DevTools styles sidebar
automatically, just like every other pseudo-class.


Can it (along with other form-related ones, I guess) be added to the list
of toggle-able pseudo classes (shown when you click on the ":hov" button)?
[image: image.png]



☆*PhistucK*


On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:

> Contact emailsjar...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>
> Summary
>
> The :user-invalid and the :user-valid pseudo-classes represent an element
> with incorrect or correct input, respectively, but only after the user has
> significantly interacted with it. This is similar to :valid and :invalid,
> but with the added constraint that these pseudo-classes only match after
> the user has interacted with the element.
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is no interop/compat risks because this is a new feature that has
> already been implemented by safari and firefox and has WPTs.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> This feature will not be used in tandem with other platform APIs. The
> default usage of this API will not make it hard for chrome to maintain good
> performance.
>
>
> Activation
>
> It will not be challenging for developers to use this feature immediately.
> There is already an MDN article for this feature, so I don't think that we
> need additional outreach.
>
>
> Security
>
> There are no security risks for this feature.
>
>
> 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
>
> These new pseudo-classes will be supported by the DevTools styles sidebar
> automatically, just like every other pseudo-class.
>
>
> 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
> 
> ?Yes
>
> Flag name on chrome://flagsUserValidUserInvalid
>
> Finch feature nameUserValidUserInvalid
>
> Requires code in //chrome?False
>
> Availability expectationThis feature is already being shipped by safari
> and firefox, so it will be available on the web platform mainline as soon
> as we launch it.
>
> Adoption expectationThis feature will be considered the best practice for
> its use case as soon as we launch it.
>
> Adoption planThis is already implemented in safari and firefox, so we
> don't need to do anything in order to gain adoption of this feature.
>
> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>
> Estimated milestones
> Shipping on desktop 118
> DevTrial on desktop 118
> Shipping on Android 118
> DevTrial on Android 118
> Shipping on WebView 118
>
> 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).
> There are no anticipated spec changes.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5132477781245952
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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/CAK6btwKVw_WLSEZ348JyUXHVXfrNOBD7DN1U5svUkQ%3D1TLADFg%40mail.gmail.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/CABc02_JapbNo_kr-Voa3xAcWu2zqMD8h4G%2BtooHocanP5dxTDg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Joey Arhar]

Sure I can try setting up the force element state feature for it.

> along with other form-related ones

Any ones you have in mind? I could try to do them all at once

On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:

> Sounds good!
>
> > Debuggability
>
> > These new pseudo-classes will be supported by the DevTools styles
> sidebar automatically, just like every other pseudo-class.
>
>
> Can it (along with other form-related ones, I guess) be added to the list
> of toggle-able pseudo classes (shown when you click on the ":hov" button)?
> [image: image.png]
>
>
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>
>> Contact emailsjar...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>>
>> Summary
>>
>> The :user-invalid and the :user-valid pseudo-classes represent an element
>> with incorrect or correct input, respectively, but only after the user has
>> significantly interacted with it. This is similar to :valid and :invalid,
>> but with the added constraint that these pseudo-classes only match after
>> the user has interacted with the element.
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is no interop/compat risks because this is a new feature that has
>> already been implemented by safari and firefox and has WPTs.
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This feature will not be used in tandem with other platform APIs. The
>> default usage of this API will not make it hard for chrome to maintain good
>> performance.
>>
>>
>> Activation
>>
>> It will not be challenging for developers to use this feature
>> immediately. There is already an MDN article for this feature, so I don't
>> think that we need additional outreach.
>>
>>
>> Security
>>
>> There are no security risks for this feature.
>>
>>
>> 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
>>
>> These new pseudo-classes will be supported by the DevTools styles sidebar
>> automatically, just like every other pseudo-class.
>>
>>
>> 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
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsUserValidUserInvalid
>>
>> Finch feature nameUserValidUserInvalid
>>
>> Requires code in //chrome?False
>>
>> Availability expectationThis feature is already being shipped by safari
>> and firefox, so it will be available on the web platform mainline as soon
>> as we launch it.
>>
>> Adoption expectationThis feature will be considered the best practice
>> for its use case as soon as we launch it.
>>
>> Adoption planThis is already implemented in safari and firefox, so we
>> don't need to do anything in order to gain adoption of this feature.
>>
>> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>>
>> Estimated milestones
>> Shipping on desktop 118
>> DevTrial on desktop 118
>> Shipping on Android 118
>> DevTrial on Android 118
>> Shipping on WebView 118
>>
>> 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).
>> There are no anticipated spec changes.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5132477781245952
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> 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/CAK6btwKVw_WLSEZ348JyUXHVXfrNOBD7DN1U5svUkQ%3D1TLADFg%40mail.gmail.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...@chrom

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[PhistucK]

I guess all of them would be good. Not really why only a few pseudo-classes
are listed there...

☆*PhistucK*


On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:

> Sure I can try setting up the force element state feature for it.
>
> > along with other form-related ones
>
> Any ones you have in mind? I could try to do them all at once
>
> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>
>> Sounds good!
>>
>> > Debuggability
>>
>> > These new pseudo-classes will be supported by the DevTools styles
>> sidebar automatically, just like every other pseudo-class.
>>
>>
>> Can it (along with other form-related ones, I guess) be added to the list
>> of toggle-able pseudo classes (shown when you click on the ":hov" button)?
>> [image: image.png]
>>
>>
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>>
>>> Contact emailsjar...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>>>
>>> Summary
>>>
>>> The :user-invalid and the :user-valid pseudo-classes represent an
>>> element with incorrect or correct input, respectively, but only after the
>>> user has significantly interacted with it. This is similar to :valid and
>>> :invalid, but with the added constraint that these pseudo-classes only
>>> match after the user has interacted with the element.
>>>
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> There is no interop/compat risks because this is a new feature that has
>>> already been implemented by safari and firefox and has WPTs.
>>>
>>>
>>> *Gecko*: Shipped/Shipping
>>>
>>> *WebKit*: Shipped/Shipping
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This feature will not be used in tandem with other platform APIs. The
>>> default usage of this API will not make it hard for chrome to maintain good
>>> performance.
>>>
>>>
>>> Activation
>>>
>>> It will not be challenging for developers to use this feature
>>> immediately. There is already an MDN article for this feature, so I don't
>>> think that we need additional outreach.
>>>
>>>
>>> Security
>>>
>>> There are no security risks for this feature.
>>>
>>>
>>> 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
>>>
>>> These new pseudo-classes will be supported by the DevTools styles
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>>> 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
>>> 
>>> ?Yes
>>>
>>> Flag name on chrome://flagsUserValidUserInvalid
>>>
>>> Finch feature nameUserValidUserInvalid
>>>
>>> Requires code in //chrome?False
>>>
>>> Availability expectationThis feature is already being shipped by safari
>>> and firefox, so it will be available on the web platform mainline as soon
>>> as we launch it.
>>>
>>> Adoption expectationThis feature will be considered the best practice
>>> for its use case as soon as we launch it.
>>>
>>> Adoption planThis is already implemented in safari and firefox, so we
>>> don't need to do anything in order to gain adoption of this feature.
>>>
>>> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>>>
>>> Estimated milestones
>>> Shipping on desktop 118
>>> DevTrial on desktop 118
>>> Shipping on Android 118
>>> DevTrial on Android 118
>>> Shipping on WebView 118
>>>
>>> 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).
>>> There are no anticipated spec changes.
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5132477781245952
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> 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/CAK6btwKVw_WLSEZ348JyUXHVXfrNOBD7DN1U5svUkQ%3D1TLADFg%40mail.gmail.com
>>> 

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Mason Freed]

On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:

I guess all of them would be good. Not really why only a few pseudo-classes 
are listed there...


This sounds like a great feature request for devtools in general. I wonder 
if we could separate it out from shipping this one set of 2 pseudo classes 
though?  


 

☆*PhistucK*


On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:

Sure I can try setting up the force element state feature for it.

> along with other form-related ones

Any ones you have in mind? I could try to do them all at once

On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:

Sounds good!

> Debuggability

> These new pseudo-classes will be supported by the DevTools styles sidebar 
automatically, just like every other pseudo-class.


Can it (along with other form-related ones, I guess) be added to the list 
of toggle-able pseudo classes (shown when you click on the ":hov" button)?
[image: image.png]



☆*PhistucK*


On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:

Contact emailsjar...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos

Summary

The :user-invalid and the :user-valid pseudo-classes represent an element 
with incorrect or correct input, respectively, but only after the user has 
significantly interacted with it. This is similar to :valid and :invalid, 
but with the added constraint that these pseudo-classes only match after 
the user has interacted with the element.


Blink componentBlink>CSS 


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is no interop/compat risks because this is a new feature that has 
already been implemented by safari and firefox and has WPTs.


*Gecko*: Shipped/Shipping

*WebKit*: Shipped/Shipping

*Web developers*: No signals

*Other signals*:

Ergonomics

This feature will not be used in tandem with other platform APIs. The 
default usage of this API will not make it hard for chrome to maintain good 
performance.


Activation

It will not be challenging for developers to use this feature immediately. 
There is already an MDN article for this feature, so I don't think that we 
need additional outreach.


Security

There are no security risks for this feature.


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

These new pseudo-classes will be supported by the DevTools styles sidebar 
automatically, just like every other pseudo-class.


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 

?Yes

Flag name on chrome://flagsUserValidUserInvalid

Finch feature nameUserValidUserInvalid

Requires code in //chrome?False

Availability expectationThis feature is already being shipped by safari and 
firefox, so it will be available on the web platform mainline as soon as we 
launch it.

Adoption expectationThis feature will be considered the best practice for 
its use case as soon as we launch it.

Adoption planThis is already implemented in safari and firefox, so we don't 
need to do anything in order to gain adoption of this feature.

Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid

Estimated milestonesShipping on desktop118DevTrial on desktop118Shipping on 
Android118DevTrial on Android118Shipping on WebView118

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).
There are no anticipated spec changes.

Link to entry on the Chrome Platform Statushttps://chromestatus.com/
feature/5132477781245952

This intent message was generated by Chrome Platform Status 
.

-- 
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/CAK6btwKVw_WLSEZ348JyUXHVXfrNOBD7DN1U5svU
kQ%3D1TLADFg%40mail.gmail.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 

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[PhistucK]

Yeah, it was just a thought, maybe any new pseudo-class should
automatically be added.

☆*PhistucK*


On Sat, Aug 26, 2023 at 10:26 PM Mason Freed  wrote:

>
>
> On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:
>
> I guess all of them would be good. Not really why only a few
> pseudo-classes are listed there...
>
>
> This sounds like a great feature request for devtools in general. I wonder
> if we could separate it out from shipping this one set of 2 pseudo classes
> though?
>
>
>
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>
> Sure I can try setting up the force element state feature for it.
>
> > along with other form-related ones
>
> Any ones you have in mind? I could try to do them all at once
>
> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>
> Sounds good!
>
> > Debuggability
>
> > These new pseudo-classes will be supported by the DevTools styles
> sidebar automatically, just like every other pseudo-class.
>
>
> Can it (along with other form-related ones, I guess) be added to the list
> of toggle-able pseudo classes (shown when you click on the ":hov" button)?
> [image: image.png]
>
>
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>
> Contact emailsjar...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>
> Summary
>
> The :user-invalid and the :user-valid pseudo-classes represent an element
> with incorrect or correct input, respectively, but only after the user has
> significantly interacted with it. This is similar to :valid and :invalid,
> but with the added constraint that these pseudo-classes only match after
> the user has interacted with the element.
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is no interop/compat risks because this is a new feature that has
> already been implemented by safari and firefox and has WPTs.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> This feature will not be used in tandem with other platform APIs. The
> default usage of this API will not make it hard for chrome to maintain good
> performance.
>
>
> Activation
>
> It will not be challenging for developers to use this feature immediately.
> There is already an MDN article for this feature, so I don't think that we
> need additional outreach.
>
>
> Security
>
> There are no security risks for this feature.
>
>
> 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
>
> These new pseudo-classes will be supported by the DevTools styles sidebar
> automatically, just like every other pseudo-class.
>
>
> 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
> 
> ?Yes
>
> Flag name on chrome://flagsUserValidUserInvalid
>
> Finch feature nameUserValidUserInvalid
>
> Requires code in //chrome?False
>
> Availability expectationThis feature is already being shipped by safari
> and firefox, so it will be available on the web platform mainline as soon
> as we launch it.
>
> Adoption expectationThis feature will be considered the best practice for
> its use case as soon as we launch it.
>
> Adoption planThis is already implemented in safari and firefox, so we
> don't need to do anything in order to gain adoption of this feature.
>
> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>
> Estimated milestonesShipping on desktop118DevTrial on desktop118Shipping
> on Android118DevTrial on Android118Shipping on WebView118
>
> 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).
> There are no anticipated spec changes.
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5132477781245952
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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/CAK6btwKVw_WL

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Joey Arhar]

I filed a bug here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1476503

On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:

> Yeah, it was just a thought, maybe any new pseudo-class should
> automatically be added.
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 10:26 PM Mason Freed  wrote:
>
>>
>>
>> On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:
>>
>> I guess all of them would be good. Not really why only a few
>> pseudo-classes are listed there...
>>
>>
>> This sounds like a great feature request for devtools in general. I
>> wonder if we could separate it out from shipping this one set of 2 pseudo
>> classes though?
>>
>>
>>
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>>
>> Sure I can try setting up the force element state feature for it.
>>
>> > along with other form-related ones
>>
>> Any ones you have in mind? I could try to do them all at once
>>
>> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>>
>> Sounds good!
>>
>> > Debuggability
>>
>> > These new pseudo-classes will be supported by the DevTools styles
>> sidebar automatically, just like every other pseudo-class.
>>
>>
>> Can it (along with other form-related ones, I guess) be added to the list
>> of toggle-able pseudo classes (shown when you click on the ":hov" button)?
>> [image: image.png]
>>
>>
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>>
>> Contact emailsjar...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>>
>> Summary
>>
>> The :user-invalid and the :user-valid pseudo-classes represent an element
>> with incorrect or correct input, respectively, but only after the user has
>> significantly interacted with it. This is similar to :valid and :invalid,
>> but with the added constraint that these pseudo-classes only match after
>> the user has interacted with the element.
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is no interop/compat risks because this is a new feature that has
>> already been implemented by safari and firefox and has WPTs.
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This feature will not be used in tandem with other platform APIs. The
>> default usage of this API will not make it hard for chrome to maintain good
>> performance.
>>
>>
>> Activation
>>
>> It will not be challenging for developers to use this feature
>> immediately. There is already an MDN article for this feature, so I don't
>> think that we need additional outreach.
>>
>>
>> Security
>>
>> There are no security risks for this feature.
>>
>>
>> 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
>>
>> These new pseudo-classes will be supported by the DevTools styles sidebar
>> automatically, just like every other pseudo-class.
>>
>>
>> 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
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsUserValidUserInvalid
>>
>> Finch feature nameUserValidUserInvalid
>>
>> Requires code in //chrome?False
>>
>> Availability expectationThis feature is already being shipped by safari
>> and firefox, so it will be available on the web platform mainline as soon
>> as we launch it.
>>
>> Adoption expectationThis feature will be considered the best practice
>> for its use case as soon as we launch it.
>>
>> Adoption planThis is already implemented in safari and firefox, so we
>> don't need to do anything in order to gain adoption of this feature.
>>
>> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>>
>> Estimated milestonesShipping on desktop118DevTrial on desktop118Shipping
>> on Android118DevTrial on Android118Shipping on WebView118
>>
>> 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).
>> There are no anticipated spec changes.
>>
>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>> feature/5132477781245952
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message b

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[PhistucK]

Thank you!

☆*PhistucK*


On Mon, Aug 28, 2023 at 4:46 PM Joey Arhar  wrote:

> I filed a bug here:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1476503
>
> On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:
>
>> Yeah, it was just a thought, maybe any new pseudo-class should
>> automatically be added.
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 10:26 PM Mason Freed  wrote:
>>
>>>
>>>
>>> On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:
>>>
>>> I guess all of them would be good. Not really why only a few
>>> pseudo-classes are listed there...
>>>
>>>
>>> This sounds like a great feature request for devtools in general. I
>>> wonder if we could separate it out from shipping this one set of 2 pseudo
>>> classes though?
>>>
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>>>
>>> Sure I can try setting up the force element state feature for it.
>>>
>>> > along with other form-related ones
>>>
>>> Any ones you have in mind? I could try to do them all at once
>>>
>>> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>>>
>>> Sounds good!
>>>
>>> > Debuggability
>>>
>>> > These new pseudo-classes will be supported by the DevTools styles
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>>> Can it (along with other form-related ones, I guess) be added to the
>>> list of toggle-able pseudo classes (shown when you click on the ":hov"
>>> button)?
>>> [image: image.png]
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>>>
>>> Contact emailsjar...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>>>
>>> Summary
>>>
>>> The :user-invalid and the :user-valid pseudo-classes represent an
>>> element with incorrect or correct input, respectively, but only after the
>>> user has significantly interacted with it. This is similar to :valid and
>>> :invalid, but with the added constraint that these pseudo-classes only
>>> match after the user has interacted with the element.
>>>
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> There is no interop/compat risks because this is a new feature that has
>>> already been implemented by safari and firefox and has WPTs.
>>>
>>>
>>> *Gecko*: Shipped/Shipping
>>>
>>> *WebKit*: Shipped/Shipping
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This feature will not be used in tandem with other platform APIs. The
>>> default usage of this API will not make it hard for chrome to maintain good
>>> performance.
>>>
>>>
>>> Activation
>>>
>>> It will not be challenging for developers to use this feature
>>> immediately. There is already an MDN article for this feature, so I don't
>>> think that we need additional outreach.
>>>
>>>
>>> Security
>>>
>>> There are no security risks for this feature.
>>>
>>>
>>> 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
>>>
>>> These new pseudo-classes will be supported by the DevTools styles
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>>> 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
>>> 
>>> ?Yes
>>>
>>> Flag name on chrome://flagsUserValidUserInvalid
>>>
>>> Finch feature nameUserValidUserInvalid
>>>
>>> Requires code in //chrome?False
>>>
>>> Availability expectationThis feature is already being shipped by safari
>>> and firefox, so it will be available on the web platform mainline as soon
>>> as we launch it.
>>>
>>> Adoption expectationThis feature will be considered the best practice
>>> for its use case as soon as we launch it.
>>>
>>> Adoption planThis is already implemented in safari and firefox, so we
>>> don't need to do anything in order to gain adoption of this feature.
>>>
>>> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>>>
>>> Estimated milestonesShipping on desktop118DevTrial on desktop118Shipping
>>> on Android118DevTrial on Android118Shipping on WebView118
>>>
>>> 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).
>>> There are no anticipated s

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Mike Taylor]

I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states 
that this and the :invalid/:valid flavors should apply to forms and 
fieldset elements. It doesn't look like the WPTs test for that - what do 
we do for those elements, and do you know if it's interoperable?


On 8/28/23 11:54 AM, PhistucK wrote:

Thank you!

☆*PhistucK*


On Mon, Aug 28, 2023 at 4:46 PM Joey Arhar  wrote:

I filed a bug here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1476503

On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:

Yeah, it was just a thought, maybe any new pseudo-class should
automatically be added.

☆*PhistucK*


On Sat, Aug 26, 2023 at 10:26 PM Mason Freed
 wrote:



On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK
wrote:

I guess all of them would be good. Not really why only
a few pseudo-classes are listed there...


This sounds like a great feature request for devtools in
general. I wonder if we could separate it out from
shipping this one set of 2 pseudo classes though?


☆*PhistucK*


On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar
 wrote:

Sure I can try setting up the force element state
feature for it.

> along with other form-related ones

Any ones you have in mind? I could try to do them
all at once

On Sat, Aug 26, 2023 at 10:00 AM PhistucK
 wrote:

Sounds good!

> Debuggability

> These new pseudo-classes will be supported by
the DevTools styles sidebar automatically,
just like every other pseudo-class.


Can it (along with other form-related ones, I
guess) be added to the list of toggle-able
pseudo classes (shown when you click on the
":hov" button)?

image.png



☆*PhistucK*


On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar
 wrote:

Contact emailsjar...@chromium.org

ExplainerNone


Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos


Summary

The :user-invalid and the :user-valid
pseudo-classes represent an element with
incorrect or correct input, respectively,
but only after the user has significantly
interacted with it. This is similar to
:valid and :invalid, but with the added
constraint that these pseudo-classes only
match after the user has interacted with
the element.



Blink componentBlink>CSS



TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is no interop/compat risks because
this is a new feature that has already
been implemented by safari and firefox and
has WPTs.



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: No signals

/Other signals/:

Ergonomics

This feature will not be used in tandem
with other platform APIs. The default
usage of this API will not make it hard
for chrome to maintain good performance.



Activation

It will not be challenging for developers
to use this feature immediately. There is
already an MDN article for this feature,
so I don't think that we need additional
outreach.



Security

There are no security risks for this feature.



WebView application risks

Does this intent deprecate or change
  

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Joey Arhar]

> I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states
that this and the :invalid/:valid flavors should apply to forms and
fieldset elements. It doesn't look like the WPTs test for that - what do we
do for those elements, and do you know if it's interoperable?

We don't have WPTs at the moment. Based on my testing, it looks like
firefox chrome and safari all don't apply :user-valid or :user-invalid to
form elements. I opened a spec issue to discuss:
https://github.com/w3c/csswg-drafts/issues/9257

On Mon, Aug 28, 2023 at 9:01 AM Mike Taylor  wrote:

> I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states
> that this and the :invalid/:valid flavors should apply to forms and
> fieldset elements. It doesn't look like the WPTs test for that - what do we
> do for those elements, and do you know if it's interoperable?
> On 8/28/23 11:54 AM, PhistucK wrote:
>
> Thank you!
>
> ☆*PhistucK*
>
>
> On Mon, Aug 28, 2023 at 4:46 PM Joey Arhar  wrote:
>
>> I filed a bug here:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1476503
>>
>> On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:
>>
>>> Yeah, it was just a thought, maybe any new pseudo-class should
>>> automatically be added.
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 10:26 PM Mason Freed 
>>> wrote:
>>>


 On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:

 I guess all of them would be good. Not really why only a few
 pseudo-classes are listed there...


 This sounds like a great feature request for devtools in general. I
 wonder if we could separate it out from shipping this one set of 2 pseudo
 classes though?




 ☆*PhistucK*


 On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:

 Sure I can try setting up the force element state feature for it.

 > along with other form-related ones

 Any ones you have in mind? I could try to do them all at once

 On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:

 Sounds good!

 > Debuggability

 > These new pseudo-classes will be supported by the DevTools styles
 sidebar automatically, just like every other pseudo-class.


 Can it (along with other form-related ones, I guess) be added to the
 list of toggle-able pseudo classes (shown when you click on the ":hov"
 button)?
 [image: image.png]



 ☆*PhistucK*


 On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:

 Contact emailsjar...@chromium.org

 ExplainerNone

 Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos

 Summary

 The :user-invalid and the :user-valid pseudo-classes represent an
 element with incorrect or correct input, respectively, but only after the
 user has significantly interacted with it. This is similar to :valid and
 :invalid, but with the added constraint that these pseudo-classes only
 match after the user has interacted with the element.


 Blink componentBlink>CSS
 

 TAG reviewNone

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 There is no interop/compat risks because this is a new feature that has
 already been implemented by safari and firefox and has WPTs.


 *Gecko*: Shipped/Shipping

 *WebKit*: Shipped/Shipping

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 This feature will not be used in tandem with other platform APIs. The
 default usage of this API will not make it hard for chrome to maintain good
 performance.


 Activation

 It will not be challenging for developers to use this feature
 immediately. There is already an MDN article for this feature, so I don't
 think that we need additional outreach.


 Security

 There are no security risks for this feature.


 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

 These new pseudo-classes will be supported by the DevTools styles
 sidebar automatically, just like every other pseudo-class.


 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
 
 ?Yes

 Flag name on chrome://flagsUserValidUserInvalid

 Finch feature nameUserValidUserInvalid

 Requires code in //chrome?False

 Availability expectationThis

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Daniel Bratell]

I think those are the ones that are hard to manually trigger while 
working in the debugger.


/Daniel

On 2023-08-26 19:30, PhistucK wrote:
I guess all of them would be good. Not really why only a few 
pseudo-classes are listed there...


☆*PhistucK*


On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:

Sure I can try setting up the force element state feature for it.

> along with other form-related ones

Any ones you have in mind? I could try to do them all at once

On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:

Sounds good!

> Debuggability

> These new pseudo-classes will be supported by the DevTools
styles sidebar automatically, just like every other pseudo-class.


Can it (along with other form-related ones, I guess) be added
to the list of toggle-able pseudo classes (shown when you
click on the ":hov" button)?

image.png



☆*PhistucK*


On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar
 wrote:


Contact emails

jar...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/selectors-4/#user-pseudos


Summary

The :user-invalid and the :user-valid pseudo-classes
represent an element with incorrect or correct input,
respectively, but only after the user has significantly
interacted with it. This is similar to :valid and
:invalid, but with the added constraint that these
pseudo-classes only match after the user has interacted
with the element.



Blink component

Blink>CSS




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

There is no interop/compat risks because this is a new
feature that has already been implemented by safari and
firefox and has WPTs.



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: No signals

/Other signals/:


Ergonomics

This feature will not be used in tandem with other
platform APIs. The default usage of this API will not make
it hard for chrome to maintain good performance.



Activation

It will not be challenging for developers to use this
feature immediately. There is already an MDN article for
this feature, so I don't think that we need additional
outreach.



Security

There are no security risks for this feature.



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

These new pseudo-classes will be supported by the DevTools
styles sidebar automatically, just like every other
pseudo-class.



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

?

Yes


Flag name on chrome://flags

UserValidUserInvalid


Finch feature name

UserValidUserInvalid


Requires code in //chrome?

False


Availability expectation

This feature is already being shipped by safari and
firefox, so it will be available on the web platform
mainline as soon as we launch it.


Adoption expectation

This feature will be considered the best practice for its
use case as soon as we launch it.


Adoption plan

This is already implemented in safari and firefox, so we
don't need to do anything in order to gain adoption of
this feature.


Sample links

https://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118

Shipping on WebView 118



  

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Joey Arhar]

> > I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states
that this and the :invalid/:valid flavors should apply to forms and
fieldset elements. It doesn't look like the WPTs test for that - what do we
do for those elements, and do you know if it's interoperable?
>
> We don't have WPTs at the moment. Based on my testing, it looks like
firefox chrome and safari all don't apply :user-valid or :user-invalid to
form elements. I opened a spec issue to discuss:
https://github.com/w3c/csswg-drafts/issues/9257

I am adding WPTs here:
https://chromium-review.googlesource.com/c/chromium/src/+/4839394
I think that we have rough consensus in the spec issue as well to not apply
:user-valid or :user-invalid to form or fieldset elements.

On Wed, Aug 30, 2023 at 5:15 PM Daniel Bratell  wrote:

> I think those are the ones that are hard to manually trigger while working
> in the debugger.
>
> /Daniel
> On 2023-08-26 19:30, PhistucK wrote:
>
> I guess all of them would be good. Not really why only a few
> pseudo-classes are listed there...
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>
>> Sure I can try setting up the force element state feature for it.
>>
>> > along with other form-related ones
>>
>> Any ones you have in mind? I could try to do them all at once
>>
>> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>>
>>> Sounds good!
>>>
>>> > Debuggability
>>>
>>> > These new pseudo-classes will be supported by the DevTools styles
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>>> Can it (along with other form-related ones, I guess) be added to the
>>> list of toggle-able pseudo classes (shown when you click on the ":hov"
>>> button)?
>>> [image: image.png]
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>>>
 Contact emails jar...@chromium.org

 Explainer None

 Specification https://drafts.csswg.org/selectors-4/#user-pseudos

 Summary

 The :user-invalid and the :user-valid pseudo-classes represent an
 element with incorrect or correct input, respectively, but only after the
 user has significantly interacted with it. This is similar to :valid and
 :invalid, but with the added constraint that these pseudo-classes only
 match after the user has interacted with the element.


 Blink component Blink>CSS
 

 TAG review None

 TAG review status Not applicable

 Risks


 Interoperability and Compatibility

 There is no interop/compat risks because this is a new feature that has
 already been implemented by safari and firefox and has WPTs.


 *Gecko*: Shipped/Shipping

 *WebKit*: Shipped/Shipping

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 This feature will not be used in tandem with other platform APIs. The
 default usage of this API will not make it hard for chrome to maintain good
 performance.


 Activation

 It will not be challenging for developers to use this feature
 immediately. There is already an MDN article for this feature, so I don't
 think that we need additional outreach.


 Security

 There are no security risks for this feature.


 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

 These new pseudo-classes will be supported by the DevTools styles
 sidebar automatically, just like every other pseudo-class.


 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
 
 ? Yes

 Flag name on chrome://flags UserValidUserInvalid

 Finch feature name UserValidUserInvalid

 Requires code in //chrome? False

 Availability expectation This feature is already being shipped by
 safari and firefox, so it will be available on the web platform mainline as
 soon as we launch it.

 Adoption expectation This feature will be considered the best practice
 for its use case as soon as we launch it.

 Adoption plan This is already implemented in safari and firefox, so we
 don't need to do anything in order to gain adoption of this feature.

 Sample links
 https://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid

 Estimated milestones
 Shipping on desktop 118
 DevTrial on desktop 118
 Shipping on Android 118
 DevTrial on Android 118
 Shipping on WebView 118

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Philip Jägenstedt]

Thanks for adding that test Joey!

https://staging.wpt.fyi/results/css/selectors/valid-invalid-form-fieldset.html?label=pr_head&max-count=1&pr=41801
shows that it also passes on Firefox. Not sure why Safari didn't run, but
that's not your fault and not something to block on.

LGTM1, and thanks for working on this!

On Mon, Sep 4, 2023 at 3:46 PM Joey Arhar  wrote:

> > > I see that https://drafts.csswg.org/selectors-4/#issue-df919919
> states that this and the :invalid/:valid flavors should apply to forms and
> fieldset elements. It doesn't look like the WPTs test for that - what do we
> do for those elements, and do you know if it's interoperable?
> >
> > We don't have WPTs at the moment. Based on my testing, it looks like
> firefox chrome and safari all don't apply :user-valid or :user-invalid to
> form elements. I opened a spec issue to discuss:
> https://github.com/w3c/csswg-drafts/issues/9257
>
> I am adding WPTs here:
> https://chromium-review.googlesource.com/c/chromium/src/+/4839394
> I think that we have rough consensus in the spec issue as well to not
> apply :user-valid or :user-invalid to form or fieldset elements.
>
> On Wed, Aug 30, 2023 at 5:15 PM Daniel Bratell 
> wrote:
>
>> I think those are the ones that are hard to manually trigger while
>> working in the debugger.
>>
>> /Daniel
>> On 2023-08-26 19:30, PhistucK wrote:
>>
>> I guess all of them would be good. Not really why only a few
>> pseudo-classes are listed there...
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>>
>>> Sure I can try setting up the force element state feature for it.
>>>
>>> > along with other form-related ones
>>>
>>> Any ones you have in mind? I could try to do them all at once
>>>
>>> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>>>
 Sounds good!

 > Debuggability

 > These new pseudo-classes will be supported by the DevTools styles
 sidebar automatically, just like every other pseudo-class.


 Can it (along with other form-related ones, I guess) be added to the
 list of toggle-able pseudo classes (shown when you click on the ":hov"
 button)?
 [image: image.png]



 ☆*PhistucK*


 On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:

> Contact emails jar...@chromium.org
>
> Explainer None
>
> Specification https://drafts.csswg.org/selectors-4/#user-pseudos
>
> Summary
>
> The :user-invalid and the :user-valid pseudo-classes represent an
> element with incorrect or correct input, respectively, but only after the
> user has significantly interacted with it. This is similar to :valid and
> :invalid, but with the added constraint that these pseudo-classes only
> match after the user has interacted with the element.
>
>
> Blink component Blink>CSS
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is no interop/compat risks because this is a new feature that
> has already been implemented by safari and firefox and has WPTs.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> This feature will not be used in tandem with other platform APIs. The
> default usage of this API will not make it hard for chrome to maintain 
> good
> performance.
>
>
> Activation
>
> It will not be challenging for developers to use this feature
> immediately. There is already an MDN article for this feature, so I don't
> think that we need additional outreach.
>
>
> Security
>
> There are no security risks for this feature.
>
>
> 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
>
> These new pseudo-classes will be supported by the DevTools styles
> sidebar automatically, just like every other pseudo-class.
>
>
> 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
> 
> ? Yes
>
> Flag name on chrome://flags UserValidUserInvalid
>
> Finch feature name UserValidUserInvalid
>
> Requires code in //chrome? False
>
> Availability expectation This feature is already being shipped by
> safari and firefox, so it will be available on the web platform mainline 
> as
> soon as we launch it.
>
>>

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Alex Russell]

Why is there no TAG review filed here?

On Wednesday, September 6, 2023 at 8:42:23 AM UTC-7 Philip Jägenstedt wrote:

> Thanks for adding that test Joey!
>
>
> https://staging.wpt.fyi/results/css/selectors/valid-invalid-form-fieldset.html?label=pr_head&max-count=1&pr=41801
>  
> shows that it also passes on Firefox. Not sure why Safari didn't run, but 
> that's not your fault and not something to block on.
>
> LGTM1, and thanks for working on this!
>
> On Mon, Sep 4, 2023 at 3:46 PM Joey Arhar  wrote:
>
>> > > I see that https://drafts.csswg.org/selectors-4/#issue-df919919 
>> states that this and the :invalid/:valid flavors should apply to forms and 
>> fieldset elements. It doesn't look like the WPTs test for that - what do we 
>> do for those elements, and do you know if it's interoperable?
>> > 
>> > We don't have WPTs at the moment. Based on my testing, it looks like 
>> firefox chrome and safari all don't apply :user-valid or :user-invalid to 
>> form elements. I opened a spec issue to discuss: 
>> https://github.com/w3c/csswg-drafts/issues/9257
>>
>> I am adding WPTs here: 
>> https://chromium-review.googlesource.com/c/chromium/src/+/4839394
>> I think that we have rough consensus in the spec issue as well to not 
>> apply :user-valid or :user-invalid to form or fieldset elements.
>>
>> On Wed, Aug 30, 2023 at 5:15 PM Daniel Bratell  
>> wrote:
>>
>>> I think those are the ones that are hard to manually trigger while 
>>> working in the debugger.
>>>
>>> /Daniel
>>> On 2023-08-26 19:30, PhistucK wrote:
>>>
>>> I guess all of them would be good. Not really why only a few 
>>> pseudo-classes are listed there...
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>>>
 Sure I can try setting up the force element state feature for it.

 > along with other form-related ones

 Any ones you have in mind? I could try to do them all at once

 On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:

> Sounds good!
>
> > Debuggability
>
> > These new pseudo-classes will be supported by the DevTools styles 
> sidebar automatically, just like every other pseudo-class.
>
>
> Can it (along with other form-related ones, I guess) be added to the 
> list of toggle-able pseudo classes (shown when you click on the ":hov" 
> button)?
> [image: image.png] 
>
>
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  
> wrote:
>
>> Contact emails jar...@chromium.org
>>
>> Explainer None
>>
>> Specification https://drafts.csswg.org/selectors-4/#user-pseudos
>>
>> Summary 
>>
>> The :user-invalid and the :user-valid pseudo-classes represent an 
>> element with incorrect or correct input, respectively, but only after 
>> the 
>> user has significantly interacted with it. This is similar to :valid and 
>> :invalid, but with the added constraint that these pseudo-classes only 
>> match after the user has interacted with the element.
>>
>>
>> Blink component Blink>CSS 
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> There is no interop/compat risks because this is a new feature that 
>> has already been implemented by safari and firefox and has WPTs.
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics 
>>
>> This feature will not be used in tandem with other platform APIs. The 
>> default usage of this API will not make it hard for chrome to maintain 
>> good 
>> performance.
>>
>>
>> Activation 
>>
>> It will not be challenging for developers to use this feature 
>> immediately. There is already an MDN article for this feature, so I 
>> don't 
>> think that we need additional outreach.
>>
>>
>> Security 
>>
>> There are no security risks for this feature.
>>
>>
>> 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 
>>
>> These new pseudo-classes will be supported by the DevTools styles 
>> sidebar automatically, just like every other pseudo-class.
>>
>>
>> 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 
>> 
>> ? Yes
>>
>> Flag n

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Alex Russell]

Was corrected in the API OWNERS meeting re: TAG review; apologies for the 
noise. LGTM2

On Wednesday, September 6, 2023 at 8:45:28 AM UTC-7 Alex Russell wrote:

> Why is there no TAG review filed here?
>
> On Wednesday, September 6, 2023 at 8:42:23 AM UTC-7 Philip Jägenstedt 
> wrote:
>
>> Thanks for adding that test Joey!
>>
>>
>> https://staging.wpt.fyi/results/css/selectors/valid-invalid-form-fieldset.html?label=pr_head&max-count=1&pr=41801
>>  
>> shows that it also passes on Firefox. Not sure why Safari didn't run, but 
>> that's not your fault and not something to block on.
>>
>> LGTM1, and thanks for working on this!
>>
>> On Mon, Sep 4, 2023 at 3:46 PM Joey Arhar  wrote:
>>
>>> > > I see that https://drafts.csswg.org/selectors-4/#issue-df919919 
>>> states that this and the :invalid/:valid flavors should apply to forms and 
>>> fieldset elements. It doesn't look like the WPTs test for that - what do we 
>>> do for those elements, and do you know if it's interoperable?
>>> > 
>>> > We don't have WPTs at the moment. Based on my testing, it looks like 
>>> firefox chrome and safari all don't apply :user-valid or :user-invalid to 
>>> form elements. I opened a spec issue to discuss: 
>>> https://github.com/w3c/csswg-drafts/issues/9257
>>>
>>> I am adding WPTs here: 
>>> https://chromium-review.googlesource.com/c/chromium/src/+/4839394
>>> I think that we have rough consensus in the spec issue as well to not 
>>> apply :user-valid or :user-invalid to form or fieldset elements.
>>>
>>> On Wed, Aug 30, 2023 at 5:15 PM Daniel Bratell  
>>> wrote:
>>>
 I think those are the ones that are hard to manually trigger while 
 working in the debugger.

 /Daniel
 On 2023-08-26 19:30, PhistucK wrote:

 I guess all of them would be good. Not really why only a few 
 pseudo-classes are listed there...

 ☆*PhistucK*


 On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:

> Sure I can try setting up the force element state feature for it.
>
> > along with other form-related ones
>
> Any ones you have in mind? I could try to do them all at once
>
> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>
>> Sounds good!
>>
>> > Debuggability
>>
>> > These new pseudo-classes will be supported by the DevTools styles 
>> sidebar automatically, just like every other pseudo-class.
>>
>>
>> Can it (along with other form-related ones, I guess) be added to the 
>> list of toggle-able pseudo classes (shown when you click on the ":hov" 
>> button)?
>> [image: image.png] 
>>
>>
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  
>> wrote:
>>
>>> Contact emails jar...@chromium.org
>>>
>>> Explainer None
>>>
>>> Specification https://drafts.csswg.org/selectors-4/#user-pseudos
>>>
>>> Summary 
>>>
>>> The :user-invalid and the :user-valid pseudo-classes represent an 
>>> element with incorrect or correct input, respectively, but only after 
>>> the 
>>> user has significantly interacted with it. This is similar to :valid 
>>> and 
>>> :invalid, but with the added constraint that these pseudo-classes only 
>>> match after the user has interacted with the element.
>>>
>>>
>>> Blink component Blink>CSS 
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> There is no interop/compat risks because this is a new feature that 
>>> has already been implemented by safari and firefox and has WPTs.
>>>
>>>
>>> *Gecko*: Shipped/Shipping
>>>
>>> *WebKit*: Shipped/Shipping
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics 
>>>
>>> This feature will not be used in tandem with other platform APIs. 
>>> The default usage of this API will not make it hard for chrome to 
>>> maintain 
>>> good performance.
>>>
>>>
>>> Activation 
>>>
>>> It will not be challenging for developers to use this feature 
>>> immediately. There is already an MDN article for this feature, so I 
>>> don't 
>>> think that we need additional outreach.
>>>
>>>
>>> Security 
>>>
>>> There are no security risks for this feature.
>>>
>>>
>>> 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 
>>>
>>> These new pseudo-classes will be supported by the DevTools styles 
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Yoav Weiss]

LGTM3

On Wed, Sep 6, 2023 at 5:49 PM Alex Russell 
wrote:

> Was corrected in the API OWNERS meeting re: TAG review; apologies for the
> noise. LGTM2
>
> On Wednesday, September 6, 2023 at 8:45:28 AM UTC-7 Alex Russell wrote:
>
>> Why is there no TAG review filed here?
>>
>> On Wednesday, September 6, 2023 at 8:42:23 AM UTC-7 Philip Jägenstedt
>> wrote:
>>
>>> Thanks for adding that test Joey!
>>>
>>>
>>> https://staging.wpt.fyi/results/css/selectors/valid-invalid-form-fieldset.html?label=pr_head&max-count=1&pr=41801
>>> shows that it also passes on Firefox. Not sure why Safari didn't run, but
>>> that's not your fault and not something to block on.
>>>
>>> LGTM1, and thanks for working on this!
>>>
>>> On Mon, Sep 4, 2023 at 3:46 PM Joey Arhar  wrote:
>>>
 > > I see that https://drafts.csswg.org/selectors-4/#issue-df919919
 states that this and the :invalid/:valid flavors should apply to forms and
 fieldset elements. It doesn't look like the WPTs test for that - what do we
 do for those elements, and do you know if it's interoperable?
 >
 > We don't have WPTs at the moment. Based on my testing, it looks like
 firefox chrome and safari all don't apply :user-valid or :user-invalid to
 form elements. I opened a spec issue to discuss:
 https://github.com/w3c/csswg-drafts/issues/9257

 I am adding WPTs here:
 https://chromium-review.googlesource.com/c/chromium/src/+/4839394
 I think that we have rough consensus in the spec issue as well to not
 apply :user-valid or :user-invalid to form or fieldset elements.

 On Wed, Aug 30, 2023 at 5:15 PM Daniel Bratell 
 wrote:

> I think those are the ones that are hard to manually trigger while
> working in the debugger.
>
> /Daniel
> On 2023-08-26 19:30, PhistucK wrote:
>
> I guess all of them would be good. Not really why only a few
> pseudo-classes are listed there...
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar 
> wrote:
>
>> Sure I can try setting up the force element state feature for it.
>>
>> > along with other form-related ones
>>
>> Any ones you have in mind? I could try to do them all at once
>>
>> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>>
>>> Sounds good!
>>>
>>> > Debuggability
>>>
>>> > These new pseudo-classes will be supported by the DevTools styles
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>>> Can it (along with other form-related ones, I guess) be added to the
>>> list of toggle-able pseudo classes (shown when you click on the ":hov"
>>> button)?
>>> [image: image.png]
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar 
>>> wrote:
>>>
 Contact emails jar...@chromium.org

 Explainer None

 Specification https://drafts.csswg.org/selectors-4/#user-pseudos

 Summary

 The :user-invalid and the :user-valid pseudo-classes represent an
 element with incorrect or correct input, respectively, but only after 
 the
 user has significantly interacted with it. This is similar to :valid 
 and
 :invalid, but with the added constraint that these pseudo-classes only
 match after the user has interacted with the element.


 Blink component Blink>CSS
 

 TAG review None

 TAG review status Not applicable

 Risks


 Interoperability and Compatibility

 There is no interop/compat risks because this is a new feature that
 has already been implemented by safari and firefox and has WPTs.


 *Gecko*: Shipped/Shipping

 *WebKit*: Shipped/Shipping

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 This feature will not be used in tandem with other platform APIs.
 The default usage of this API will not make it hard for chrome to 
 maintain
 good performance.


 Activation

 It will not be challenging for developers to use this feature
 immediately. There is already an MDN article for this feature, so I 
 don't
 think that we need additional outreach.


 Security

 There are no security risks for this feature.


 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


 Deb