[css-ui]Spec for cursor during selection?

[EiraGe]

Is there spec about cursor change during selection (Like over link)? @frivoal
This seems cannot achievable by UA stylesheet.

[frivoal]

You can do it with

:any-link {
  cursor: pointer;
}

or, if you are in a browser that does not support :any-link, with:

:link, :visited {
  cursor: pointer;
}

[EiraGe]

That's not what I'm asking.
I am asking what's the expected behavior for cursor when selecting some text which is also a link(with mouse down)?
Should it be I-beam because it's selecting text? Or pointer from UA stylesheet.

[frivoal]

Ah, I understand now.

Chrome only switches to a text cursor over link while selecting them if the link's cursor has not been overridden by the user, and uses the user specified value regardless of selection if there is one. Note that other browsers don't do this: safari changes the cursor to text while selecting even if there is another user specified cursor, and firefox does not style the cursor differently while selecting.

My suggestion would be that just like the UA is allowed to do whatever it wants over the cursor over native user-agent controls such as scrollbars, resizers, or other native UI widgets, the UA should also be allowed to use whatever cursor it wants to reflect a particular state of the UA. This would include showing the wait cursor when the page / browser is unresponsive, and could include allowing the browser to use the text cursor while selecting.

I'd consider this an editorial clarification over the existing sentence that allows the UAs to ignore the cursor property (addition in bold):

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. User agents may also ignore the cursor property and display a cursor of their choice to indicate various states of the UA's user interface, such as a busy cursor when the page is not responding, or a text cursor when the user is performing text selection.

This seems enough to make it clear that neither chrome nor safari's behaviors are spec violations. If we want to go for further interoperability in the future, I suggest tackling that in the next level of the spec, in the interest of wrapping up this level.

@EiraGe, would that work for you?

[frivoal]

Agenda+ to see if this is acceptable to the group (and if people agree it's an editorial clarification).

[css-meeting-bot]

The CSS Working Group just discussed Spec for cursor during selection?, and agreed to the following resolutions:

• RESOLVED: Add the proposed text from the github issue https://github.com/w3c/csswg-drafts/issues/1691

The full IRC log of that discussion

<dael> Topic: Spec for cursor during selection?
<dael> Github topic: https://github.com//issues/1691
<dael> Florian: We discussed and reaffirmed that we want cursor:auto to only do limited switching. All other types of adjustment are through UA stylesheet. Chrome is fixing their impl to change that and they found another thing. While user is dragging mouse they change cursor to text cursor if it's auto.
<dael> Florian: This is chrome only behavior. Safari changes always, not just auto.
<dael> Florian: My feeling is this is sort of out of scope. We already said UA can ignore cursor if you're doing something like hovering over scrollbars. We originally suggested that way the UA does to reflect state of UI is out of scope.
<dael> Florian: My suggestion is changing the cursor to reflect selection is an indication of the browsers UI is out of scope. I propose an editorial clarification to say that. Is that sounding sane?
<dael> Bert: Does to me.
<dael> myles: On mac there's already system behavior. It's valuable to be able to match platform.
<fremy> +1
<dael> Bert: That's support for Florian
<dael> jensimmons: I'd add that I have no see authors desiring the ability to control at this level of detail so sounds good to me.
<dael> Bert: Anybody else?
<dael> Bert: Proposal is add a note?
<dael> Florian: I'm doing this as a may. Proposal is in issue. [reads]
<dael> Florian: resolution would be adopt the wording in the issue.
<dael> Bert: Okay, proposal is add the text as is in the issue.
<dael> Bert: Objections?
<dael> RESOLVED: Add the proposed text from the github issue https://github.com//issues/1691
<dael> action Florian add the proposed text in https://github.com//issues/1691 to the spec
<trackbot> Created ACTION-862 - Add the proposed text in https://github.com//issues/1691 to the spec [on Florian Rivoal - due 2017-08-30].

[frivoal]

Not submitting a test case for this, as this is merely allowing the UAs to do something, not requiring them too, and also because the scope of this allowance is too broad to be effectively tested.

[IanBellomy]

Q: Has there been consideration somewhere about making the UA allowance a general rule about granting cursor-override privileges to items 'closer' to the system, i.e. shallower in the dom ?

Currently if an element in a shadow has a cursor value, that rule will have precedence over rules outside of the shadow. Of course this precedence makes sense when considering the internal styling of that shadow tree but the cursor is not a child of that tree. Nor does it seem safe to say, conceptually I don't think, that the cursor is 'on loan' or under some kind of temporary but exclusive control of the deepest element it touches. However, outer elements have no say over what a shadow tree enclosed child element might want to do with the cursor style.

Thus you can get situations where a widget that is responsible for consuming and managing sub widgets is not able to over-ride the cursor based on its state in the same way the system is allowed to override the cursor based on its state.

As a kind of quick hack example, if I wanted to swap in a circle graphic for the cursor in order to do a quick and dirty as-if-on-a-touch-screen demo of a site, that global styling could be overridden by any subcomponent. Totally expectable result in any other case, but somehow peculiar in the case of the cursor...

Assumedly the privileges that the UA gets are due to the fact that nothing running on a system should have the ability to unilaterally determine how fundamental input works. Similarly though, it seems like no consumed custom element should have the ability to unilaterally decide how a cursor appears in a document.

So, similar to the UA allowance, it seems like cursor styling is a weird case where it should be possible for priority to be reversed via some mechanism in order to handle the same categories that the UA allowance admits.

Is this an old and dismissed idea? Is it just bad?

I'm assuming that this phenomena has been thoughtfully considered somewhere else but the posts here have been the closest I've found so far. Apologies if I'm rehashing something ignorantly.