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

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

From: Florian Rivoal <florian@rivoal.net>
Date: Thu, 17 Mar 2016 15:21:58 +0900
Cc: www-style list <www-style@w3.org>, "miket@mozilla.com" <miket@mozilla.com>
Message-Id: <BEE35ED3-1C92-426D-9B44-70C7B06A39C6@rivoal.net>
To: Simon Pieters <simonp@opera.com>

>> 
>> 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
>> 
> 
> (This was discussed in the telecon yesterday and I didn't speak up in the call both because I had my son on my lap and I needed a night's sleep to articulate my thoughts here.)
> 
> I think I prefer 3 over 4, and saying that aliasing is done using a shorthand, because that is simple and *testable* and something that we can reach interop on over time, even though there isn't an immediate interest in tweaking this particular feature in browser engines at this time. Leaving it undefined means it's impossible to test.

Right. Going with a specific definition would make things more robust and testable, which in general is a good thing, but in this case we know that the vendors each went their own way about supporting this, and that their aliasing mechanism is different. The differences are subtle, but they're there, and there's as far as I can tell no intent from either vendor to adjust the way they do aliasing.

I don't see the point in specifying something that isn't what browsers actually do, and I am not sure there's much value in trying to pin down a definition of aliasing that is sufficiently vague to allow for the existing aliasing strategy of all browsers while ruling out whacky approaches.

Besides, usage of this property is generally sufficiently simple and non scripted that the differences in aliasing mechanisms don't affect compat with real sites.

Having spent quite a bit of time looking at different aliasing strategies, if we had to pin it down, I'd prefer to go with "-webkit-user-select is a shorthand of user-select, which accepts the same values". This is sane, match what firefox does, and by building on existing mechanisms fully defines how this works, all the way to obscure corners of the OM. But it's not quite what Microsoft does, and they've stated they had no interest in tweaking their aliasing system.

I also haven't recently looked at how Blink and Webkit (and Servo, and...) deal with aliasing, to know that prescription would require them to change how they handle aliasing.

In other words, show me consensus among vendors that they're willing to adjust the aliasing mechanism to match the spec, and I'll gladly write a tighter spec. Until then "Option 4" sounds more practical.

 - Florian
Received on Thursday, 17 March 2016 06:22:43 UTC

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