- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 23:58:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Allow developers to set the text color under the caret when caret-shape is block`, and agreed to the following: * `RESOLVED: Add a second color to caret-color which sets the font color of the following char when caret-shape is block` * `RESOLVED: Default value for this new second color is "auto", letting the UA decide on the contrasting color` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> florian: if you set caret-shape to block, and don't set color, we have spec text saying UA should choose a color that maintains contrast<br> <TabAtkins> florian: we didn't handle opposite situation, a block caret and user sets the color, and now the text fails to contrast<br> <TabAtkins> florian: deliberately chose a caret that matches the text<br> <TabAtkins> florian: user might expect the *text* to then contrast the caret<br> <TabAtkins> florian: I propose we extend caret-color to have an optional second argument, giving the color of the text when it's overlapping the caret<br> <ChrisL> q+<br> <TabAtkins> florian: if we don't have compat, make the default be "browser can flip color if needed".<br> <astearns> ack ChrisL<br> <TabAtkins> florian: otherwise default is currentcolor<br> <TabAtkins> ChrisL: what are caret-shape options?<br> <TabAtkins> florian: bar, underscore, block<br> <TabAtkins> ChrisL: what happens with descenders/etc outside the caret?<br> <TabAtkins> florian: stepping back, the block caret is already somewhat sensitive to text around.<br> <TabAtkins> florian: it checks the next character so it can be the right width<br> <TabAtkins> florian: i'm suggesting that, with the same definition, can look at text color, and is allowed to be smart about swashes poking out<br> <TabAtkins> florian: at least apply the color to the active character. if you're extra smart, maybe do visual intersection<br> <TabAtkins> ChrisL: my concern is a character changing color due to caret but its acute accent is a different color<br> <TabAtkins> florian: my default proposed behavior is that the ehwole next character changes color<br> <TabAtkins> florian: so two qs. first, do we want this second parameter at all?<br> <TabAtkins> florian: if yes, is the default `currentcolor` (as it currently effectively is) or is it `auto` that preserves contrast?<br> <TabAtkins> florian: I suspect the most compatible behavior is to allow currentcolor+auto and default to currentcolor<br> <TabAtkins> florian: but maybe not ideal<br> <TabAtkins> ChrisL: or add a new property, caret-color-text<br> <TabAtkins> florian: yeah, that's another approach<br> <TabAtkins> astearns: q of add a value or a separate property hinges on whether you need these to cascade seperately<br> <emilio> scrollbar-color is a similar precedent<br> <TabAtkins> florian: I think you want them together<br> <ntim> q+<br> <TabAtkins> kbabbitt: I was thinking about a use-case where I have a paragraph of text that's mostly one color except a span, I might want the caret to follow the underlying text... maybe that means it should be two properties<br> <TabAtkins> ChrisL: you could also do a relative color using currentcolor<br> <TabAtkins> florian: I think because it'sa bout contrast you want to set them together<br> <astearns> ack ntim<br> <TabAtkins> ntim: where does that second color show up?<br> <astearns> q+<br> <TabAtkins> florian: in bar or underscore it doesn't matter, but if you have a block caret it overlaps the next character<br> <TabAtkins> ntim: so you'd have the original text...<br> <TabAtkins> TabAtkins: The following character is rendered in this new color<br> <TabAtkins> ntim: oh I thought the caret covered the text<br> <TabAtkins> florian: No, it displays the text still<br> <astearns> q-<br> <TabAtkins> emilio: for anything other than block, you just draw it on top<br> <TabAtkins> florian: but for block you do render behind/around<br> <TabAtkins> florian: this property *would* allow you to make the text invisible with the caret if you want<br> <TabAtkins> TabAtkins: I think I've seen console environments with either behavior<br> <TabAtkins> astearns: if this second color was specified with underline or bar, it just wouldn't have an effect?<br> <TabAtkins> florian: yes<br> <TabAtkins> astearns: so are we arriving at a proposed resolution?<br> <TabAtkins> astearns: objections?<br> <TabAtkins> arronei: do we want to clarify we don't want a property?<br> <TabAtkins> astearns: it's in the discussion and the resolution will be for the second value, specifically<br> <TabAtkins> RESOLVED: Add a second color to caret-color which sets the font color of the following char when caret-shape is block<br> <TabAtkins> florian: now second question: is the initial value current-color, or auto?<br> <TabAtkins> florian: current Chrome behavior is effectively currentcolor<br> <TabAtkins> florian: downside is authors *might* have their own idea of what's ok, and already be happy with their text+caret colors<br> <TabAtkins> TabAtkins: I suspect, since the major use-case of block caret is console emulation, and consoles (at least, mine) do the inversion, we should default to "auto"<br> <TabAtkins> florian: happy to spec it that way<br> <TabAtkins> PROPOSED: Default value for this new second color is "auto", letting the UA decide on the contrasting color<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: Default value for this new second color is "auto", letting the UA decide on the contrasting color<br> <TabAtkins> florian: if the author actually wants the color to be the same as the rest of the text, do we expect them to type currentcolor? or give them "normal"?<br> <TabAtkins> fantasai: currentcolor seems fine<br> <TabAtkins> florian: k<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13723#issuecomment-4166453471 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 23:58:40 UTC