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

On Thu, 17 Mar 2016 07:21:58 +0100, Florian Rivoal <florian@rivoal.net>  
wrote:

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

Yes.

> but in this case we know that the vendors each went their own way about  
> supporting this, and that their aliasing mechanism is different.

Right. This is bad, and it's what happens when there isn't a spec, or if  
there is but it leaves things undefined.

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

There was no intent from any vendor to rewrite their HTML parsers before  
the HTML parser specification was written, either, but they did.

> I don't see the point in specifying something that isn't what browsers  
> actually do,

I explained the point in the part you didn't quote:

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

i.e. the point is getting interop (eventually), to reduce long-term cost  
of compat problems and reverse engineering.


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

Nobody has suggested doing that.

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

Citation needed? Also this isn't the only property that is aliased in  
browsers.

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

This WFM.

CSSOM serialization might need some tweaks to avoid preferring serializing  
as a vendor-prefixed property (because it is a "shorthand"). And this is  
another reason why it's useful to have a precise spec; we can identify and  
fix problems elsewhere before bad behavior is impossible to change because  
of Web compat.

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

OK, fair enough.

FWIW, -webkit-user-select is used on 72.4021% of page views, so I'd expect  
it will stick around forever.
https://www.chromestatus.com/metrics/css/timeline/popularity/339

It seems writing-mode and -webkit-writing-mode are not aliases in Blink:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4009

But columns and -webkit-columns are:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4010

I can investigate more and file bugs for Blink.

-- 
Simon Pieters
Opera Software

Received on Thursday, 17 March 2016 19:44:07 UTC