W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2017

Re: [csswg-drafts] [css-ui-3] auto cursor should behaves as default cursor except for text?

From: François REMY via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Oct 2017 02:28:39 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-335663066-1507688903-sysbot+gh@w3.org>
> My understanding was that switching to a text cursor over "anything editable" was doable in the UA stylesheet (:read-write { cursor: text; } for browsers that support that, or a more exhaustive list of things for those that don't), and that we therefore wanted to move to doing that, so the spec and the test reflect that (and we have an old resolution for that somewhere, which I'll dig out if that's helpful).

I am not entirely sure everything can be expressed as css selectors. Consider `<div style="user-select:none">Non-selectable text</div>`; I believe user agents should be allowed and encouraged to behave like Firefox and show an arrow cursor over that text. Of course, the only reason it is possible to implement is because we let "auto" fallback to a value computed at hit-testing time (the "magic" part, which in Edge is a boolean called the WantArrowCursor flag, true if `auto` would be `default` and false it it would be `text`). I don't want to change the logic that computes this value, so to continue to have this work we need the behavior of auto to allow user agents to use more of the context than just "Am I over text or not?" and allow to consider selectability and editability.

I do agree with you on the link-in-contenteditable case though: we can and should use `:any-link:not(:read-write) { cursor: pointer }` (or equivalent) and I am not arguing for a change here that would make `auto` suddenly impossible for developers to predict again; I would just prefer a tweak in the wording that would help us describe how the logic for disambiguating `auto` between `text` and `default` actually works so we don't have to rewrite that part in all browsers (which means Firefox should pass the test, and we can enable Edge to do so without fearing any compat risk, which I think is also what motivated Rick above to weigh in positively for the Chrome counter-part).

> [As for your test, you should probably] separate the places where we expect auto to look like text from those where it is expected to look like default, for ease of testing

I agree we might want to split this into multiple tests, I just tried to do a quick edit to your for my own testing purposes. 

Unfortunately there is no interop on whether disabled text fields allow selection of text (they do in chrome so they show the text-beam cursor, while firefox and edge do not allow to focus a disabled field and therefore do not allow selection of its content so we both display an arrow-pointer; I think all browsers agree that a readonly input shows a text-beam cursor though because its content is selectable even if not editable).

To me, this divergence would be allowed per-spec with the edit I propose because the difference in cursor is also tied to a difference in functionality which is what `auto` disambiguation is really all about.

I am not sure it would be right to enforce a particular value in the test, in the end it depends on what the operating system considers editable and selectable, which might vary per platform.

-- 
GitHub Notification of comment by FremyCompany
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1598#issuecomment-335663066 using your GitHub account
Received on Wednesday, 11 October 2017 02:28:27 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:19 UTC