-
Notifications
You must be signed in to change notification settings - Fork 29
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
Unclear how specificity of ::cue() and ::cue-region() should be calculated #499
Comments
You'll want to check the WebVTT spec: it talks about applying the selectors: https://www.w3.org/TR/webvtt1/#the-cue-pseudo-element and https://www.w3.org/TR/webvtt1/#the-cue-region-pseudo-element |
I can't see any definition for the specificity for There are specificity rules for In example 2 the the specificity decides whether
The difference between the last two becomes clearer if the universal selector is used:
Background: I'm adding support for ::cue() and ::cue-region() to an existing CSS engine. I need to know the specificity of these selectors to do this interoperably. |
The specificity wording for :host() and :host-context() may be a good starting point: |
I would need to spend more time on this, including investigating current implementations, but my current reading and knowledge of the spec seems like the intent was to have You are correct that the spec doesn't currently make this explicit, and it would be something that should be updated in the spec. |
It wasn't added to the spec as the expectation was that the CSS
specification provides for that kind of specificity, so they was no need to
duplicate.
…On Fri, Oct 29, 2021, 6:56 AM Gary Katsevman ***@***.***> wrote:
I would need to spend more time on this, including investigating current
implementations, but my current reading and knowledge of the spec seems
like the intent was to have ::cue and ::cue() behave in a similar way to
:host(). So, ::cue would have the specificity of a pseudo-element and
::cue() would have a specificity of a pseudo-element plus the specificity
of the argument given.
You are correct that the spec doesn't currently make this explicit, and it
would be something that should be updated in the spec.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#499 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAXFQL4RPX3OUEXLFXUEGTUJGTILANCNFSM5GDT3BTQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Should the selectors passed as an argument be taken into consideration or ignored when calculating specificity?
Looking at 'Calculating a selector’s specificity' in selectors-4 doesn't make things clear since pseudo classes that take selectors as parameters are special-cased:
https://drafts.csswg.org/selectors/#specificity-rules
The text was updated successfully, but these errors were encountered: