[css-pseudo-4] Clarify ::selection background-color in presence of fill/stroke

[fantasai]

We currently have a rule (which exists due to compat reasons) that if the author sets either background-color or color on ::selection, then the UA's rules for both background-color and color get dropped. So, for example, if the author sets color, then background-color becomes transparent.

What about if the author sets fill or stroke? Should they also make the background-color become transparent, or should the selection continue to use the OS default selection background color?

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] Clarify ::selection background-color in presence of fill/stroke.

The full IRC log of that discussion

<dael> Topic: [css-pseudo-4] Clarify ::selection background-color in presence of fill/stroke
<fantasai> s/mean/include/
<dael> github: https://github.com//issues/4720
<dael> fantasai: I don't have proposed change, it's a question. Special rule that says if either color or bg color is set on selection then UA default colors for both are not used and we use initial value for not set property
<dael> fantasai: What if author sets fill or stroke, should that remove the UA default color and bg color or is that part of properties that nulls UA rule or applied in addition to UA rule?
<dael> dbaron: We have that behavior in the first place?
<dael> dbaron: We remove the UA rules?
<dael> fantasai: Yes and I'm pretty sure that's required for web compat. Haven't tested, but impl in all browsers that way
<dbaron> s/We have/Why do we have/
<dael> tantek: Don't know how to evaluate w/o tests
<dael> fantasai: No one impl fill or stroke right now
<dael> tantek: Test for existing behavior so we can understand effect and what desired/undesired would be
<dael> fantasai: Will make test case
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%3A%3Aselection%20%7B%20color%3A%20blue%3B%20%7D%0A%3C%2Fstyle%3E%0A%0A%3Cp%3ETest%20%3Cspan%3Ethis%3C%2Fspan%3E
<emilio> q+
<fantasai> testcase ^
<fantasai> demonstrates that setting 'color' removes background-color
<dael> dbaron: Seems like this behavior is kind of silly and removes possibility of using one of the colors. Maybe not silly. What's trade off between preventing things authors would like to do but can't so with this rule vs the fact that spec one color but not the other will break when defaults aren't expected
<dael> florian: More that case
<dael> Rossen_: Clarifying question- if what you're prop is adopted if I set a stroke or fill are you suggesting selection bg will be discontinuous?
<emilio> fantasai: I'm pretty sure browser behavior is _any_ property removes background-color
<dael> fantasai: Transparent, yes
<dael> Rossen_: That on its own is questionable
<dael> florian: If you set stroke and color and bg you get intended. If only set stroke you expect the rest to be set to something
<fantasai> emilio, yes, but I don't think that's a web-compat requirement, and I think it's reasonable that e.g. adding text-decoration doesn't remove colors
<Rossen_> ack emilio
<AmeliaBR> q+
<dael> emilio: I'm pretty sure browser behavior is as soon as have a selection pseudo element then you apply ua colors. You put anything in and browser surpresses default colors
<dael> fantasai: I don't think that's good
<dael> emilio: But it's current. Agree not great. May not be great
<dael> Megan: Do we know why this is there in the first place?
<AmeliaBR> Test case for SVG: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7755
<dael> emilio: Once you get to rendering you only have computed style. Gecko can in theory do it, but it's easier saying does speudo match any rule vs saying did the author specifically set this color which could be same as UA color
<Rossen_> What about the use case for https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-stroke
<dael> AmeliaBR: There was statement earlier that we can't test browser b/c they don't impl fill and stroke. Not true with SVG. We have existing use. Made a quick test. In Chrome if you set a fill color in a selection for svg text it doesn't draw default selection bg. Have to look at other browsers to see if concistent
<dael> florian: True in FF
<dael> ??: Have looked in safari
<dael> AmeliaBR: If we want to keep it's another question. In SVG have no way for author to define bg color for selection. Don't have a property that's span bg color.
<dael> AmeliaBR: Either way selection styling is limited in SVG. It's something to think of.
<dael> smfr: These examples show what emilio stated. UA Assumes author knows what they're doing and provides style to make selection look okay.
<dael> florian: We can keep spec as is and increase scope. Or we say if you have a selection pseudo things change
<dael> emilio: I'm pretty sure it's consistent behavior except blink and wk don't handle empty decoration blocks.
<dael> florian: Empty b/c syntax or just empty
<dael> emilio: Just empty. Discared with unknown property. If declaration top line is 0. I think it's styling optimization doing unexpected
<dael> florian: If it discards unknown syntax that's annoying
<dael> emilio: I think that's a bug.
<dael> Rossen_: Impl issues aside. I think a guiding principle should be whatever behavior we land on can'tbreak user expected behavior of visual selection
<dael> Rossen_: I think one of the challenges is if I accidentally create an empty selector I'm breaking the user expected behavior. That sounds like a counter-argument to have the behavior currently proposed.
<dael> Rossen_: From there if this is obviously not hte case main question is how smart should this rule behave and how are these interdependant prop supposed to behave. One is put it in the hands of the author and trust or provide safe defaults in browser to guar. expected behavior. That's the top level fork
<emilio> q+
<emilio> ack fantasai
<dael> fantasai: For as long as selection only accepted bg color and color it made sense if you choose one or the other you drop UA selection color b/c it could be any random color and you want to know the contrast. That does have utility in that author can't assume and if they set color can't predict bg color
<dael> fantasai: As we extend selection to allow for more properties should I add a txt decoration in that rule some browser it will have effect and in some it won't b/c not impl. but it will blow out existing color so browser w/o support will have no indiaction of what's happening.
<dael> fantasai: That's bad for the user and we don't get benefit from dropping colors when adding text decoration
<AmeliaBR> What fantasai is describing is exactly what happens with my SVG test in Firefox: you don't get the author-specified selection fill color, but you also don't get the browser default selection styles.
<dael> fantasai: From PoV that we're adding more properties any property blowing out the colors is a problem for transition esp as transition could be continuous as we add more properties. Indefinite period of transition and any property will blow out color in browsers that don't support it.
<dael> fantasai: Would be best for us to not have any property blow out all the colors behavior. I don't think it's good. Given current behavior and contrast concerns having that behavior for bg color and color we can't and shouldn't change.
<dael> fantasai: filla nd stroke have same contrast concerns so should fall in same bucket. If you set any of those 4 you drop, any other property does not
<florian> +1
<dael> emilio: I kinda agree with Rossen_ that current is sometimes undecided. These 4 properties disable and rest do not seems weird to me. Can we add a note to spec say UA should ensure selection has visible effect?
<dael> emilio: Not sure. 4 properties that disable not sure it's the best. Maybe it is.
<dael> fantasai: There's 2 reason why bg color and color reset should be kept. One is that if author sets bg color they make assumptions about text color of selection and that might be incorrect on another platform. If you're not testing all platforms you can get bad contrast
<dael> fantasai: Second is this is current behavior so if people are setting it's w/ bg color and color. not sure if anyone is depending on not setting these. If they are might be depending on fact that setting bg color cuases reset
<dael> emilio: Setting bg color should retain inherited color. not sure that contridicts my prop to ensure there's enough contrast. I think some UA restrict transparency.
<dael> emilio: I agree we can't break that case of just changing bg
<dael> plinss: Opportunity to instead of magic where one property blows out another can we have a value UA can set that has that behavior?
<dael> plinss: That way UA can set magic value for color and bg color and then setting values acts normally.
<dael> AmeliaBR: Logic would be UA says color selection styles, bg color styles, but rule is you only use them if both values compute to the keyword and otherwise go back to inherit. Is that what?
<dael> plinss: Something like that. not exact mechanics. I want not having magic behavior, just magic in value of property
<dael> florian: Have similar in text decor. Value of text-decoration-line that's supposed to be used on ::spelling-error has a value of spelling-error.
<AmeliaBR> s/ color selection styles, bg color styles/ `color: selection-style; background-color: selection-style`
<dael> plinss: The UA stylesheet says selection color something like selection color. Behavior is normal as far as web property is defined. Make sense?
<dael> fantasai: Yes
<dael> Rossen_: Should we put this back to issue and work out details later?
<dael> Rossen_: Once proposed magic is baked enough we bring it back for resolution?
<dael> fantasai: I thinkt hat works. I'll try and draft plinss suggestion as AmeliaBR desc and see if that's acceptable
<dael> Rossen_: Sounds great. Adding guiding principles of expected behavior would be good.
<Rossen_> Hold on - calling back
<dael> [agenda wrangling]

See official minutes

[delan]

This is an interesting issue, and it has some overlap with #6386 (see also @fantasai’s comment).

I think the fact that paired defaults help authors avoid contrast hazards is a nice consequence, but not a good enough reason to extend this behaviour (or for impls to have created it in the first place). Mixing author colors with system colors is always hazardous. Sometimes the hazards are so pervasive in the wild that we need technical mitigations, but I’m not sure that’s the case for highlight ‘fill’ and ‘stroke’.