W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

Re: [csswg-drafts] [css-pseudo-4] Specify better handling of text shadows for ::selection (#3605)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 20 Feb 2019 17:57:41 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-465687546-1550685460-sysbot+gh@w3.org>
The CSS Working Group just discussed `Specify better handling of text shadows for ::selection`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Specify better handling of text shadows for ::selection<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3605<br>
&lt;dael> astearns: I see daniel commented. Did you get to read spec daniel?<br>
&lt;dael> daniel: I haven't<br>
&lt;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.<br>
&lt;dael> daniel: Sounds like you don't expect pic I posted?<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;dael> chris: Sounds like 2 models for this. One if it's above or below and another is painting over.<br>
&lt;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<br>
&lt;chris> s/painting over/painting without shadow/<br>
&lt;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?<br>
&lt;dael> fantasai: If we go with AmeliaBR model author could set text-shadow unset?<br>
&lt;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<br>
&lt;chris> +1 to what Amelia said. Set a good default but give authors control<br>
&lt;dael> fantasai: I think in cases users won't think through it. If selection color was navy blue and white<br>
&lt;dael> AmeliaBR: If author has set custom selection and not considered contrast that's author error<br>
&lt;dael> fantasai: Theyd idn't think about the text shadow that's incompat. I think text shadow should be an explicit opt in<br>
&lt;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<br>
&lt;dael> fantasai: I don't think text-shadow:inherit would work b/c inherit from parent selection<br>
&lt;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.<br>
&lt;astearns> also chris: you can't legislate against bad design<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;dael> daniel: I think that's their responcibility to think through. They can do selection pseudo with good properties.<br>
&lt;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<br>
&lt;dael> fantasai: If author wants text shadow to show through selection you can set that<br>
&lt;dael> daniel: I think that's the wrong audience. What does use expect and I think they would expect shadow to stay<br>
&lt;dael> fantasai: I didn't expect it to stay<br>
&lt;dael> daniel: Native OS gets you that result<br>
&lt;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.<br>
&lt;dael> gregwhitworth: Don't know how to strandardize and take that all in in a meaningful way<br>
&lt;chris> authoring advice is a good way forward<br>
&lt;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<br>
&lt;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<br>
&lt;dael> astearns: Not sure default is you should cancel the shadow<br>
&lt;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<br>
&lt;dael> florian: So by default you need to suppress it<br>
&lt;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<br>
&lt;dael> daniel: Could adjust visibility of color. webkit does this for regular foreground text. That's one way<br>
&lt;dael> fantasai: Let's talk about this later, we're not going to resolve today<br>
&lt;dael> astearns: Not much time in the call and not hearing consensus. Let's close for now and come back.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3605#issuecomment-465687546 using your GitHub account
Received on Wednesday, 20 February 2019 17:57:43 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:44 UTC