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

[Loirooriol]

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]

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]

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]

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

[Loirooriol]

@upsuper There are various resolution in favour of nested pseudo-elements. See #3876 (comment) and #3836 (comment)

[Loirooriol]

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

[khushalsagar]

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

[dbaron]

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 #7469 (comment) if I'm reading it correctly.

[Loirooriol]

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]

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]

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.

[css-meeting-bot]

The CSS Working Group just discussed [cssom] getComputedStyle for ::before::marker or ::after::marker, and agreed to the following:

• RESOLVED: The pseudoElement argument to getComputedStyle takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()

The full IRC log of that discussion

<chrishtr> oriol: this is about nested markers. The spec already allows these syntaxes. If authors are able to style them then they should be able to query the style of them.
<chrishtr> oriol: I proposed generalizing the second argument to getComputedStyle to put multiple pseudo element selectors in this
<chrishtr> oriol: we already resolved this in animations for the ? function that we already resolved, in issue 7469
<chrishtr> oriol: there we resolved that multiple pseudo-elements could be provided. Propose to repeat that pattern here.
<emilio> +1
<kizu> +1
<schenney> +1
<chrishtr> emilio: have you thought through all the corner cases?
<schenney> Also relevant: https://github.com//issues/10297
<chrishtr> florian: this resolution doesn't add any new cases, it's just about querying existing cases
<chrishtr> oriol: for the other web animations issue, if you end up matching multiple things then you take the first one
<chrishtr> oriol: not sure if this was exactly what you were saying about view transitions
<florian> makes sense
<chrishtr> emilio: this is what my memory was, so sounds good
<dbaron> +1 (to the initial proposal here)
<chrishtr> PROPOSED: allow multiple pseudo-elements in the same way as in the web animations spec
<Rossen1> The pseudoElement argument to animate() takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
<chrishtr> PROPOSED: The pseudoElement argument to getComputedStyle takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()
<chrishtr> RESOLVED: The pseudoElement argument to getComputedStyle takes any pseudo-element selector, and selects the first matching pseudo-element like querySelector()