1445571 - CSS cursor auto property

Status: RESOLVED DUPLICATE of bug 88688

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[davidj.martin]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180307142707

Steps to reproduce:

Construct a navigation bar using an unordered list with anchor elements in the list items. The CSS was set to cursor:auto for the anchor tags. This is over qualification as the property by default is auto.
<ul>
<li><a></a></li>
</ul>


Actual results:

Instead of the cursor rendering as the pointer (hand) it was rendered as an I bar for text editing.


Expected results:

Setting the CSS property to auto should have affected nothing and the browser should have rendered it automatically as it always does as a hand not an I bar.

Comment 1

[j.j.]

This is intended behaviour, the same in Google Chrome. See bug 88688.

Comment 2

[j.j.]

See also bug 847320

Comment 3

[davidj.martin]

How is this intended behavior?

If the default is auto then you overwrite the property with the same value the result should still be the same not a completely different result.

Because Google Chrome does it, doesn't mean it is the correct implementation of the property. This should be re assessed and corrected as replacing anything with its default property should not affect the original behavior only the children as is the case with absolute and relative. Which by the way in Firefox has the default value of relative position and setting the position to relative does not change the intended behavior!

Comment 4

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Adding a component for triage reasons until a clear decision will be taken on this.

Comment 5

[j.j.]

(In reply to davidj.martin from comment #3)
> Because Google Chrome does it, doesn't mean it is the correct implementation of the property.

Did you read bug 88688? David Baron resolved it as INVALID 2004-01-08. Google Chrome 1.0 was released 5 years later (2008-12-11).


(In reply to Ciprian Muresan [:cmuresan], Desktop Engineering QA, :steve from comment #4)
> Adding a component for triage reasons until a clear decision will be taken on this.

There was a decision 14 years ago in bug 88688, or missed I something new to consider?

Comment 6

[davidj.martin]

(In reply to j.j. from comment #5)
> (In reply to davidj.martin from comment #3)
> > Because Google Chrome does it, doesn't mean it is the correct implementation of the property.
> 
> Did you read bug 88688? David Baron resolved it as INVALID 2004-01-08.
> Google Chrome 1.0 was released 5 years later (2008-12-11).
> 
> 
> (In reply to Ciprian Muresan [:cmuresan], Desktop Engineering QA, :steve
> from comment #4)
> > Adding a component for triage reasons until a clear decision will be taken on this.
> 
> There was a decision 14 years ago in bug 88688, or missed I something new to
> consider?

Plain and simple replacing a value with the same value should not affect the behavior period. In this instance the cursor should still behave as it did before not different. 
Perhaps you missed my comment on the positioning property, seems that behaves like it should when replaced with the same value.
Because it was accepted 14 years ago does not simply stop the issue being corrected now, it is a simple bug fix when replaced with the same default value ignore the new value or do nothing.

Comment 7

[j.j.]

davidj, please note that I personally don't have any specific opinion on this issue, just referring to decisions in the past.

You may consider bringing this issue up to the www-style mailing list.
https://lists.w3.org/Archives/Public/www-style/

Make sure to search the archive for previous discussions.

Comment 8

[Anne (:annevk)]

It's not replacing it with the same value, you're overriding the UA stylesheet value for links. j.j. resolved this correctly. If you want different behavior here, you'll have to take it up with the CSS WG.