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] Where should cursor-shape apply? #11335

Open
schenney-chromium opened this issue Dec 7, 2024 · 2 comments
Open

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

schenney-chromium opened this issue Dec 7, 2024 · 2 comments
Labels

Comments

@schenney-chromium
Copy link
Contributor

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 frivoal added the css-ui-4 Current Work label Dec 12, 2024
@frivoal
Copy link
Collaborator

frivoal commented Dec 14, 2024

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
Copy link
Collaborator

frivoal commented Dec 14, 2024

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

frivoal added a commit to frivoal/csswg-drafts that referenced this issue Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants