Intent to Implement :is()

[Victoria Su]

Intent to Implement :is()

Contact Emails

victor...@google.com

Spec

https://drafts.csswg.org/selectors-4/#zero-matches

Design Doc

https://docs.google.com/document/d/1ZUNf4eXIABKYtOb2IWdzkHqMSC9GWgX5740McqQ5ur0/edit?usp=sharing

TAG Review

https://github.com/w3ctag/design-reviews/issues/219

Summary

CSS Selectors 4 will be introducing the specificity-adjustment pseudo-class. The specificity-adjustment pseudo-class is a functional pseudo-class taking a selector list as its argument, and represents each of the elements in this selector list. It has the same syntax and functionality as :matches(), however neither the pseudo-class nor any of its arguments contribute to the specificity of the selector. Currently, the name for this selector is still in discussion, however it will be referred to as :is() in this Intent to Implement, design doc, and initial commits.

Motivation

The motivation for implementing :is() is to introduce style filters to selectors while keeping the associated style declarations easy to override. An example of this can be found in the spec.

Risks

Interoperability and Compatibility

There is some interoperability risk in implementing this feature as no other major browsers (Firefox, Safari, and Edge) support it yet. However, since it is already included in the CSS Selectors 4 specification, other browsers should be likely to also implement it in the future.

The compatibility risk is very low as this feature is very similar to :matches(), which has already been implemented.

Ergonomics

N/A.

Activation

It should not be challenging for developers to use this feature once it is implemented.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Feature dashboard link

https://www.chromestatus.com/feature/4600991135563776

Requesting approval to ship?

No.

[Rick Byers]

/cc spec editors to ensure they're aware of the implementation interest

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5eb3244d-4abe-4967-9538-75d2ce9196be%40chromium.org.

[fantasai]

On 02/05/2018 07:58 AM, Rick Byers wrote:
> /cc spec editors to ensure they're aware of the implementation interest

Thanks! I do recommend just CCing www-style for CSS specs: you'll hit all
the spec editors at once and also other WG members who may have useful
information. :)

Specific comments below

> On Sun, Feb 4, 2018 at 10:40 PM, 'Victoria Su' via blink-dev <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>
> Intent to Implement :is()
>
> Contact Emails

> victor...@google.com <mailto:victor...@google.com>
>
> Spec
> https://drafts.csswg.org/selectors-4/#zero-matches <https://drafts.csswg.org/selectors-4/#zero-matches>

As you may have noticed, this pseudo-class doesn't even have a name yet.
It has been added to the draft only recently -- last month -- and hasn't
received much public review. While I appreciate the enthusiasm, it might
be worth waiting until people have had a chance to comment on the feature.

> TAG Review
> https://github.com/w3ctag/design-reviews/issues/219 <https://github.com/w3ctag/design-reviews/issues/219>

For example, the TAG review is till open, and could result in a redesign
of the feature. See, e.g. Alex Russell's comments.

> Interoperability and Compatibility
>
> There is some interoperability risk in implementing this feature as no other major browsers (Firefox, Safari, and Edge)
> support it yet. However, since it is already included in the CSS Selectors 4 specification, other browsers should be
> likely to also implement it in the future.

It should be worth noting that adding features to a CSS spec doesn't mean
that feature is design-complete. In fact, a feature which was recently
added is typically *not* design-complete as it has not yet had a chance
to receive wide review, which often results in changes.

Overall Selectors 4 is in a relatively stable phase of development, but
there are a few features which are not. This pseudo-class is definitely
one of them. If it retains its current design of being an analog to
:matches(), there should be no problem with it moving forward quickly;
but until we've had a wider range of people review it, I would not be
confident that this is its ultimate design.

The draft will likely be trimmed down to the set of stable features
(those without significant open issues) ~April and sent to CR. At
that point, there will have been 4 months of time for review of this
feature, so we will have more confidence about whether or not it is
stable in its design.

(Any CSS spec in CR is considered stable and ready for implementation;
those not yet in CR require more scrutiny. We're almost, but not quite,
there for Selectors 4.)

> The compatibility risk is very low as this feature is very similar to :matches(), which has already been implemented.

I don't understand why being very similar to :matches() makes the compatibility
risk low. Certainly it makes the implementation effort low, but that's not the
same thing.

~fantasai

[PhistucK]

Note that this is only an intent to implement - it is not meant to be shipped at this point, only to have some interested web developers play around with it (and only when they activate a flag) so the team (as well as you) can gather some feedback from actual experience.

☆PhistucK

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7585a83e-ddf6-183d-78de-682ce8f5e513%40inkedblade.net.

[Ojan Vafai]

Regarding the feature, I agree that specificity is often a problem, but this solution seems to be a fix to only a small part of the problem.

I'd rather see us explore options that opt the page or stylesheet out of specificity entirely. I know Tab had some proposals in this area. For example, being able to just set the specificity to a certain value.

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/7585a83e-ddf6-183d-78de-682ce8f5e513%40inkedblade.net.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[fantasai]

On 02/05/2018 10:56 AM, Ojan Vafai wrote:
> Regarding the feature, I agree that specificity is often a problem, but this solution seems to be a fix to only a small part
> of the problem.
>
> I'd rather see us explore options that opt the page or stylesheet out of specificity entirely. I know Tab had some proposals
> in this area. For example, being able to just set the specificity to a certain value.

The discussion that led to this feature is in
https://github.com/w3c/csswg-drafts/issues/1170

Your comment was raised by Philip Walton in
https://github.com/w3c/csswg-drafts/issues/1170#issuecomment-329878248
and responded to by Lea Verou in
https://github.com/w3c/csswg-drafts/issues/1170#issuecomment-329879780
and
https://github.com/w3c/csswg-drafts/issues/1170#issuecomment-331620760

~fantasai