[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.

[frivoal]

To the extent we're just matching Firefox the web compat risk is low [...] If you find that you're doing something which no other browser appears to do today [...]

There's a bit of both. Firefox does more cursor changes than chrome via the UA style sheet, so some changes (like the pointer cursor over links) will be just matching Firefox. But Firefox still has some more magic built into the auto value than the spec calls for, so there we are in slightly more uncharted territory.

If we compat requires some aspect of cursor changing to be handled via auto, then this will have to be added to the spec. However, no such thing has been uncovered yet. Until then, the best would be for browsers to try to match the spec and only handle via auto things that cannot be handled otherwise, and to report back if that uncovers any web compat issue.

[css-meeting-bot]

The CSS Working Group just discussed [CSS-UI-3], and agreed to the following resolutions:

• RESOLVED: Close 1598 as no change.

The full IRC log of that discussion

<eae> Topic: [CSS-UI-3]
<Florian> https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/
<Florian> https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/17/
<eae> Florian: Link to test suite results
<fantasai> astearns, Rossen, values and units is blocked on https://github.com//issues/434#issuecomment-310183908
<eae> Florian: Normative requierments that do not have two or more implementations
<eae> Florian: Think covergae is sufficient. One test per normative assertion. Only 6 are missing for MUST. More are missing for SHOULDs.
<eae> Florian: We're getting there. Since it is six and not zero I'm not pushing for CR today. Please fix them so that we can go to PR.
<eae> Florian: One of the things I have not verified coverage for is direcitonal navigaiton properties. Implemented in presto and TD
<eae> Florian: There are some informal issues raised. Marked at risk.
<eae> Florian: Specifically, one thing we have already resolved on that has been quesiton is whether we should stick to what we have resolved on with regards to cursor.
<eae> Florian: All the changes to cursor auto should be UA stylesheet. Have filed bugs to blink about this, they filed bug back with "are you sure?".
<eae> fremy: In edge, there are some cases where we have things in the UA stylesheet. Also things that are magic. Much better to use UA stylesheet, fies bugs.
<eae> fremy: If you want to change, it should be in the UA stylesheet,
<tantek> re: https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/ I would be strongly concerned with any test that fails in blink, edge, gecko, *and* webkit
<tantek> q?
<Florian> https://github.com//issues/1598
<eae> Florian: If you find cases where it cannot be in the UA stylehseet and it isn't a known one then please file a bug back.
<eae> Florian: Can we close this bug (1598) as no change?
<eae> Rossen: Any objecitons?
<eae> RESOLVED: Close 1598 as no change.
<tantek> q?
<TabAtkins> GitHub: https://github.com//issues/1598
<Rossen> q?
<Florian> https://github.com//issues/1637
<Florian> github: https://github.com//issues/1637
<TabAtkins> GitHub: https://github.com//issues/1598

[FremyCompany]

Hey @frivoal, I was prototyping a change in Edge that would make us match the spec, but I found out I disagree with the test you wrote; when this issue was resolved I read the following reply to @dbaron's questions and thought that if this was correct I agreed with your proposed spec text, but this does not seem to be properly reflected in the spec.

auto means text for text and for anything editable, and default otherwise (@dbaron)

This is per spec. (@frivoal)

Here is what the spec currently says:

The UA determines the cursor to display based on the current context, specifically: auto behaves as text over text, and default otherwise.

Here is what I think the spec should say:

The UA determines the cursor to display based on the current context, specifically: auto behaves as text over selectable text and editable regions, and default otherwise.

selectable text is required to allow text in "user-select:none" (or disabled inputs or even text inside the button tag) not to require a text cursor, while and editable regions is required to allow a text cursor in a contentEditable div having no content at all, as well as textarea and input with cursor:auto.

Changing the spec in such a way makes all browser pass the test, but the test stops being exhaustive enough to cover all cases. I wrote a new test covering more cases as part of my change, and it shows that currently only Firefox passes the test (and my prototype in Edge).

   <p>The test passes if, when moved over every element inside the blue box, the cursor becomes a text-editing cursor over editable regions or selectable text and remains the platform-dependent default cursor otherwise.</p>
 <div id="test">
    
    <a><br></a>
    <a>linklinklinklinklinklinklinklink</a>
    <a href="javascript:void(0)"><br></a>
    <a href="javascript:void(0)">linklinklinklinklinklinklinklink</a>
    
    <button>button</button>
    <button disabled>button</button>
    <button style="-webkit-appearance:none;appearance:none">button</button>
    <button disabled style="-webkit-appearance:none;appearance:none">button</button>
    
    <textarea></textarea>
    <textarea disabled>abc</textarea>
    <textarea style="-webkit-appearance:none;appearance:none"></textarea>
    <textarea disabled style="-webkit-appearance:none;appearance:none">abc</textarea>
    
    <input />
    <input disabled />
    <input style="-webkit-appearance:none;appearance:none" />
    <input disabled style="-webkit-appearance:none;appearance:none" />
    
    <input type="button" value="input-button" />
    <input type="button" value="input-button" disabled />
    <input type="button" value="input-button" style="-webkit-appearance:none;appearance:none" />
    <input type="button" value="input-button" disabled style="-webkit-appearance:none;appearance:none" />
    
    <select></select>
    <select disabled></select>
    <select style="-webkit-appearance:none;appearance:none"></select>
    <select disabled style="-webkit-appearance:none;appearance:none"></select>
    
    <div contentEditable="true"><br></div>
    <div><br></div>
    
  </div>

[frivoal]

@FremyCompany you're right, I was a bit quick replying to @dbaron, and missed the "and anything editable".

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).

