[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.