Csswg-drafts: [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 https://github.com/w3c/csswg-drafts/issues/3876#issuecomment-488482816 and https://github.com/w3c/csswg-drafts/issues/3836#issuecomment-490559213

[Loirooriol]

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