- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2023 23:28:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Safari’s ::selection “wash” and UA tweaks to highlight colors`, and agreed to the following: * `RESOLVED: If there is color in the author origin the UA must respect that color` * `RESOLVED: If there isn't a color from the author origin the UA may apply magic` <details><summary>The full IRC log of that discussion</summary> <dael> fantasai: The problem here is that certain UAs make tweaks to highlight color spec by author such as making semi-transparent. That means rendering differs across UAs. I believe FF is only one using colors given as is. This can create contrast problems b/c author can use a color that is fine when semi-transparent but unreadable when opaque<br> <dael> fantasai: There was a bug report on this with white text and white brackground<br> <dael> fantasai: Either we decide we're adding alpha channel magic and use the same magic or we should agree to use colors as specified<br> <Rossen_> q?<br> <dael> fantasai: I don't want every UA to do whatever and they end up unreadable<br> <dael> florian: Desire to match platform is understandable but leads to this where authors use something not interpretable<br> <dael> Rossen_: Yeah, this is a problem when unreadable<br> <dael> fantasai: Default it's fine to do whatever but we need to agree on how the colors are used<br> <florian> s/not interpretable/not interpretable, and thereby unreadable in some casees/<br> <fantasai> s/white background/white background. Looked great on Safari, was completely unreadable in Firefox./<br> <dael> Rossen_: Anyone have an opinion on if we want to add alpha channel magic or agree on the specific colors? Which path forward?<br> <GameMaker> q+<br> <dael> florian: I suspect what fantasai hinted at which is once color is spec use that it's the easiest path forward. Havign to spec magic I'm not sure if it's doable. Matching native isn't something we can set in stone. Do native magic by default but when a color is set do that<br> <dael> Rossen_: I agree that it would be an uphill battle<br> <dael> GameMaker: Can someone explain the demo page? I see a slider that changes color but I'm not sure what this is trying to show<br> <dael> iank_: If you slide all the way to the right on Safari you'll see the magic alpha applied on Safari<br> <dael> GameMaker: That makes sense<br> <dael> GameMaker: In general against trying to codify this. We work with hi and it might change in 10 years. Letting UAs do what they want when there isn't a color that's great. But when author says I want this color I think we can get behind that<br> <Rossen_> ack GameMaker<br> <dael> Rossen_: Magic described will match the current magic giving the alpha in the last stop on Safari?<br> <heycam> q+<br> <dael> Rossen_: The demo page which in Safari adds an alpha channel in the last stop when it's opaque. My question is if we allow for other browsers to match that magic is that the effect we want?<br> <GameMaker> q+<br> <dael> iank_: Proposal is the opposite<br> <dael> florian: Opposite b/c in the demo author has spec the color. If the author hadn't all browsers could do whatever magic they want<br> <Rossen_> ack heycam<br> <dael> heycam: I think there's a question of exact mech to determine author has given a color. What's the value of the selection color going to be by default. A system color keyword?<br> <dael> fantasai: Either system color or not specified other than an internal keyword. I think system colors is most straightforward<br> <dael> heycam: Author can't read because getComputedStyle?<br> <dael> fantasai: There's a compat vs security discussion on there<br> <dael> florian: Worried about round tripping?<br> <iank_> how do you access the ::selection getComputedStyle ?<br> <dael> heycam: More about the exact way ofdetermining the author wrote a color<br> <Rossen_> s/getComputedStyle?/getComputedStyle::selection/<br> <dael> florian: As long as it's written you don't have a preference?<br> <dael> heycam: I prefer value of property rather than result of cascade. Seeing if there's a rule with a color property<br> <Rossen_> ack GameMaker<br> <dael> GameMaker: Sounded like we might lean toward defining this and I would say we don't want to define special magic<br> <dael> florian: Not looking for special magic, but looking for when it does and does not apply<br> <dael> GameMaker: Sounds like on same page<br> <dael> Rossen_: Let's look for resolution<br> <dael> fantasai: Here's what's tricky. Spec says each system color computes to corres. color in color space. So at computed time we don't know it's a system color<br> <dael> florian: We would need to do what heycam doesn't prefer<br> <dael> heycam: Do we have other examples of looking at cascade to determine if something was spec?<br> <dael> iank_: Maybe highlight?<br> <dael> florian: I think there's logic around bg and fg. Can we use same logic around having set things?<br> <fantasai> https://drafts.csswg.org/css-pseudo-4/#paired-defaults<br> <dael> florian: I think 2 part resolution. Part 1: When the author has not specified a color the UA may do what they want. When author has specified a color UA must use as is<br> <dael> florian: Second is investigating what do we consider author has set a color<br> <dael> florian: Maybe we push second part to later?<br> <dael> iank_: Inside of Blink we have a mech to detect if something is spec by an author. We use it rarely, appearance and highlight stuff. I don't know if WK has that<br> <dael> florian: Found what I was talking about. Condition is if bg color yields a cascaded value from author origin. We could use that<br> <dael> florian: Not as simple as heycam wanted<br> <dael> fantasai: But it's something you're already detecting<br> <dael> heycam: If other things use this mech I guess it's okay<br> <dael> Rossen_: Prop: For colors that originate in the...<br> <dael> florian: If there is color in the author origin the UA must respect that color<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: If there is color in the author origin the UA must respect that color<br> <fantasai> s/that color/that color exactly, including its alpha/<br> <dael> Rossen_: Do we need to resolve on the magic?<br> <dael> florian: If there isn't a color from the author origin the UA may apply magic<br> <dael> Rossen_: Happy to resolve on that<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: If there isn't a color from the author origin the UA may apply magic<br> <PaulG> q+<br> <Rossen_> ack PaulG<br> <dael> PaulG: Was the alpha transparency magic from Safari b/c they were rendering on top of the text? Do we need to add to spec selection is rendered under text?<br> <dael> fantasai: That is in the spec<br> <dael> chrishtr: Does resolution say UA must not apply magic otherwise?<br> <dael> florian: That's the first resolution<br> <dael> fantasai: Spec allows magic that's not controllable by CSS like dimming content. Need to clarify they can't change colors<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6853#issuecomment-1498278929 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 April 2023 23:28:23 UTC