[css3-ui] cursor:auto (Issue 48)

We have resolved to define cursor:auto in the narrowest possible way:
Everything that can be handled via the UA style sheet should be, and auto
should be defined to account for necessary behavior that cannot be dealt with
this way.

This is an attempt to define what that means, looking at the various things
auto could need to handle.

1) 'text' vs 'default'
Regular text elements such as div, p, span, etc, usually display a ''text''
cursor over the text itself, but a ''default'' cursor when hovering on empty
parts (between lines, over padding, margin or borders...).

Also, BradK suggested UAs should render auto as the default cursor when over
text when user-select is none. Given that ''text'' is defined as "Indicates
text that may be selected.", this is reasonable.

=> As there is nothing for selectors to match, auto needs to switch between
''default'' and 'text' depending on whether selectable text is being hovered
or not.

2) text vs vertical-text

The 'text' cursor value already allows the cursor to follow the orientation of
the text. 'vertical-text' can force the cursor to be vertical, but it isn't
needed to allow it.

=> 'auto' not needed, 'text' already smart enough

3) resize cursors

When an element's 'resize' property is not 'none' and 'overflow' is not
'visible', it can be resized by the user, and a resize handle (or some
equivalent mechanism) is shown. UAs may show a resize cursor when this resize
handle is hovered.

However, even if the cursor on the element is not set to auto, UAs may want to
show a resize cursor over the resize handle, although browsers are
inconsistent about this: FF shows a resize cursor over the resize handle
regardless of the cursor property, chrome never shows a resize cursor, safari
only shows a resize cursor if the cursor property is auto. Demo here:
http://jsbin.com/voxiwo/1/watch

Whether this is done by building the resize handle with web components (or
similar) and styling that, or by having the UA ignore the cursor property when
interactive with native controls, this shows that including this behavior into
the 'auto' value is neither needed nor sufficient deal with this use case.

=> 'auto' does not need to account for resize handles

4) links

A ''pointer'' cursor is normally shown over links. However, this can easily
be expressed in the UA stylesheet:

:link, :visited {cursor: pointer;}  /*or :any-link, if implemented */

This is actually what the whatwg's UA stylesheet for HTML specifies
(https://html.spec.whatwg.org/multipage/rendering.html#phrasing-content-3),
and at least Firefox already seems to be handling it this way.

=> 'auto' does not need to account for links

5) form controls:

dbaron said:
> The case where we've gotten bug reports is authors look at
> the spec and auto on a form control should mean the form
> control cursor and on a link the link cursor. I think we
> should say what switching is a part of auto.

If ''auto'' shows ''default' unless it is over selectable text, you
would get the behavior you want on form controls. Even if it didn't,
this can be expressed with regular CSS.

  button, input[type=button], ... {cursor: default;}

As for links, see point 4.

=> no built-it awareness of form controls and links into 'auto' seems
necessary to achieve desired styling.

I'll note that unlike Safari, Chrome, and IE, Firefox doesn't show a
pointer cursor on a link inside a button, and makes the following a no-op (at
least on OS X): "button a[href] {color:pointer;}"

Maybe Gecko should consider increasing the set of properties it allows on
children of buttons to include 'cursor'. I don't think any spec change is
needed for that though.

6) Other UA level mechanisms

What if the UA has a special feature that it wants to indicate with a special
cursor?

The UA is always free to ignore CSS and do whatever it wants if what it is
doing is out of scope for CSS. It already does, actually, for example when it
displays a busy cursor if javascript is stuck in an infinite loop.

Besides, if the UA wants to do something special that varies depending on what
you're hovering in the page, there's a priori no reason to think this couldn't
be expressed in terms of selectors, and typing it to 'auto' would probably be
a bad idea anyway, as the special cursor would fail to show when 'cursor' is
set to something else.

=> no need for 'auto' to handle UA level behaviors


Conclusion:
I might have missed something, but as far as I can tell, the only thing 'auto'
needs to be able to switch between is 'text' and 'default'. Everything else I
can think of can either be done with selectors or is out of scope for CSS.

Based on all this, here are three proposed changes I think we should make to
the spec. Only the first one is necessary to resolve this issue, but the other
two are relevant as well, and should help clarify the matter.

Proposed text for a new definition of auto:

  The User Agent must either display the ''text' cursor or the ''default''
  cursor. The full logic for choosing between this two is implementation
  dependent, but as a general rule, User Agents should use the ''text''
  cursor when hovering over selectable text, and ''default'' otherwise.
  When displaying as the ''text'' cursor, the rules for adapting to
  vertical text or text rendered at an angle apply.

Proposed tightening of the definition of ''text'' to make sure it works well on
vertical text:

  <dd>Indicates text that may be selected. Often rendered as a vertical I-beam.
- User agents may automatically display a horizontal I-beam/cursor
+ User agents should automatically display a horizontal I-beam/cursor
  (e.g. same as the ''vertical-text'' keyword)
- for vertical text, or for that matter,
+ for vertical text, and may display
  any angle of I-beam/cursor for text that is rendered at any particular angle.
  </dd>

Proposed additional text to include in the general cursor definition, to
clarify the resize use case:

  When the user is interacting with controls provided by the User Agent which
  are not part of the DOM, such as in-page resize handles or scroll bars, the
  User Agent may display any cursor it deems appropriate, with no regards to
  the 'cursor' property.

- Florian

Received on Tuesday, 3 February 2015 17:49:27 UTC