W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [css-ui-4] -webkit-user-select

From: Florian Rivoal <florian@rivoal.net>
Date: Thu, 18 Feb 2016 04:33:12 +0900
Message-Id: <585111E2-F959-4F93-96F2-9B425AFDAD3B@rivoal.net>
To: www-style list <www-style@w3.org>

> On Feb 6, 2016, at 14:28, Florian Rivoal <florian@rivoal.net> wrote:
> Hi,
> css-ui-4 specifies the user-select property. This property is widely used under its webkit prefixes, which is causing enough issues that both Edge (not IE11) and firefox (in nightlies) have decided to support it under the webkit prefix in addition to their own.

So on the call we've agreed to spec it, but left open the question of whether:

1. we should restrict the -webkit- syntax to only support the values which webkit supports
2. we should restrict the -webkit- syntax to only support the subset of values supported by webkit which are needed for web compat
3. we should require that browsers support the same values under -webkit- and unprefixed
4. we need not be so specific, and merely spec that the -webkit- prefix may be supported, without being explicit about the values

We also have the question of whether we define -webkit-user-select to be a shorthand of user-select, or whether we do not specify how the aliasing works.

I was actioned to find out what non-webkit browsers who support the webkit prefix do. Here are the results.

Both Firefox (nightlies / developer edition) and Edge (production version) support all the values they know about under both syntaxes, so they will respond to "-webkit-user-select: -moz-none" and to  "-webkit-user-select: element" respectively.

As for how they do the aliasing, Firefox appears to be treating -webkit-user-select as a shorthand for -moz-user-select, while Microsoft is using some subtly different aliasing mechanism:

With both Firefox and Edge you can find "-webkit-user-select" as an entry in the CSSStyleDeclaration returned by getComputedStyle() in addition to their own naming.

When querying the name of the property using "document.styleSheets[0].cssRules[0].style.item(0)", both return the canonical name, not the webkit name, even when the webkit name was specified by the author.

The only other way I can think of of observing the property name from JS is using -webkit-user-select as the specified value of transition-property, and using getComputedStyle() to query for that value. Here Firefox and Edge behave differently: Firefox returns the -webkit-user-select name if it was the one used (which is what you do if you treat it as a shorthand), while Edge always returns -ms-user-select, even if the -ms-user-select one was specified.

* I don't think it is particularly interesting to spec anything else than reality, so unless Firefox and IE actually plan to change their implementation, we should go with 3 or 4, because they're clearly not doing 1 or 2.

* Even though all browsers support all values (including non standard ones) under both syntaxes, I am not convinced there is any value in requiring that. We could go with 3, but I think the relaxed requirement of 4 is enough.

* I don't think it is necessary to harmonize the aliasing mechanism to that level of details, so I would prefer leaving that undefined. But if browser vendors think it is and are willing to change their implementation to match, I prefer siding with Firefox and using a shorthand mechanism, since that's something all browsers know how to do (and I know how to spec).

 - Florian
Received on Wednesday, 17 February 2016 19:33:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC