Csswg-drafts: [css-pseudo] ::selection style propagation section doesn't reflect reality in any way.

[emilio]

https://drafts.csswg.org/css-pseudo/#highlight-pseudos currently says in https://drafts.csswg.org/css-pseudo/#highlight-cascade:

Each element draws its own portion of the highlight overlay, which receives the styles specified by the highlight pseudo-element styles for which that element or one of its ancestors is the originating element. When multiple styles conflict, the winning style is the one belonging to the innermost element after cascading.

Note that even the spec example doesn't work as described on current browsers (the highlight background is definitely not green throughout).

What happens at least in WebKit, Blink and Gecko (haven't tested IE / Edge) is that the closest element ancestor's selection style is matched, inheriting from the ancestor style, and nothing else.

This is nice because what the spec specifies is kind of slow, and changing impls right now may be tedious and prone to compat bugs.

Can we update the spec to reflect reality please?

[fantasai]

That depends: do we want p::selection (and p::spelling-error and p::grammar-error) to work as authors would expect, or do we want only unqualified ::selection selectors, which affect the whole document at once, to be usable? In current implementations, the introduction of even an unstyled <span> breaks any form of targeted selection styling. This violates the generally-applied invariant in CSS that an unstyled inline element has no effect on rendering.

(The current spec, btw, is an attempt to reflect these discussions.)

[emilio]

I'm intending to unprefix this in Gecko in https://bugzilla.mozilla.org/show_bug.cgi?id=509958.

I'm happy to wait and change to what the spec says if other vendors commit to changing their long-unprefixed implementation, but lacking that having it prefixed is harming Firefox with a slow stream of web-compatibility bugs from people remembering to use ::-moz-selection in some places but not others.

Also, just tested Edge, and it seems to do the same thing WebKit and Blink do.

[frivoal]

I cannot speak for the WG, but given that other vendors have shipped unprefixed, I would be in favor of Firefox unprefixing it as well.

Separately from that, I think that we should still look into doing what the spec says (or something close), rather than what legacy implementations do, because the legacy approach makes the pseudo useless for anything other than the unqualified ::selection selector.

This definitely does mean that implementations will have to change, but I am not too worried about web compat, given that we'd be making a previously unusable thing usable.

If the discussion with implentors in the WG confirms that we still want to make ::selection more broadly useful, I'll try to help out with tests.

[css-meeting-bot]

The Working Group just discussed :selection style propagation, and agreed to the following resolutions:

• RESOLVED: ::selection is cleared for shipping unprefixed even though multiple impl do not follow the spec.
• RESOLVED: Switch to using inheritance instead of cascade.

The full IRC log of that discussion

<dael> Topic: :selection style propagation

<dbaron> and so does CSS 2.1 https://www.w3.org/TR/CSS21/cascade.html#specificity

<dael> github: https://github.com/w3c/csswg-drafts/issues/2474

<dael> emilio: No one does what spec says. So I think we should change the spec or all impl.

<dael> rune_: This has been a topic for multiple F2F. I think we covered it in 2010.

<dael> rune_: dbaron has best overview.

<dael> dbaron: Selection was spec in selectors 3, but didn't say what it meant. A bunc hof browsers impl something, then we tried to look at what people wanted and expected and I made a list of requirements of what it should do. I think we picked one but no one adjusted.

<dael> rune_: I'm not sure we picked one.

<dael> dbaron: I don't know. Maybe we didn't. Way selection works in most browsers isn't useful.

<dael> florian: I think based on thebackground fantasai spec a thing that makes sense and is useful, but it's not what browsers do today.

<dael> dbaron: Other question is is the thing spec compat with what's on the web today.

<dael> florian: I think underlying is should we try and make it useful. If we establish that's the goal by applying to qualifying selectors we accept we're willing to go into that level of complexity. If we don't accept hte premise let's not bother. Current spec had the assumption that we wanted to bother. Is that true?

<dael> dbaron: The thing in the spec attempts to do useful thing sfor selections and styles. Also there we features we wanted to build on top of ::selection so we can do things like styling spell check region that are on top of this feature.

<dael> fantasai: We added grammar and spell check.

<dael> emilio: Annoying part of how it's spec is you need to start resolving status to the top.

<dael> fantasai: There's different ways of getting same result. THere was an alternative way to have selection inherit from itself in a sep tree.

<dael> emilio: You have to resolve the entire tree which is different then what browsers do. I could say that, but I care about browser compat.

<dael> emilio: Whoever changes the impl first needs to be aware they might break.

<dael> florian: I don't know. It will do it wrong if you try and use it outside :selection

<dael> tantek: I'd rather see data on actual use.

<dael> TabAtkins: Argument is any current usage that would be effected is almost certainly broken.

<dael> tantek: You'd be fine with blink changing ::selector

<dael> TabAtkins: I would be fine with our impl to change, it would be better for users. Only global selection is useful right now and that wouldn't change.

<dael> emilio: Seems like it would make select-all sort of slow. You need to style whole page again.

<tantek> s/::selector/::selection

<dael> TabAtkins: recascade

<dael> emilio: You pay the cost of selecting the whole page.

<dael> fantasai: Don't have to recascade

<dael> TabAtkins: Track a full cascade

<dael> fantasai: ::selection has 4 properties.

<dael> TabAtkins: True.

<dael> emilio: But then special casing that.

<dael> fantasai: Then you just...instead of using cascading you can use inheritence through selection tree.

<dael> rune_: That's what presto used to do.

<dael> emilio: Somewhat like blink and webkit do for visible

<dael> rune_: Works for limited number of property

<dael> fantasai: Has to be limited because non-layout effecting.

<dael> TabAtkins: Most are already inherited. Others can be shifted.

<fantasai> https://drafts.csswg.org/css-pseudo/#highlight-cascade

<dael> fantasai: And I think there's an open issue about describing it to use inheritence.

<dael> fantasai: WE can do it either cascde or inheritance but you get same behavior. Main difference is if you fail.

<dael> fantasai: Most of the time authors are not setting the inherit keyword. Behavior between cascading and inheritance is that the inherit keywod behaves differently

<dael> emilio: Synth prop that are usuallyr eset but are not inherited for purpose of selection...I don't know.

<dael> TabAtkins: Happy to desc like that.

<dael> emilio: Seems hard.

<dael> TabAtkins: Spec text should be fine.

<dael> tantek: first-line has similar issues

<dael> TabAtkins: NOt a great example

<dael> tantek: Older and has more tests

<dael> florian: Less constrained because compat. Can effect layout.

<dael> tantek: If you look at the ::selection and apply them to first-line you can come up with a reasonable list.

<dael> florian: That the set of properties for ::selection is more constrained means you can use more mech.

<dael> tantek: But from user/author it's not clear it should be different then first-line

<dael> fantasai: I think first-line is not related because it's trying to solve different constraints

<dael> TabAtkins: Pretend everything is inherited make sense?

<dael> emilio: Will people change?

<dael> TabAtkins: WE should try.

<tantek> ::selection is only trying to solve a subset of the constraints of ::first-line, which is why it is related and worth looking at

<dael> florian: Is it priority or disagreement? If browsers agree but don't prioritize there are people that have fixing browsers as a bug. If the browsers will accept that behavior that's different then we would not want to do this.

<dael> emilio: If there's no committment to impl.

<dael> florian: I'm saying that there might be and a patch might be written.

<dael> dbaron: Other option is put a note in a spec saying it hasn't been impl and we want feedback to see if it would work out and desc the other thing.

<dael> florian: Other thing being only global is useful?

<dael> dbaron: Yeah.

<dael> fantasai: It's easy to describe current impl. That's easy to desc in 2 sentences and add another for why it doesn't work well.

<dael> fantasai: I'm with TabAtkins we should try and make it more useful and if that's in terms of inhertence that's fine.I'm with TabAtkins that impl correctly is unlikely to break anybody.

<dael> fantasai: I would say if you impl in a way that makes it work no one will be made at Mozilla not doing it right. You have a problem that it's prefixed in your impl. You've got compat on the basic case that works so you should unprefix. Separately then make it useful.

<dael> tantek: Reasonable approach. We heard existing unprefix impl are willing to change so that adds weight to Moz can unprefix assuming we're willing to change.

<dael> fantasai: Prop: Mozilla should unprefix ::selection impl and the spec should describe how ::selection of a child gets its parent's styles via an incoherence based mechanism

<dael> florian: Our process prevents Mozilla from unprefixing and we need to allow.

<dbaron> s/incoherence/inheritance/

<dael> fantasai: WE generally rec you only ship if you're reasonably complient and people are not and we're saying it's okay.

<dael> fantasai: ::selection is cleared for sipping unprefixed even though multiple impl do not follow the spec.

<dael> Rossen: Obj?

<dael> RESOLVED: ::selection is cleared for shipping unprefixed even though multiple impl do not follow the spec.

<dael> fantasai: Currently ::selection of a child is desc with cascade. There are edge cases that will behave different with inherit.

<dael> fantasai: Prop: is switch to describing using the ihenretenace rather then the cascade.

<dael> Rossen: Current resolution is about cleared for shipping so we need the second resolution to change the spec.

<dael> Rossen: Obj?

<dael> RESOLVED: Switch to using inheritance instead of cascade.

[dbates-wk]

I just want to clarify that "RESOLVED: Switch to using inheritance instead of cascade" means that ::selection will inherit from ::first-line (if there is one) such that selecting all of the following text in the page whose markup is:

<style>
#test {
    color: black;
}
#test::first-line {
    color: red;
}
#test::selection {
    background-color: blue;
}
</style>
<p id="test">First line of text.<br>Second line of text.</p>

will render equivalent to the page whose markup is:

<style>
#test {
    color: black;
    background-color: blue;
}
</style>
<p id="test"><span style="color: red">First line of text.</span><br>Second line of text.</p>

?

The first line has red text on a blue background and the second line has black text on a blue background.

[emilio]

@dbates-wk I don't think it necessarily does. The resolution comes to say that selection for a <span> should inherit from the ::selection pseudo of its parent. Maybe accounting for first-line is fine (but what should win, the ::selection pseudo of the block, or the ::first-line?), but that's not quite what the resolution says.

[fantasai]

OK, I've drafted up the changes. Agenda+ to request review, but otherwise I'm closing this issue in favor of follow-up issues for anything that needs further fixing.

[css-meeting-bot]

The CSS Working Group just discussed Switching ::selection to use inheritance rather than cascade for parent-child value propagation, and agreed to the following:

• RESOLVED: Accept the edits here: https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

The full IRC log of that discussion

<dael> Topic: Switching ::selection to use inheritance rather than cascade for parent-child value propagation

<dael> github: https://github.com/w3c/csswg-drafts/issues/2474#issuecomment-380369965

<dael> fantasai: I made the edits we resolved on. Wanted to request review b/c it's a significant re-write.

<florian> I did review, and I like it.

<dael> fantasai: If anyone needs time that's fine. But it would be good to do an update WD at some point

<florian> would like to hear from would be implementors

<dael> astearns: Is this informative to have people come back? Or are you okay with Florian's review?

<dael> fantasai: Either is fine

<dael> astearns: Does anyone want more time to read the changes?

<dael> florian: I want impl to read because what's spec is different then what's impl. but what's impl isn't useful so we want them to switch. Based on a previous read of the previous text that was objected to. but reading it and assuming it's fine wouldn't be good

<dael> astearns: Writing tests is easiest way to get impl to pay attention

<dael> florian: That's somewhere on my to do list

<dael> astearns: Let's get a resolution to accept these changes. Follow up issues should be sep file

<dael> astearns: Obj to accepting the edits here https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

<dael> fantasai: Unless emilio comes back and objects

<dael> astearns: Is he tagged in issue?

<dael> fantasai: I did not

<dael> florian: He opened it

<dael> astearns: Okay

<dael> RESOLVED: Accept the edits here: https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

[fantasai]

@emilio I think we're closed out on this issue, but I wanted to check with you if the edits are acceptable. Lmk?

[emilio]

Yes, the edits look sensible, thanks!

[dbaron]

For what it's worth, the way things worked prior to this issue was I think the result of a discussion of which https://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html was an important part.