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

On Wed, 17 Feb 2016 20:33:12 +0100, Florian Rivoal <florian@rivoal.net>  
wrote:

>
>> 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.
>
> Conclusion:
> * 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).

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

Anything that browsers have to support will typically eventually be  
refactored or hit a Web compat bug, and what browser developers then  
typically do is turn to the spec and see if it says what to do. If we do 4  
we miss the opportunity to get closer to interop when that happens, since  
instead of implementing what the spec requires the browser developer will  
either reverse engineer some other browser and try to match that or do  
whatever that will fix the broken page, and we don't really get closer to  
interop and the long-term cost and pain persists, and the spec wasn't  
useful.

If the goal is interop, then clearly leaving it undefined how it should  
work doesn't really help reach the goal.

-- 
Simon Pieters
Opera Software

Received on Thursday, 10 March 2016 11:02:21 UTC