At the same time, since we have more interop on auto meaning text over editable things, I'm OK with changing the spec if that's what implementers want.

As for your test, it looks correct, but I'd split it in 4 (2x2) tests:

• 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
• separate the uses of apperance:none, as that's only defined in level 4, and I don't think we want to make level 3 tests fail because of properties of level 4.

[FremyCompany]

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. Even clearer is button:not(:read-write) { cursor: auto } which should not, I think, show a text cursor over the text content of the button tag since that text is not selectable or editable.

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 would rather not change the logic that computes this WantArrowCursor flag, so to continue to have this stay unchanged 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 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 of yours 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.

[frivoal]

Consider

Non-selectable text

; I believe user agents should be allowed and encouraged to behave like Firefox and show an arrow cursor over that text.

Agreed, and CSS-UI level 4 calls that out explicitly. But user-select:none doesn't exist in level 3, so it is left out. We could do as you suggested, and change "auto behaves as text over text" to "auto behaves as text over selectable text". Even though level 3 doesn't have a mechanism for making text non selectable, that may be a better way to record what we intend.

I would rather not change the logic that computes this WantArrowCursor flag, so to continue to have this stay unchanged 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 am not sure I've followed you 100%. I do understand (and agree with) the part about selectability, but I thought you were saying that editability could be handled via the UA stylesheet. Or is that only contentEditable? What other kind of editability cannot be handled in the UA stylesheet?

[tantek]

Agreed with changing "over text" to "over selectable text".

[FremyCompany]

What other kind of editability cannot be handled in the UA stylesheet?

Not entirely sure if such thing exists or not; maybe that second part isn't actually required, but I am afraid there are people currently using cursor:auto on edit fields today and getting their expected behavior in all browsers, and I am not sure we want to break that.

Also, since what is considered editable might vary per platform (for example, an input type="color" might be a textbox in some browser, hence editable, and a button in another, hence not editable): what value should authors use if they want to specify a custom cursor on that element with a fallback cursor? I would argue they should specify "auto" as fallback and let the browser decide whether the control is editable/selectable and display the default/text cursor depending on that, and not hardcode a value that works for their specific browser/platform and looks weird on others).

[FremyCompany]

Another interesting case I found while investigating the WantArrowCursor flag is that we do not show a text-beam cursor on already-selected text but the default arrow instead (presumably to indicate the user can right-click to open the context menu). I would rather have this behavior stay per-spec.

[frivoal]

Also, since what is considered editable might vary per platform (for example, an input type="color" might be a textbox in some browser, hence editable, and a button in another, hence not editable): what value should authors use if they want to specify a custom cursor on that element with a fallback cursor?

I suppose they could do input[type="color"]:read-write, so I do not the ability to express this with regular selectors and regular values is blocking.

