[CSS-UI] Where should cursor-shape apply?

[schenney-chromium]

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".

[frivoal]

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]

See #11373 for an attempt at a PR that would make this clear.

[frivoal]

@astearns @atanassov can you schedule this soonish? As this PR is getting older, I've had to rebase the it to resolve conflicts that were introduced since, and I'd rather not need to do that too many times. Alternatively, Async CfC?

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Caret properties apply to elements that accept input

[astearns]

RESOLVED: Caret properties apply to elements that accept text input

(I modified the resolution based on a comment in the PR)