[cssom-1][css-pseudo-4] getComputedStyle and pseudo-elements with pseudo-classes or sub-pseudo-elements

[delan]

getComputedStyle currently takes an optional <pseudo-element-selector>, and for highlight pseudos like ::search-text (#3812), it returns the styles that would apply to the element if that highlight is the only one active.

But pseudo-elements can have their own pseudo-classes, such as ::search-text:current (#10212) or ::first-line:hover, or even their own sub-pseudo-elements, such as ::before::marker. Note that while an element’s ::first-line is either :hover or :not(hover), both the :current and :not(current) styles can apply to different parts of an element’s ::search-text at once.

1. Should getComputedStyle(x, "::search-text") return the :current styles or the :not(:current) styles? We propose :not(:current), and specifying this behaviour for ::search-text in css-pseudo #getComputedStyle.

2. Given that getComputedStyle(x) returns the :hover styles when x is being hovered, should getComputedStyle(x, "::first-line") return the ::first-line:hover styles when the first line is being hovered? My current belief is that it should, and that in general, getComputedStyle should take pseudo-classes of the given pseudoElt into account. Note that ::first-line:hover rules are not yet supported by major impls (demo).

3. Can we give authors a way to get the ::search-text:current styles? My current belief is that we should change pseudoElt from “<pseudo-element-selector>” to “<pseudo-compound-selector>”, but I’m not yet sure how we would update the algorithm in a way that satisfies both my beliefs in question 2 and question 3.

4. Can we give authors a way to get the ::before::marker styles? My current belief is that we should change pseudoElt to “<pseudo-element-selector>+” or “<pseudo-compound-selector>+”, depending on the outcome of question 3.

I may experiment with questions 2 through 4 in Chromium to see what’s feasible, before putting this on the agenda.

[jihyerish]

I've also investigated this issue, and here is my opinion:

1. Should getComputedStyle(x, "::search-text") return the :current styles or the :not(:current) styles? We propose :not(:current), and specifying this behaviour for ::search-text in css-pseudo #getComputedStyle.

I agree with this because we need to stick to the current behavior of getComputedStyle() for highlight pseudo-element.
It returns styles as if that highlight is active and all other highlights are inactive.

2. Given that getComputedStyle(x) returns the :hover styles when x is being hovered, should getComputedStyle(x, "::first-line") return the ::first-line:hover styles when the first line is being hovered? My current belief is that it should, and that in general, getComputedStyle should take pseudo-classes of the given pseudoElt into account. Note that ::first-line:hover rules are not yet supported by major impls (demo).

I agree with this.
In addition, I found a request to support this feature from WICG.

3. Can we give authors a way to get the ::search-text:current styles? My current belief is that we should change pseudoElt from <pseudo-element-selector> to <pseudo-compound-selector>, but I’m not yet sure how we would update the algorithm in a way that satisfies both my beliefs in question 2 and question 3.
4. Can we give authors a way to get the ::before::marker styles? My current belief is that we should change pseudoElt to <pseudo-element-selector>+ or <pseudo-compound-selector>+, depending on the outcome of question 3.

I also think that changing pseudoElt from <pseudo-element-selector> to <pseudo-compound-selector> for getComputedStyle(elt, pseudoElt) is reasonable way to approach.

I also think :target::target-text may be similar to ::search-text:current in terms of how it works with getComputedStyle().
It seems getComputedStyle(x, ":target::target-text") returns null in this case now.
Here is the demo related to this.

[delan]

See also #4456, which is about nested pseudo-elements in getComputedStyle.

[schenney-chromium]

This issue is resolved by the same resolution as #4456

Good for everyone?

[css-meeting-bot]

The CSS Working Group just discussed [cssom-1][css-pseudo-4] getComputedStyle and pseudo-elements with pseudo-classes or sub-pseudo-elements, and agreed to the following:

• RESOLVED: add bramus as co-editor to CSS Scroll Animations

The full IRC log of that discussion

<kbabbitt> schenney: observation is that with gCS you can gCS an element and an optional pseudo class string
<kbabbitt> ... currently speced as being a single pseudo class string
<kbabbitt> ... given other issues we just talked about, potential of having first-line hover etc.
<kbabbitt> ... no way to gCS on multiple chained pseudos
<emilio> q+
<kbabbitt> ... would be a change to behavior of gCS to enable
<oriol> q+
<kbabbitt> ... proposal I agree with is to change 2nd argument from single pseudo selector string to become pseudo element compound selector
<lea> q?
<kbabbitt> ... propose we extend gCS to instead of single string with one pseudo, list of pseudos
<astearns> ack dbaron
<kbabbitt> dbaron: both pseudo element and pseudo class in there
<kbabbitt> ... need to be careful to distinguish
<kbabbitt> ... right now gCS argument is just pseudo element
<kbabbitt> ... gives style given what pseudo class is applied
<kbabbitt> ... providing a way to change that is a bigger discussion
<kbabbitt> ... second piece: I think we discussed this for some other use case
<bramus> https://github.com//issues/4456 was the issue
<kbabbitt> ... I think we have a resolution to allow multiple pseudo elements in that string
<TabAtkins> Yeah, `<pseudo-compound-selector>+` would be the grammar term to use
<kbabbitt> schenney: I did not follow up on that, I think we should table this
<lea> q+
<kbabbitt> s/that/issue 4456/
<oriol> q-
<kbabbitt> ... we should look at this more before we bring it back
<kbabbitt> ... oh wait, I said we should use the resolution for 4456
<astearns> ack emilio
<kbabbitt> emilio: what dbaron said
<kbabbitt> ... I don't think we should accept pseudo classes
<kbabbitt> ... for some specific cases it might be useful
<kbabbitt> .. doesn't match what happens for elements
<bramus> q+
<kbabbitt> ... element would give style with pseudoclasses applied at the time
<kbabbitt> ... could be use cases to request with a given pseudo class
<kbabbitt> ... but I don't think we want to expand that only for pseudo elements
<kbabbitt> astearns: if we use 4456 resolution it's only talking about pseudo classes
<astearns> ack lea
<emilio> s/classes/elements
<kbabbitt> emilio: think we should not mess with pseudo classes here
<TabAtkins> then we need to make the grammar a little more restrictive, that's fine
<dbaron> s/astearns/emilio/
<kbabbitt> lea: basically allowing chained pseudoe elements seems reasonable which not
<kbabbitt> s/which/why/
<kbabbitt> ... hoping we can limit number of times this is needed in the language in general
<kbabbitt> ... agree with dbaron about pseudo classes
<kbabbitt> ... time to turn that argument into dicutionary perhaps
<kbabbitt> ... much larger scoped change than what's discussed here
<kbabbitt> ... seems like a useful addition that should be discussed separately
<astearns> ack bramus
<emilio> ack bramus
<fantasai> +!
<fantasai> +1
<kbabbitt> bramus: hijacking thread ... pseudo elements are not first class citizens in DOm
<kbabbitt> ... filed aqn issue for that
<kbabbitt> ...11559\
<kbabbitt> ...something to think about
<kbabbitt> astearns: for this issue, we can just apply resolution from 4456 and reuse mechanism from there?
<kbabbitt> schenney: I think it's close no change needed
<emilio> https://github.com//issues/11559 fwiw
<kbabbitt> astearns: might be good to have example in spec
<kbabbitt> schenney: will add example to spec so we can explain
<dbaron> I think the key distinction between pseudo-elements and pseudo-classes here is that pseudo-elements are about finding a different object, whereas providing a pseudo-class you're asking the entirely different question of "what would the style for *this* object be if we changed pseudo-class state in this way")
<kbabbitt> fantasai: propose adding bramus as co-editor to CSS Scroll Animations
<kbabbitt> ... he has contributed very heavily
<kbabbitt> ... very much on design side, coming at it from a different perspective by providing examples
<kbabbitt> ... he put in as much effort in design as editors have
<fantasai> s/examples/demos and use cases/
<kbabbitt> bramus: I would be happy to, thank you for acknowledging
<kbabbitt> RESOLVED: add bramus as co-editor to CSS Scroll Animations