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

[EiraGe]

The spec of "auto" behavior says:

The UA determines the cursor to display based on the current context

and

auto behaves as text over text, and default otherwise

According to the css tests cursor-auto-005 and cursor-auto-002 the auto cursor shouldn't change when it's over a text input area or a link. Two chromium bugs were filed by @frivoal :
bug 1 and bug 2.

I think the the cursor should shows "it's a clickable link" when over a link and I-beam for the input area when it is "auto", because it should change based on the current context. Is the spec wants cursor doesn't show it's over link and over input area?

Also, "auto" is the initial value for cursor style: https://drafts.csswg.org/css-ui-3/#cursor. In Chrome, "auto" behave same as cursor style not set. But in Firefox, set "cursor: auto" cursor over link is different from not setting cursor style.
Should "auto" behave same as style not set?

[frivoal]

Is the spec wants cursor doesn't show it's over link and over input area?

No, that is not the goal of the spec. The cursor is expected to change (hand over link, I-beam over input area…), but it is expected to do that using the UA stylesheet, not using the auto value.

When we looked at standardizing exactly what the auto value does, we decided using auto to do all the cursor changes in different contexts was not a good approach: the list of situations where it needs to change to something would be very long, and possibly changing over time, making it difficult to standardize.

As some elements contain text AND empty areas, and it is not possible to use selectors to tell these appart, auto needs to handle that, and switch from the default cursor to the I-beam when it is over empty areas or over text. However, to switch to the pointer cursor over links, you can simply add :any-link { cursor: pointer; } in the UA stylesheet. Similarly, textarea { cursor: text; } will give you the I-beam over <textarea> elements.

I think it would be fair to add a note to the specification to clarify that expectation, but I do not think any behavior change is needed.

However, if you find situations where you want to change the cursor but cannot do it in the UA stylesheet, please let us know. That would absolutely be something to consider for an addition to the specification.

[EiraGe]

1. I think the definition of "auto" in spec is not clear.
   It says "auto: The UA determines the cursor to display based on the current context, specifically: auto behaves as text over text, and default otherwise." The first part of this sentence is contradict to the second part.

2. when someone set "cursor: auto", should it be same behavior with not setting anything?

[frivoal]

think the definition of "auto" in spec is not clear.
It says "auto: The UA determines the cursor to display based on the current context, specifically: auto behaves as text over text, and default otherwise." The first part of this sentence is contradict to the second part.

The key word is "specifically". The second part is an explanation of how to do the first one, which means the UA is not allowed to change the cursor based on context in any way it wants, but only in one way.

It would be better to phrase it this way:

"auto: behaves as text over text, and default otherwise.
Note: Other context-based cursor changes are expected to be provided by the UA in the UA stylesheet. For example, for HTML, the UA stylesheet may contain :any-link { cursor: pointer; }."

---

2. when someone set "cursor: auto", should it be same behavior with not setting anything?

