W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-ui-3] handling unsupported cursor values

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Fri, 19 Jun 2015 17:26:09 -0700
Message-ID: <CAEV2_WYOktxeaPOdBNEsMhp=B=XM0PEfoxCddbW696JGpAVJ4A@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
On Wed, Jun 17, 2015 at 5:45 AM, Florian Rivoal <florian@rivoal.net> wrote:
> I've been writing tests about css-ui-3's cursor, which made me review the spec prose closer than before.
>
> The spec contains this sentence:
>
>   "The UA may treat unsupported values as auto.
>    E.g. on platforms that do not have a concept
>    of a context-menu cursor, the UA may render
>    default or whatever is appropriate."
>
>
> I think this is bad:

I cannot recall the use-cases or any reasons why I put this text in.


> a- as a general error handling mechanism in css, when you don't support a value, you should fail to parse it, so that authors can use the cascade for fallbacks.

Agreed. This is the predictable mechanism that authors can use if necessary.


> b- "whatever is appropriate" is not something the UA can determine in this case. The only thing it know about the author's intent is that they want a context-menu cursor, and possibly which fallbacks they want if this value is not supported.

There are no fallbacks for the keywords - *a* keyword is a final
fallback for the optional list of cursor images.

However, as you pointed out in a- authors can use the cascade for fallbacks.


> c- regardless of whether the platform has a concept of a context menu, my web app may have one. I don't want the browser to second-guess what I want based on OS behavior.

That seems reasonable also.


> I think we should either simply delete this sentence so that normal error handling applies, or if we want to be explicit (as we've been with outline-color), write this:
>
>   "The UA must reject unsupported values at parse-time."

I'm fine with just deleting unless you see a specific need for
explicit language for this property.

Thanks for the catch and heads-up!

Tantek
Received on Saturday, 20 June 2015 00:27:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC