-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-ui] Actual caret caret-shape #4402
Comments
Do you have examples of interactive user interfaces that are using these marks, or complaints about the inability to use them? |
I’ve seen bidi-aware text fields on Windows use this UI when the caret is between bidi runs. In some situations, when you type a character, if it’s an RTL character, it would appear in one place, but if it’s an LTR character, it would appear in another place, because of how the bidi runs surrounding the caret are placed. These bidi-aware fields will place the upper caret in one of the two visual insertion points and the lower caret in the other visual insertion point. Even though there are two visual carets draen on the screen, there’s still only one logical caret. If a text field doesn’t do this, and only has a single visual caret, the user can get into a situation where the caret is in one place, but when they press a key, the character appears in some visually unrelated place, which is a bad experience. |
The split caret for RTL/LTR edges seems like a more complex issue (I think I've also seen it displayed as a partial bar at the two possible places), but definitely something that needs to be considered in this property. Might want to get internationalization folks to weigh in, but one question is whether that should be left up to the user agent to do something smart when split caret points are required, regardless of whether the author considered it when setting the caret type. |
Oh, the case I was thinking of may have actually been two half bars, instead of two carets as I described. In that case, please disregard my above comment. |
In either case, tho, you can't use CSS to make the caret do something special only when it's in an ambiguous place. |
Right; the behavior I described above should be implemented by browsers, not websites. |
Unfortunately, I do not. I am pretty sure I have seen a caret below in a boot loader CLI a while ago, but I cannot find or remember it exactly. Since, unlike an I-beam or vertical bar, an arrowhead caret would usually not need to blink, it could perhaps be a useful feature to improve accessibility.
While researching this a bit, I also came across the issue of slanting carets and selection edges to match the angle of slanted or italic font variants. |
Controlling the caret in general is useful, including its shape, as evidenced by the links provided in #4402 (comment), and the specification is exploring that. However, given no evidence that the specific caret shape that this issue is suggesting is in common demand, I'm closing as wontfix. This could be revisited on the basis of evidence of strong demand for this specific variant. |
I mentioned accessibility, but what about print and other static media? If one wanted to have a visible caret there, a chevron shape would be preferred, I assume. Browsers are not that strong in such media, so Iʼd like to hear some input from vendors of CSS to PDF converters, die insurance. |
The caret is the UI element that shows where text insertion will happen if you start typing. This isn't a thing on print and other static media. You're free to include images and graphical effects where you want, to display something resembling a caret, chevron-like if that's what you want, but I don't see printing as a relevant use case for styling the actual text insertion caret in particular ways. |
caret-shape
currently defines three common types:bar
,block
andunderscore
.In handwritten proofreading marks, a caret is an arrow-head instead, either pointing upwards from below (like U+2038
‸
caret and ) or downwards from above (like U+02C7ˇ
caron), cf. U+2380⎀
insertion symbol and U+2324⌤
. Additionally, there are variants with one leg extended (e. g. like U+2041⁁
caret insertion point).I suggest to add keywords for these. They would be horizontally positioned like
bar
.Iʼm not sure whether there should also be a way to have both at once, an arrow-head from the top and one from the bottom.
Iʼm also not sure whether there should also be variants with filled chevrons, i. e. triangles.
The text was updated successfully, but these errors were encountered: