Re: Selectors, vendor prefixes (again...) and IE9 and Opera and WebKit

From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
> On 5/14/10 11:33 AM, François REMY wrote:
>> I don't care.
>
> That's very selfish of you.
>> As long as the two essential properties
>> are supported (color & background-color)
>
> They're not supported interoperably across the browsers that implement 
> unprefixes ::selection (in particular, not supported the same way in Opera 
> and Webkit; I don't have an IE preview on hand to test).

If it's true, I may reconsider the whole point. But
small tests I performed seemed to show that the
implementation were reliable enough for simple
uses-cases, at least.

>> as it's sufficiently interoperable for my own
>> use of the property (and, more globaly, to the vast
>> majority of all uses-cases of this pseudo-class)
>
> Why bother with specs at all then?  The "common" use case (as long as you 
> don't try to actually do anything interesting) is already interoperable 
> for most things; let's all pack up and go home.

Well, it's not the point I'm defending here. The point is that :
(a) The syntax of ::selection is not likely to change
(b) It's currently already possible to define a "minimal set"
      of things every UA support, and which covers a great part
      of the uses-cases we found for the property
(c) Websites are already using the feature

This doesn't mean no standard or consensus should be found.
It should.

This mean the feature is mature enough to *allow* the UAs that
feels the feature is stable and interoperable enough in their
browser to accept the unprefixed version of the selector.

>> Well, in such case it's interesting. But why would
>> you rename the ::selection pseudo class ?
>
> Because what you implement is buggy and idiosyncratic and doesn't match 
> what other browsers likely implement?

Well, I'm not asking why you would like to have ::selection
not recognized by UA's. I'm speaking about "why would you
like that the (final) version of the selector has another name
than ::selection ?".

>> As a web developer, I've the feeling that no property
>> should stay too long in a prefixed version, since
>> it's pretty difficult to use the feature then, and,
>> even worse, it occults the feature for every UA
>> for which we didn't include the prefixed version.
>
> But the point of prefixed versions is that if it's prefixed then you're 
> free to change it to fix bugs or align with other browsers.  If everyone 
> shipped different non-interoperable broken crap unprefixed all the time 
> (as you seem to want them to do), you couldn't use the properties safely 
> anyway without long lists of things to avoid, _and_ it would be more 
> likely that sites would come to depend on a particular behavior, making a 
> sane standard that much harder.

Well it's not what I want to. Unprefixed version should only
be accepted when the property is stable enough to be used
(at least for the most part) on the web.

>> Now this property has been used on the web,
>> I don't think it's desirable to break the feature
>> they're relying on.
>
> This is EXACTLY why unprefixed broken stuff should not ship.  Thank you 
> for making my case.
>
> -Boris

Received on Friday, 14 May 2010 16:04:59 UTC