Skip to content
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

Closed
Crissov opened this issue Oct 8, 2019 · 10 comments
Closed

[css-ui] Actual caret caret-shape #4402

Crissov opened this issue Oct 8, 2019 · 10 comments

Comments

@Crissov
Copy link
Contributor

Crissov commented Oct 8, 2019

caret-shape currently defines three common types: bar, block and underscore.

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.

@AmeliaBR
Copy link
Contributor

AmeliaBR commented Oct 8, 2019

Do you have examples of interactive user interfaces that are using these marks, or complaints about the inability to use them?

@AmeliaBR AmeliaBR added the css-ui-4 Current Work label Oct 8, 2019
@litherum
Copy link
Contributor

litherum commented Oct 9, 2019

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.

@AmeliaBR
Copy link
Contributor

AmeliaBR commented Oct 9, 2019

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.

@litherum
Copy link
Contributor

litherum commented Oct 9, 2019

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.

@tabatkins
Copy link
Member

In either case, tho, you can't use CSS to make the caret do something special only when it's in an ambiguous place.

@litherum
Copy link
Contributor

Right; the behavior I described above should be implemented by browsers, not websites.

@Crissov
Copy link
Contributor Author

Crissov commented Oct 10, 2019

Do you have examples of interactive user interfaces that are using these marks,

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.

or complaints about the inability to use them?

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.

@frivoal
Copy link
Collaborator

frivoal commented Dec 29, 2019

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.

@Crissov
Copy link
Contributor Author

Crissov commented Dec 29, 2019

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.

@frivoal
Copy link
Collaborator

frivoal commented Dec 30, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants