[css-pseudo] Highlight pseudo-el cascade rules doesn't match reality

[tabatkins]

All browsers (now?) agree in nearly all details for how to render ::selection (and presumably will apply the same to the other highlight pseudo-els). However, the spec text drastically conflicts with this.

In particular, IE/FF/Blink all:

• have some default UA styles for the highlight

• each element's segment of the highlight is styled according to that element's ::selection rules

• if a given element doesn't style the highlight at all, it uses the UA rules (instead of inheriting them from the originating element or using initial values)

  (Definition of "doesn't style at all" is slightly inconsistent - all agree that an empty style rule for the element doesn't style it, and all agree that a highlight-valid property in the style rule does style it. IE assumes that a property that doesn't apply to the highlight (such as display) doesn't count as styling, while FF and Blink treat it as styled.)

There was some discussion/resolution about this in the past, of which the current spec text is apparently the result, but iirc browsers previously didn't agree as strongly so we believed there was some room to dictate a maximally "useful" result. However, they currently strongly agree (with only very minor differences) on what I described above. We should change the spec to match current browser behavior, which, while not ideal, is serviceable, simple, and mostly consistent with how other pseudo-elements work.

[fantasai]

The current mismatch you're complaining about (that an unstyled ::selection uses the initial styles, not that of its parent ::selection), is not even useful, not just “not ideal”. I'm open to discussing this, but I also think we should consider what would actually be useful to Web authors, not just what's currently implemented.

[tabatkins]

The vast majority of ::selection styling is simple whole-page theming, with a naked ::selection { ... } selector. That sort of usage doesn't care which strategy we use.

So then it's a question of whether making a much less common usage of the feature work somewhat better is worth the significantly increased complexity of a completely novel inheritance algorithm.

[fantasai]

(Added to the TPAC agenda.)

[gregwhitworth]

I disagree with the statement that everything seems the same. Unless I'm missing something here, I think this is a decent testcase to what you're referring to: http://jsbin.com/xamafaxudu/edit?html,css,output

Dragging selection from basic paragraph to psuedo:
Chrome: No styles
Edge: Styles
Firefox: No styles on the paragraph nor the psuedo

Double clicking the psuedo content:
Chrome: No styles
Edge: No styles
Firefox: No styles

Double clicking the paragraph:
Chrome: Styles
Edge: Styles
Firefox: No Styles

Again, I may be missing something here, but at the very least there is a decent amount of interop issues here. I personally prefer the Edge behavior but think that the double clicking should behave the same as a regular box.

[dbaron]

See a post I wrote in 2008 laying out options for fixing ::selection.

[upsuper]

Dragging selection from basic paragraph to psuedo:
Chrome: No styles
Edge: Styles
Firefox: No styles on the paragraph nor the psuedo

Double clicking the psuedo content:
Chrome: No styles
Edge: No styles
Firefox: No styles

So what's happening here is that, Gecko doesn't allow selecting pseudo content consistently, and Blink and Edge allow that in some case but not others.

Double clicking the paragraph:
Chrome: Styles
Edge: Styles
Firefox: No Styles

There are two possible reasons for this:

1. Gecko currently only supports prefixed ::-moz-selection while your testcase only includes ::selection
2. There is probably some bug in Gecko that selection inside <iframe> isn't style correctly. When I pop out the result to whole page, it seems that the selection is styled as expected.

[upsuper]

There is probably some bug in Gecko that selection inside <iframe> isn't style correctly. When I pop out the result to whole page, it seems that the selection is styled as expected.

This seems to be some issue specific to how JS Bin works... it doesn't seem to be a general issue, and I have no idea how it happens at the moment... I've filed a Gecko bug for this.

(You can work around this Gecko bug by inspecting the "results" iframe in devtools and adding & then removing "display:none", so that its frames get recreated.)

[dbaron]

Though actually all 6 links in section 3.3 are probably relevant.

[css-meeting-bot]

The Working Group just discussed selection cascade.

The full IRC log of that discussion

<Rossen> Topic: selection cascade
<Rossen> github: https://github.com//issues/374
<eae> TabAtkins: The original part of the issue: I assumed my testing had proven that there was a simple subset we could agree on. A few weeks ago Greg posted that not to be the case. David recently commented and linked to data dating back many many years.
<eae> TabAtkins: The propable issue is that it's still more complicated than I though it was. We need to figure it out and be consistent.
<eae> fantasai: We looked at this many times in the past. Once was when dbaron posted all options, another time was during psuedo discussion, when we realized we couldn't do it for interop/web compat.
<eae> Rossen: You're saying spec text is not accidental?
<eae> fantasai: Yes
<cyril> s/propable/probable/
<eae> TabAtkins: My memory are hazy but I said something like "all browsers agree on behavior but all disagree with spec". We need to either update spec or change behavior.
<eae> dbaron: When is spec text from?
<eae> TabAtkins: In psedo
<eae> florian: 2-3 years old?
<eae> TabAtkins: More than one year old
<eae> florian: Less than five
<eae> dbaron: 3.3 in psedo spec links to substantially more info that lead to the text.
<eae> TabAtkins: The point is: As far as I can tell no implementing matches the spec. We're trying to do more of these and would be good to have at least the first one match the spec.
<eae> TabAtkins: I need to write good tests for it
<TabAtkins> s/I need/Someone needs/
<TabAtkins> ^_^
<eae> dbaron: Hard part is how the election styles interact with each other across elements.
<tantek> s/election/selection
<eae> dbaron: This is the reason gecko hasn't unprefixed it.
<dbaron> fantasai, sorry for implying that.
<eae> TabAtkins: The only actionable point is "make this all better", my original premise was ruined by youall pointing out I was wrong.

[fantasai]

See also the previous WG discussion on ::selection.