Re: [csswg-drafts] [css-ui-4] inteference with the caret blinking and the ability to animate its color (#9707)

The CSS Working Group just discussed `[css-ui-4] inteference with the caret blinking and the ability to animate its color`, and agreed to the following:

* `RESOLVED: The caret animation is auto versus none`

<details><summary>The full IRC log of that discussion</summary>
&lt;Frances> florian: Using the caret-color property that is implemented is an animated property. Could use the wrong blinking between transparent and the color. Proposal is to make it possible, to opt to not animate the caret.<br>
&lt;Frances> Florian: If there is not an override, we need to create a more reliable animation. Use various built in types of animations. Add none and auto.<br>
&lt;kbabbitt> q+<br>
&lt;Frances> florian: Counter point is that sometimes the browser can do things that is not just thinking, if stopping the animations then could lose animating the caret at the same time.<br>
&lt;Frances> Kevin: Could a better property be the caret pseudo element to replace the blinking and a box caret, would it be more extensible?<br>
&lt;Rossen_> ack kbabbitt<br>
&lt;TabAtkins> I think the "people are already just completely replacing the caret, we likely won't make this worse" is reasonable, so adding this won't make things meaningfully worse (and is outweighed by having the native caret be used, which is less janky).<br>
&lt;Frances> Florian: This could possibly expose too much structure, most carets might be simple, might be used in case. Could be a dormant property. Make an explicit not implementing the caret in adding support and being able to add support. Browsers that do not want to yield should be able to not implement the caret<br>
&lt;flackr> q+<br>
&lt;schenney> q+<br>
&lt;Frances> flackr: We have some pseudos to specify only a few properties.<br>
&lt;Frances> Florian: There are some fairly limited carets that exist. Such as both sides of the logical locations. Not sure if a caret pseudo would be the right thing.<br>
&lt;vmpstr> tab, the blinking rate though is something that is (or can be) user set and so ignoring that because author said so seems wrong.. But I agree that if authors already replacing the whole caret, maybe this isn't worse<br>
&lt;Frances> Florian: What does width mean? Multiple pieces? We would need to describe the structure.<br>
&lt;Rossen_> ack flackr<br>
&lt;Frances> Tab: We already have existent proof in manually reimplementing them. It could be less janky with a more correct caret. More people could replace the animation of a caret for the user of a web page.<br>
&lt;Frances> Tab: Leans towards this being a useful thing to specify.<br>
&lt;Frances> Florian: We need to be careful to not interfere in any way in accessibility.<br>
&lt;Frances> Schenney: The most similar pseudo would be spelling and grammar, text browsers render native text-decorations<br>
&lt;Frances> Schenney: We can outline and could put a special caret.<br>
&lt;Frances> PROPOSAL: The caret animation is auto versus none<br>
&lt;Frances> RESOLVED: The caret animation is auto versus none<br>
&lt;Rossen_> github-bot topic end<br>
&lt;Rossen_> github-bot topic: end<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9707#issuecomment-1933199902 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 8 February 2024 01:02:20 UTC