[css-pseudo-4] Specify better handling of text shadows for ::selection

[fantasai]

There's an issue in the spec:

What should happen with text shadows? Drawing them in their original color is disconcerting if that color is not a shade of gray. Maybe if the overlay has a background, suppress any text shadows below it?

I'm still of the opinion that the suggested behavior is the best behavior, would like to hear back if it's OK to spec.

[dbates-wk]

I don't have a moment right now (02/13) to ponder this. So, I will need to get back to you. Here's a tidbit for now. WebKit supports specifying a text-shadow for ::selection today though repaint rects likely don't account for it. So, messed up repainting. Here's where WebKit gather's the CSS text shadow for ::selection as part of painting: https://trac.webkit.org/browser/trunk/Source/WebCore/rendering/TextPaintStyle.cpp?rev=240887#L152

[dbates-wk]

A picture is worth a thousand words. Picture please? Didn't open the spec., to find your quote (yet), are we talking about the originating element's style has a text-shadow? If so, it seems to match my intuition (and Apple's Pages - see below) that ::selection paints on-top of the originating element's style (or whatever the top-most styling is for the element).

[dbates-wk]

Or are we talking about ::selection having a text-shadow? Maybe I should read the spec. :/

[css-meeting-bot]

The CSS Working Group just discussed Specify better handling of text shadows for ::selection.

The full IRC log of that discussion

<dael> Topic: Specify better handling of text shadows for ::selection
<dael> github: https://github.com//issues/3605
<dael> astearns: I see daniel commented. Did you get to read spec daniel?
<dael> daniel: I haven't
<dael> fantasai: When we highlight text the problem is if you have a shadow behind. In general I would expect highlight to obscure shadow. In tess I've seen highlighting lets you see text badly styled.
<dael> daniel: Sounds like you don't expect pic I posted?
<dael> fantasai: The color of text and background of highligh are defined by selection. If we keep color of text from selection but take shadow from author we might not get enough contrast between text and shadow behind.
<dael> fantasai: Whereas if we obscure the text shadow then you can ensure there is enough contrast b/c you have chosen both text and background color
<dael> AmeliaBR: A little confused about drawing over text shadow. It's not like text decoration where it's contibuous from parent. text shadow is inheriting. It's not about drawing over, it's were' drawing within selection and that's part of character style
<dael> chris: Sounds like 2 models for this. One if it's above or below and another is painting over.
<dael> fantasai: That's fair. Maybe way to deal is UA default sheet should have text-shadow:none and that turns it off in selection
<chris> s/painting over/painting without shadow/
<dael> daniel: I like effect in picture. That would be example of if someone wanted to do word processing that's what I'd expect as a user. Any way we can let a webdev get that?
<dael> fantasai: If we go with AmeliaBR model author could set text-shadow unset?
<dael> AmeliaBR: But what if you want it preserved in selection. Maybe in the default selection styles could include turning off text shadow. But if user sets selection styles we shoudln't unset an inherited style
<chris> +1 to what Amelia said. Set a good default but give authors control
<dael> fantasai: I think in cases users won't think through it. If selection color was navy blue and white
<dael> AmeliaBR: If author has set custom selection and not considered contrast that's author error
<dael> fantasai: Theyd idn't think about the text shadow that's incompat. I think text shadow should be an explicit opt in
<dael> AmeliaBR: As an author I would not want browser to mess thigns up so I have to explicitly say text-shadow:inherit on my selection
<dael> fantasai: I don't think text-shadow:inherit would work b/c inherit from parent selection
<dael> chris: Better to let author do what they want. Fine to have a default, but argument for not having contrast is same for setting foreground and background color.
<astearns> also chris: you can't legislate against bad design
<dael> fantasai: I think it's a question is where styles come from and do authors except them to combine. You as author should set background and foreground readable and text shadow in conjunction with that. Seems unlikely you'll style a psace and have headers with white text on black shadow and somewhere else in stylesheet you have hot pink as selection color with black text
<dael> fantasai: Then in that section you have black text on a black shadow with a hot pink background. It's hard to read. You were thinking about making sure you had enough contrast, but where you set text shadow it takes effect
<dael> AmeliaBR: I want to point out one of the things I use text-shadow for is to create contrast. If I've intentionally added something to create contrast and you wipe it for selection that could be counterintuitive. Unless I have easy way to say inherit that i's confusing
<dael> fantasai: But that is cause of creating context, but when have selection you have different background and text color and shadow will no longer give you contrast. It should be exactly wrong color
<dael> daniel: Seems to alternate between 2 audiences. One is web dev and stylesheet and other is person on computer who has own stylesheet. I think there's 2 answers. If this is for the website it's the website author's problem. I can see your argument makes sense for a human who has their own stylesheet
<dael> fantasai: I'm worried about author picks good colors in all cases but when you use selection color with the shadow that was for the heading you end up with a combo of the same color becaue selection wasn't thinking about heading having shadow
<dael> daniel: I think that's their responcibility to think through. They can do selection pseudo with good properties.
<dael> daniel: solution: if you take the selection, paint the background and then blend shadow when you paint so that it preserves contrast. NOt exactly what author wants but we're correcting. Could be crazy solution
<dael> fantasai: If author wants text shadow to show through selection you can set that
<dael> daniel: I think that's the wrong audience. What does use expect and I think they would expect shadow to stay
<dael> fantasai: I didn't expect it to stay
<dael> daniel: Native OS gets you that result
<dael> gregwhitworth: We are doing a lot of user studies in similar scenario. WE had to come to same conclusion that ultimately that's what selection pseudo is for and author needs to think through. WE have to give capability for authors to override so they can still do stupid things. I don't know what to standardize but would instead leave it to UAs. This comes down to user preference and in our studies people wanted it all ways and authors too.
<dael> gregwhitworth: Don't know how to strandardize and take that all in in a meaningful way
<chris> authoring advice is a good way forward
<dael> astearns: Maybe we change from what should happen in the spec to an authoring note telling authors they should consider this but not put normative requirements on UA
<dael> florian: seems like a lot of work for authors. Every time you have selection you should turn off text shadow before you think about it so you get right contrast. Defualt is you have to cancel the shadow and please think about it
<dael> astearns: Not sure default is you should cancel the shadow
<dael> florian: If you set selection you set foreground and background color. If shadow comesfrom whereever it could be whatever color and you don't know contrast is good
<dael> florian: So by default you need to suppress it
<dael> fantasai: No one is going to think to reset shadow when setting selection. you're not using shadows everywhere. I think we should be biased toward good contrast
<dael> daniel: Could adjust visibility of color. webkit does this for regular foreground text. That's one way
<dael> fantasai: Let's talk about this later, we're not going to resolve today
<dael> astearns: Not much time in the call and not hearing consensus. Let's close for now and come back.

[css-meeting-bot]

The CSS Working Group just discussed Specify better handling of text shadows for ::selection, and agreed to the following:

• RESOLVED: text-shadow:none in UA style sheets are override-able by authors for selection

The full IRC log of that discussion

<dael> Topic: Specify better handling of text shadows for ::selection
<dael> github: https://github.com//issues/3605
<dael> Rossen_: Discussed once and the discussion was cut short. Who wants to resume that discussion and catch up the group?
<dael> fantasai: The question was really the text shadows spec on an element and highlight element w/ bg should text shadows show through
<dael> Rossen_: On element or on text?
<dael> fantasai: On text.
<dael> fantasai: Shadow is set on the element on DOM and you have highlighted that element. Are you seeing the shadow or not? THe highlight has a bg and generally paint text over bg but that menas text might not visible b/c have changed both text and bg color and there's no assurance shadow color is appropritate to preserve contrast
<dael> fantasai: Highlight colors come from elsewhere then dom element. I think it makes most sense to suppress text shadow unless author explicitly says what it should be
<dael> florian: If an author explicitly considers shadows so they'll set it to the right thing. Most of the time they won't think about it and inherit and it prob will be wrong. I agree
<dael> AmeliaBR: Complication I brought up last time is that there's no easy way to just say use whatever text shadow is on surrounding b/c weirdness of how selection inherits. Not jsut suppressing by default, but taking away option for author to say keep text shadw as is
<dael> florian: Could do custom properties but that's a bit of a cludge
<dael> AmeliaBR: In contrast if we leave it as is which is keep drawing text shadow it's easy for author to override with text shadow:none
<dael> fantasai: But most won't
<dael> florian: Robust by default is important
<dael> fantasai: I think cases where author will want text shadows and showing when highlighting will be less common then when author sets text shadow and not highlight or setting highlight colors and not thinking about it when setting shadows
<dael> AmeliaBR: That's true. I think as far as weither text shadow looks good or bad is 50/50
<dael> fantasai: Not good or bad, this is about readable. This is a11y
<dael> AmeliaBR: Reasonable to say default selection remove text shadows. Not reasonable to override user set selection styles. But if others disagree I've made my statement and won't object
<dael> nigel: Makes sense. If have default selection color for bg and fg they apply and all the defaults make it readable that's fine. If someone overrides text shadow for selection they should look out. Other is if they override text shadow for selections we try and push a color change, but that's a pain to try and do to only modify the color if it's overwritten
<dael> fantasai: I want to keep this not crazy complicated. WE should try and use cascade as much as possible
<nigel> +1 to not crazy complicated!
<dael> fantasai: Prob simpliest is add a text-shadow:none to UA default style sheet. If you want more complicated we can consider
<dael> AmeliaBR: Do have some complications since default UA sets bg and fg but if author sets either, neither value applies. Set text shadow in same group where if author sets any we ignore whole set of UA rules
<bradk> +1 to just being in UA stylesheet. Allowing footguns is better than being author-nanny.
<dael> fantasai: Could do that. Additional weirdness. Not concernedwith jsut UA but that author that sets selection is not the one that puts text shadow on this specific heading. They just want the header to look good on the page when it loads but not in this case. Will be difficult if want text shadow to show up in selection but not impossible. We should bias toward readable page
<dael> AmeliaBR: Sure. As you say selections are about a11y not fancy styling
<dael> AmeliaBR: So you are saying UA style sheet would have text-shadow:none but if author sets it in their selection styles that's fine?
<dael> fantasai: Yes
<dael> AmeliaBR: Okay
<dael> Rossen_: Nearing consensus. Any other feedback on this or is everyone getting around the same page. text-shadow:none in UA style sheets are overridable by authors for selection
<dael> Rossen_: Objections?
<dael> RESOLVED: text-shadow:none in UA style sheets are override-able by authors for selection