No. when a user sets cursor: auto it should do "text over text, and default otherwise", and only that. If someone wants "whatever the browser would do, including anything in the UA stylesheet, just as if I hadn't set anything", then that is achieved with cursor: revert (see https://drafts.csswg.org/css-cascade-4/#valdef-all-revert).

[EiraGe]

I test the "cursor:auto" behavior with this page: http://output.jsbin.com/yixetov
Currently, When setting "cursor: auto"
Chrome, Edge and Safari have same behavior.
Firefox doesn't have pointer cursor when over link, but has text cursor when over text area.
Is the desired behavior what Firefox does?

(In Mozilla's page: https://developer.mozilla.org/en/docs/Web/CSS/cursor, they use "E.g." instead of "specifically". )

Also, when there is text inside textarea, one html element will have two types of cursor. It seems weird.

[frivoal]

Is the desired behavior what Firefox does?

yes. Edit: see next comment.

In Mozilla's page: https://developer.mozilla.org/en/docs/Web/CSS/cursor, they use "E.g." instead of "specifically".

That's a mistake.

Also, when there is text inside textarea, one html element will have two types of cursor. It seems weird.

div/p/article… elements have two types of cursors for 1 element: text over text, default over empty areas. That is what auto is for. Everybody has been doing that forever, so I do not think that this is weird.

For textarea (and a number of similar form controls), the behavior would be the same if cursor is left to its auto value, but adding textarea {cursor: text} in the UA stylesheet is also an option.

The specification currently does not propose additions to the UA stylesheet, and leaves it up to browsers to do what they want. Maybe css-ui-4 should make an attempt at giving a UA stylesheet for HTML for cursors over various elements, but for now the expectation is that browsers will do it by themselves.

[frivoal]

Is the desired behavior what Firefox does?
yes.

Sorry, I replied too fast. The firefox behavior over the link is the desired one. Over the text area it is not (all browsers are incorrect according to the specification).

[EiraGe]

@RByers @tabatkins Do we want to match this "cursor: auto" behavior? Could you think of any possible problem for implementing this?

[dbaron]

For what it's worth, the places where Gecko (excluding XUL) has cursor behavior that's not in the UA style sheet cover:

• auto means text for text and for anything editable, and default otherwise
• text means vertical-text when in vertical writing mode
• <input type=image> treats auto as pointer (not sure why!)
• image maps (see [css-ui-3] should there be a note pointing to HTML's definition of cursor applying to image maps? #1618)
• draggable frameset borders
• support for NPPVpluginUsesDOMForCursorBool in the plugin API
  (Only the first three items relate to the behavior of auto.)

[frivoal]

@dbaron :

auto means text for text and for anything editable, and default otherwise

This is per spec.

text means vertical-text when in vertical writing mode

This is also per spec, as a “may”. (see https://drafts.csswg.org/css-ui-3/#valdef-cursor-text)

<input type=image> treats auto as pointer (not sure why!)

Is there any reason why this could not be moved to the UA stylesheet?

draggable frameset borders

This is per spec, based on this statement: "User agents may ignore the cursor property over native user-agent controls such as scrollbars, resizers, or other native UI widgets e.g. those that may be used inside some user agent specific implementations of form elements."

support for NPPVpluginUsesDOMForCursorBool in the plugin API

This is Netscape Plugins, right? These things are on their way out, can we just ignore it and assume it is going to disappear before too long?

image maps (see #1618)

As far as I can tell, this could be done via the UA stylesheet, couldn't it?

[frivoal]

@RByers @tabatkins @EiraGe
See these old mails/minutes for context as to why the spec was written this way:

https://lists.w3.org/Archives/Public/www-style/2014Nov/0531.html
https://lists.w3.org/Archives/Public/www-style/2015Jan/0087.html
https://lists.w3.org/Archives/Public/www-style/2015Feb/0039.html
https://lists.w3.org/Archives/Public/www-style/2015Mar/0314.html

[dbaron]

> `<input type=image>` treats auto as pointer (not sure why!) Is there any reason why this could not be moved to the UA stylesheet?

I suspect not. But first I'd look into seeing whether other UAs match it.

> image maps (see #1618) As far as I can tell, this could be done via the UA stylesheet, couldn't it?

Not really. It requires code to say that for images, if the pointer is in the area covered by an area element, use the computed cursor of the `area` rather than of the `img`. (`area`s themselves can't really be event targets since they can be referenced from multiple `img`s.) But otherwise it's doing what the relevant specs (CSS + HTML) say.

[frivoal]

image maps (see #1618)

As far as I can tell, this could be done via the UA stylesheet, couldn't it?

Not really. It requires code to say that for images, if the pointer is in the area covered by an area element, use the computed cursor of the area rather than of the img. (areas themselves can't really be event targets since they can be referenced from multiple imgs.) But otherwise it's doing what the relevant specs (CSS + HTML) say.

But that's not specific to the auto value, that's for all values of the cursor property. So there is some magic needed to make the hit testing work, and to make the inheritance go from the img (or obj) element rather than from the map element, as the HTML spec requires, but that magic isn't really something that belongs in the auto value.

[RByers]

@RByers @tabatkins Do we want to match this "cursor: auto" behavior? Could you think of any possible problem for implementing this?

Sorry for the delay. Yes we should try to match the spec (and if we hit any significant web compat problems those are potential spec issues). To the extent we're just matching Firefox the web compat risk is low and you can probably just treat such changes as a bug-fix (but let me know if we get any bugs about broken sites). If you find that you're doing something which no other browser appears to do today though then we might need to be more cautious.