You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cursor-shape property sets the shape of a caret, which addresses a reasonably common use case for text editing by allowing terminal-like styling for editable text.
But it makes little sense for carets used in other situations, particularly caret-based-navigation. The spec relies on font metrics and text shaping results to determine the size of a block caret and the width of an underscore, and these things are only available in text (or could come from the root).
I propose the spec be updated to limit caret-shape to "editable elements" as defined for user-select. Even better, define all the caret properties as "must apply" to "editable elements" and may apply to other carets (like navigation or some future thing). The example above of an image would presumably fall back to "no next character".
The text was updated successfully, but these errors were encountered:
Mostly, I agree. In fact, I think that's what the spec already attempts to say, though it may not be doing it very effectively.
Looking through the text, there are various hints and phrases indicating that we're only trying to talk about the caret in the limited sense you want, not the navigation caret, or any other caret that the UA might have. But the phrasing isn't consistent, so I can see how there remains some ambiguity.
That said, I don't think editable elements is exactly what we're looking for, as by the current definition, the when subtree is editable thanks to contenteditable, the element at the root of the editable subtree is considered an "editable element", but not its descendants. I think going by "elements that accept input" will work.
I'll make a pull request.
frivoal
added a commit
to frivoal/csswg-drafts
that referenced
this issue
Dec 14, 2024
The cursor-shape property sets the shape of a caret, which addresses a reasonably common use case for text editing by allowing terminal-like styling for editable text.
But it makes little sense for carets used in other situations, particularly caret-based-navigation. The spec relies on font metrics and text shaping results to determine the size of a block caret and the width of an underscore, and these things are only available in text (or could come from the root).
Consider in particular this result for a chrome test with an image in content editable. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/platform/mac/editing/pasteboard/copy-standalone-image-expected.png
I propose the spec be updated to limit caret-shape to "editable elements" as defined for
user-select
. Even better, define all the caret properties as "must apply" to "editable elements" and may apply to other carets (like navigation or some future thing). The example above of an image would presumably fall back to "no next character".The text was updated successfully, but these errors were encountered: