-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pseudo-class after ::part()
#255
base: gh-pages
Are you sure you want to change the base?
Conversation
e.g. `::part():hover`. Blink CL: https://chromium-review.googlesource.com/c/chromium/src/+/5811889
'::part(mypart):buffering', | ||
'::part(mypart):stalled', | ||
'::part(mypart):muted', | ||
'::part(mypart):volume-locked', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dbaron I noticed that these are not currently added to the tests in Blink Cl, are these valid?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's in the spec for the selectors:
https://drafts.csswg.org/selectors-4/#sound-state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I interpret them, :seeking
, :buffering
, :stalled
, :muted
, and :volume-locked
fulfill the criteria for being placed after ::part()
, as they match <audio>
and <video>
elements based on their local element information. (And David at least already added :paused
and :playing
.)
:current
(and its functional notation), :future
, and :past
on the other side, not, because they are structural pseudo-classes, i.e. they match an element based on another element.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:future, and :past on the other side, not, because they are structural pseudo-classes, i.e. they match an element based on another element.
Can you go here and make a comment? w3c/csswg-drafts#10787
@LeaVerou PTAL |
I am not sure if we should test all of the pseudo-classes. Normally the tests only cover a few combinations. Though I don't have a strong opinion on that. Regarding Sebastian |
Created #257 for that. Sebastian |
What pseudo-classes are supported by I think I don't know anything about |
'::part(mypart):muted', | ||
'::part(mypart):volume-locked', | ||
|
||
// TODO: add pseudo-elements after ::part() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion either. Given that not all pseudo-classes are allowed though, maybe testing all that should be allowed makes sense. |
Let's merge this PR. |
e.g.
::part():hover
.Blink CL: https://chromium-review.googlesource.com/c/chromium/src/+/5811889