However, the argument that we already have interoperability on auto looking like text over editable things is for me a convincing argument. If other browsers agree and want to preserve that, I'm ok with a spec edit.

Another interesting case I found while investigating the WantArrowCursor flag is that we do not show a text-beam cursor on already-selected text but the default arrow instead (presumably to indicate the user can right-click to open the context menu). I would rather have this behavior stay per-spec.

I am not sure who to cover that one.

I think it could be considered allowed under this part of the spec:

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.

but that feels a bit like a stretch. Any suggestion?

[FremyCompany]

[...] we do not show a text-beam cursor on already-selected text but the default arrow instead (presumably to indicate the user can right-click to open the context menu).

I think it could be considered allowed under this part of the spec:

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.

but that feels a bit like a stretch. Any suggestion?

Actually, this sounds good enough to me.

[hugoholgersson]

I'd like the spec to say that the auto-cursor for links is the hand 'pointer'. That's more intuitive?

Chrome 62, Safari 10 and Edge 15 show the hand as the auto-cursor for links already.

I suggest: "auto behaves as text over selectable text and as pointer over links"

[frivoal]

@hugoholgersson

We resolved against doing that (twice already), because

1. There are many such context-based cursor changes, and they are not fully interoperable (although some are more than others), and going through the full list seems like a never ending task with countless nuances and exceptions
2. This can be done using the UA stylesheet, and does not need to use the auto value

So the cursor should look like the hand pointer over links, but it should do so because of the UA stylesheet, not because that's what the auto value does.

Cases that cannot be done through the UA stylesheet are what auto should be about. text vs non-text falls under that, and so does selectable text vs non selectable text. Editable or not is a bit fuzzy, since it is selectable, but not trivially so, and there seems to be interop anyway.

[hugoholgersson]

Thanks for the feedback!

Argument I. Ask an intermediate web developer (or a web user): "What do you think is the automatic cursor when hovering links?" Most will probably answer "Ah, easy, it is the hand pointer!". I would like the spec's 'auto' to reflect this common conception of links. All browsers (except Firefox) have had this behavior so I'd like the spec+Firefox to adapt here (not all others).

1. There are many such context-based cursor changes, and they are not fully interoperable (although some are more than others), and going through the full list seems like a never ending task with countless nuances and exceptions

Argument II. I think links can be added to the list tough (it will not be a never ending task).

2. This can be done using the UA stylesheet, and does not need to use the auto value

Argument III. It can also be done using the 'auto' value. I would like to keep the UA stylesheet compact. (I think our current UA stylesheets already have too many exceptions. These long UA stylesheets confuse web developers).

Argument IV. Open cursor-auto-002 in Firefox. Isn't it confusing that an I-beam is shown? Displaying an I-beam gives users a hint about semantics: "this point can start a selection". But it cannot! Links cannot start selections (because they are draggables) so an I-beam might confuse regular users. That's why I think cursor-auto-002's expectation needs to change.

[FremyCompany]

@hugoholgersson Unfortunately, what you think is a behavior that is interoperable between Webkit-derived browsers and IE/Edge is in fact not as interoperable as you would believe. The code we have to support for overriding auto as pointer on links is fragile and it is our best interest right now to either leave it buggy as-is, or to remove it entirely.

https://wptest.center/#/yizue0 (Edge display a text-beam cursor on 22, Chrome a hand-pointer).

Right now auto in Edge is completely inconsistent and often acts as inherit which is totally against the spec. If I want to change this, I will however break the logic that currently makes cursor:auto display an hand-pointer on links in most cases. Fixing this would require way more work than this issue is worth, so if we have to keep this behavior, Edge will not get fixed anytime soon.

At this point the question is whether there is a sane-enough behavior that we all can implement that would get us rid of a bunch of terrible code (and then developers would have a predictable experience when using cursor, all browsers would react the same, and we make things better for our users) or we find out there is not and we stay different for a while longer.

We previously resolved we wanted to be interoperable and resolved on a particular solution, but it turns out the text of the spec did not state exactly what the discussion had us think it was, but except if we cannot get consensus on the updated text, I would rather not have us revert the previous decision.

