[css-pseudo] Safari’s ::selection “wash” and UA tweaks to highlight colors #6853
Labels
Projects
Comments
|
I agree, but we should also allow |
|
|
|
If Safari makes opaque colors specified by the author translucent, then it's going to have different highlight colors than e.g. Blink and Gecko. This can, in fact, result in color/background pairs that while readable in one browser are unreadable in another--and this has occurred on real websites in the past. So either everyone has to apply magic alpha the same way, or there is no magic alpha. We can't have every UA choosing independently on whether to apply alpha magic to author-specified ::selection colors, if we want authors to be able to reliably specify sufficiently-contrasting colors. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<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<dael> fantasai: There was a bug report on this with white text and white brackground <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 <Rossen_> q? <dael> fantasai: I don't want every UA to do whatever and they end up unreadable <dael> florian: Desire to match platform is understandable but leads to this where authors use something not interpretable <dael> Rossen_: Yeah, this is a problem when unreadable <dael> fantasai: Default it's fine to do whatever but we need to agree on how the colors are used <florian> s/not interpretable/not interpretable, and thereby unreadable in some casees/ <fantasai> s/white background/white background. Looked great on Safari, was completely unreadable in Firefox./ <dael> Rossen_: Anyone have an opinion on if we want to add alpha channel magic or agree on the specific colors? Which path forward? <GameMaker> q+ <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 <dael> Rossen_: I agree that it would be an uphill battle <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 <dael> iank_: If you slide all the way to the right on Safari you'll see the magic alpha applied on Safari <dael> GameMaker: That makes sense <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 <Rossen_> ack GameMaker <dael> Rossen_: Magic described will match the current magic giving the alpha in the last stop on Safari? <heycam> q+ <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? <GameMaker> q+ <dael> iank_: Proposal is the opposite <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 <Rossen_> ack heycam <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? <dael> fantasai: Either system color or not specified other than an internal keyword. I think system colors is most straightforward <dael> heycam: Author can't read because getComputedStyle? <dael> fantasai: There's a compat vs security discussion on there <dael> florian: Worried about round tripping? <iank_> how do you access the ::selection getComputedStyle ? <dael> heycam: More about the exact way ofdetermining the author wrote a color <Rossen_> s/getComputedStyle?/getComputedStyle::selection/ <dael> florian: As long as it's written you don't have a preference? <dael> heycam: I prefer value of property rather than result of cascade. Seeing if there's a rule with a color property <Rossen_> ack GameMaker <dael> GameMaker: Sounded like we might lean toward defining this and I would say we don't want to define special magic <dael> florian: Not looking for special magic, but looking for when it does and does not apply <dael> GameMaker: Sounds like on same page <dael> Rossen_: Let's look for resolution <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 <dael> florian: We would need to do what heycam doesn't prefer <dael> heycam: Do we have other examples of looking at cascade to determine if something was spec? <dael> iank_: Maybe highlight? <dael> florian: I think there's logic around bg and fg. Can we use same logic around having set things? <fantasai> https://drafts.csswg.org/css-pseudo-4/#paired-defaults <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 <dael> florian: Second is investigating what do we consider author has set a color <dael> florian: Maybe we push second part to later? <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 <dael> florian: Found what I was talking about. Condition is if bg color yields a cascaded value from author origin. We could use that <dael> florian: Not as simple as heycam wanted <dael> fantasai: But it's something you're already detecting <dael> heycam: If other things use this mech I guess it's okay <dael> Rossen_: Prop: For colors that originate in the... <dael> florian: If there is color in the author origin the UA must respect that color <dael> Rossen_: Objections? <dael> RESOLVED: If there is color in the author origin the UA must respect that color <fantasai> s/that color/that color exactly, including its alpha/ <dael> Rossen_: Do we need to resolve on the magic? <dael> florian: If there isn't a color from the author origin the UA may apply magic <dael> Rossen_: Happy to resolve on that <dael> Rossen_: Objections? <dael> RESOLVED: If there isn't a color from the author origin the UA may apply magic <PaulG> q+ <Rossen_> ack PaulG <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? <dael> fantasai: That is in the spec <dael> chrishtr: Does resolution say UA must not apply magic otherwise? <dael> florian: That's the first resolution <dael> fantasai: Spec allows magic that's not controllable by CSS like dimming content. Need to clarify they can't change colors |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Safari has a special approach to painting text ::selection, where it only paints a “wash” on top of the text being selected (see #6022 irc log, “blue wash”, “magic transluscent”). The way this is achieved is interesting: iff the author sets the ::selection background to a fully-opaque color, Safari overrides the alpha value to make the color translucent (demo).
But @fantasai says:
I don’t think we can allow Safari to paint ::selection as a translucent “wash” and forbid Safari from making opaque ::selection backgrounds translucent, because any author unaware of Safari’s different approach might set the ::selection background to an opaque color (such as a named color or other color without alpha) while expecting the selected text to stay legible.
I want to agree with @fantasai here and forbid all UA tweaks to author highlight colors (see also #6150). But I think I’m biased here, because I also feel like we should forbid the “text wash”, because both of these would make it easier to specify and test highlight painting precisely.
(@smfr, @mrego)
The text was updated successfully, but these errors were encountered: