w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.51k stars 671 forks source link

[cssom] getComputedStyle for ::before::marker or ::after::marker #4456

Open Loirooriol opened 5 years ago

Loirooriol commented 5 years ago

From https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle, the signature is

getComputedStyle(elt, pseudoElt)

where pseudoElt is parsed as a <pseudo-element-selector>.

For example, ::before or ::marker are <pseudo-element-selector>s.

However, https://drafts.csswg.org/css-pseudo-4/#marker-pseudo allows ::before::marker and ::after::marker in stylesheets. These are not a single <pseudo-element-selector>, but it seems useful for authors to expose their styles via getComputedStyle.

So maybe we could allow one of these:

getComputedStyle(elt, "::before::marker")
getComputedStyle(elt, "::before", "::marker")
Loirooriol commented 5 years ago

I guess there's also the 3rd possibility of allowing a CSSPseudoElement as the 1st argument, then

getComputedStyle(elt.pseudo("::before"), "::marker")
getComputedStyle(elt.pseudo("::before").pseudo("::marker"))
AmeliaBR commented 5 years ago

Regarding these two options:

getComputedStyle(elt, "::before::marker")
getComputedStyle(elt, "::before", "::marker")

My first concern for the second case is that it is bad for compatibility/progressive enhancement: existing browsers will silently ignore the final parameter & just return the ::before styles, with no way to catch the difference.

However, now that I actually test it, it seems like the results for unrecognized selector strings aren't actually useful for catching the difference, either! See discussion in #3980.

upsuper commented 5 years ago

I'm wondering whether we can just ban nested pseudo-element of this kind from being used as selector as a whole...

Loirooriol commented 5 years ago

@upsuper There are various resolution in favour of nested pseudo-elements. See https://github.com/w3c/csswg-drafts/issues/3876#issuecomment-488482816 and https://github.com/w3c/csswg-drafts/issues/3836#issuecomment-490559213

Loirooriol commented 5 years ago

It would be good if the solutions here and in #4487 were consistent.

khushalsagar commented 2 years ago

Seems like we can follow the footsteps of the resolution above and permit the same syntax for 'pseudoElt' in getComputedStyle?

dbaron commented 3 days ago

I'm in favor of using additional selector syntax in the second argument to getComputedStyle, that is, to allow:

getComputedStyle(elt, "::before::marker")

I think that agrees with the resolution in https://github.com/w3c/csswg-drafts/issues/7469#issuecomment-1190493968 if I'm reading it correctly.

Loirooriol commented 2 days ago

Yes, the wording of the resolution isn't very clear, but from the minutes

when I say any selector I mean anything that targets pseudo-elements, so just ::before::marker-like selectors and ::before>>=::marker

(I understand ::before>>=::marker was supposed to be ::before :>> marker, and is conditionally to fully specifying #7346)

bramus commented 2 days ago

Isn’t the underlying problem that pseudos are not a first class citizen in JavaScript? Ideally it’d be something like getComputedStyle(document.getElementById('elt').getPseudo('before').getPseudo('marker')), no?

Loirooriol commented 1 day ago

I'm not sure if pseudo() is getting any traction... Anyways, allowing getComputedStyle(el, "::before::marker") doesn't prevent accepting a CSSPseudoElement as the 1st argument in the future.