Outside this real-implementer-life considerations, I have no idea why someone would manually set a { cursor: auto } and I am absolutely not worried this will ever be a problem. This code is broken today, and the proposed fixed would make it consistently broken so that authors can see and fix the issue independently of the browser they use to test their site.

On the other side, if as an author you ever wondered what cursor was being displayed on an element, you had absolutely no way of finding out. With the proposed text (and what Firefox implements) the computed style of an element will always return the value of the cursor that is being displayed, and not "auto" for every single element. Even when you get "auto", you know as an author this is not any random cursor but one of two specific ones. This, I think, is very valuable for authors.

[css-meeting-bot]

The Working Group just discussed auto cursor should behaves as default cursor except for text?, and agreed to the following resolutions:

• RESOLVED: Change the definition of cursor auto to look like text over selectable text in css UI 3
• RESOLVED: Add exception for editable text into L3 UI

The full IRC log of that discussion

<dael> Topic: auto cursor should behaves as default cursor except for text?
<dael> github: https://github.com//issues/1598
<dael> florian: We've already narrowed problem considerably. It's only about distinguishing things we can't in UA stylesheet. There's two things reopened. WE say one cursor over test, one over everything else. Wee should change that to be one over selectable text. That was in originally, seemed an unintentional omissions
<dael> fremy: I can give some background as to why this is useful. I fyou have text inside a buttonn you don't want the cursor to become a text cursor, but you don't want that. To me it seems straight forward and most browsers are doing this. I think that should be in the spec.
<dael> florian: I sort of have this in L4. In L4 I put an exception to not look like text cursor. I forgot the other things that imght make the text not selectable. [missed]
<dael> Rossen: What is the request?
<dael> florian: For a resolution to change the definition of the auto cursor to change on selectable text, not all text. I'll make edits.
<tantek> and I already +1 that here: https://github.com//issues/1598#issuecomment-335863545
<tantek> last week
<dael> Rossen: That would mean change of behavior...fremy your example. what would the change mean to you?
<dael> fremy: We are already doinng this in edge. I think all browsers also.
<dael> fremy: This is aligning spec with browsers.
<dael> dbaron: Were you going to get to the editable thing?
<dael> florian: I wanted that sep.
<dael> florian: proposed resolution: Change the definition of cursor auto to look like text over selectable text
<tantek> +1 https://github.com//issues/1598#issuecomment-335863545
<dael> Rossen: Objections?
<dael> RESOLVED: Change the definition of cursor auto to look like text over selectable text in css UI 3
<dael> florian: Second part is another thing where we may want to align to browseres, but it contridicts previous intention. In the general case browsers change to text cursor over editable, even if it's not next. This is doable in UA stylesheet, but we're interop in not doing that. There's reluctance to change, esp. on Chrome side. Do we want to change or grant an exception for this because we are interop?
<dael> Rossen: Opinions? Esp from Chrome?
<dael> robertknight_clo_: Do we have anyone from Chrome?
<dael> s/robertknight_clo_/rossen
<dael> Rossen: I guess there's no one from chrome
<dael> florian: Chrome seemed if other browsers commit to change and we push hard they'll do it. They prob don't want to be alone in this. I'd like to hear from Mozilla.
<dael> dbaron: I'm fine with having editable thing in spec. It's not 100% clear to me that read/write pseudo does the right thing here.
<dael> dbaron: I jut haven't thought through it. I'm okay with the editable exception.
<florian> tantek: test case: https://test.csswg.org/harness/test/css-ui-3_dev/single/cursor-auto-005/format/html5/
<tantek> +1 similar thoughts to dbaron
<tantek> thanks florian
<dael> fremy: I'm in favor too. It's interop i n all browsers. We can change, but I don't think we need to. I don't think author would expect it and changing something interop could cause problems. My opinion is we should make the change to make things easier for impl.
<dael> Rossen: I hear a lot in favor or don't mind.
<dael> Rossen: Objections to adding an exception into L3 UI?
<tantek> so we're saying auto should look like text over editable text?
<tantek> just trying to understand
<florian> tantek: yes
<dael> RESOLVED: Add exception for editable text into L3 UI
<florian> should -> must
<tantek> +1

[frivoal]

Relevant tests needing review here: web-platform-tests/wpt#7894