RE: Selectors, vendor prefixes (again...) and IE9

Daniel,

I am confused. Very confused.

Two months ago, you stated here [1] that you wanted 
the following to "never happen again":

   -moz-border-radius: 5px;
   -webkit-border-radius: 5px;
   -o-border-radius: 5px;
   -ms-border-radius: 5px;
   border-radius: 5px;

But now, you are implicitly asking for this:

  #foo::-moz-selection, 
  #foo::-ms-selection, 
  #foo::-webkit-selection,
  #foo::-o-selection,
  #foo::selection {
	....
  } 

So either these two positions are compatible and I'd like to
understand how. Or you've changed your mind and I'd like to
understand why. 

Also two months ago, you were very enthusiastic about our
implementing ::selection [2]. It was as unprefixed then as 
it is now. What happened ? Is it because of the recent IE 
Mobile incident ? As you are the one who informed the mailing
list that this was pulled [3] the same day the issue was raised, 
I trust a perceived lack of caring is not the concern here ?

Regarding that particular issue, I think the proper course of
action is to try and standardize a property that is already 
very widespread on the web. May I suggest adding this to our 
agenda ?

Now, as to ::selection.

Since this selector has long ago been pulled out of the spec 
and the current PR/REC does not include it, it does seem reasonable
that a new implementation should prefix it.

However satisfying or obvious that may appear from a strict process 
viewpoint, authors should come first. At this stage, two of three 
shipping implementations support the non-prefixed version of this 
feature. With all major browsers now implementing ::selection in 
one form or another, we know this feature *needs* standardization. 
Addressing this should be the first priority of our WG. I thus also 
suggest adding this work to our agenda.

Then comes the overall vendor prefix policy. 

It would *really* help if it were clearly and extensively specified.
The current prose [5][6] is terse and only offers a few simple examples
of prefixed property names. It does not say anything about keywords, 
it does not mention selectors, it does not cover new value formats, 
it does not say what should happen when a spec goes from CR back 
to WD, or what should happen when features are dropped. Policy is 
*much* easier to follow when guesswork is not involved.

Take, for instance, Tab's recent Chromium submission for #rrggbbaa:
https://bugs.webkit.org/show_bug.cgi?id=39140. There is no standard 
spec for this yet but let's assume we add it to CSS3 Color tomorrow. 
Where should the prefix go ? It can't really go in the value. Should 
Chromium create a prefixed version of every single property that 
takes <color> for the sole purpose of using this new notation until 
CSS3 Color goes CR ? That seems rather suboptimal for implementors 
and authors alike. And after CR, then what ? They'd support the 
new notation unprefixed until Color goes back to WD, and then what 
happens ? The answer seems to depend on whether this specific feature 
is being removed (or maybe even a breaking edit ?)

And thus we get to your statement that:
"A feature that is dropped should get its prefixes back." 

Fair enough. But then CR is now effectively meaningless to authors. 
Until a module reaches REC, they should drag the prefixed version 
of every new feature they use in their stylesheet or their page 
may break when said feature gets pulled following a not-so-uncommon 
trip back WD. Granted, feature removal may be rare but as they can't 
easily predict whether or when it will happen or which feature will 
be affected, what else can they reasonably do to future-proof their 
stylesheets ? 

Which, again, seems to conflict with your previous aim to save 
authors a lot of error-prone repetitions. It also means that 
authors must write more code - CSS and JS, too - to protect 
themselves not just from the cross-browser interop issues 
inherent to new experimental features, but from interop issues 
across releases of the same exact browser as well *because the 
WG might change its mind and pull a feature*. This, imo, is neither 
desirable nor sustainable at any scale. And if it is your position 
then I believe you will fail to reach agreement; and I believe you 
should fail. Such instability is in no one's interest. This is not 
what authors or implementors expect from a standard process. We
must do better.

To conclude, I don't want to sound like I'm picking on you, or trying
to wiggle out of my obligations to this WG, our users and web authors.
I'm ready, able and willing to change this specific feature. 
This *is* a preview build, after all.

But you do make it sound like we have a coherent, clear and complete
set of rules to follow, and thus that our 'violation' and its remedy 
are self-evident. 

And there is, I think, the disagreement: both existing implementations 
and the opinions of browser vendors reps on this thread indicate we do 
not in fact have such rules or consensus.

Until the WG does establish clear rules that browser vendors *and* authors
agree to be beneficial, I have no straight and easy answer for you here. 
I am not willing to make authors deal with more seemingly arbitrary and 
confusing interop issues than they already have to handle. Of all the 
vendors here I probably have to be the most careful about adding to their 
already significant burden so I *really* want to do the right thing. 

But right now, I can't tell what that is in all cases, nor can I clearly 
explain why adding a prefix is the best thing to do for this feature and
this release of our browser. Thus I hope we can work together to establish 
a clear process that makes authors' lives easier and allows browser vendors 
to get valuable implementation experience.

[1] http://lists.w3.org/Archives/Public/www-style/2010Mar/0026.html
[2] http://twitter.com/glazou/status/10579348820
[3] http://lists.w3.org/Archives/Public/www-style/2010May/0180.html
[4] http://lists.w3.org/Archives/Public/www-style/2010May/0271.html
[5] http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords
[6] http://www.w3.org/TR/css3-syntax/#vendor-specific





> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Daniel Glazman
> Sent: Friday, May 14, 2010 2:27 AM
> To: www-style@w3.org
> Subject: Selectors, vendor prefixes (again...) and IE9
> 
> IE9 implements all of CSS 3 Selectors and is said to pass 100%
> of the Selectors Test Suite [1]. Mucho mucho congrats to the IE9 Team.
> 
> But it also implements ::selection, a pseudo-element originally
> in the first drafts of Selectors but that was later removed [2] because
> its difficult specification was putting the whole thing at risk.
> 
> That means that at this time, ::selection is NOT standard,
> that the Microsoft spec behind ::selection is definitely an interesting
> contribution to the future standardization debate but it's also
> potentially NOT the final specification for that feature. In other
> terms, that ::selection should really be a ::-ms-selection until the
> CSS Working Group reaches consensus on that. On a side note, and unless
> I missed a message, the spec for that implementation by Microsoft of
> ::selection was not submitted to the CSS Working Group for discussion.
> 
> [1]
> http://blogs.msdn.com/ie/archive/2010/05/13/the-css-corner-css3-
> selectors.aspx
> [2] http://www.w3.org/TR/css3-selectors/#selection
> 
> </Daniel>
> --
> W3C CSS WG, Co-chairman
> 
>

Received on Saturday, 15 May 2010 22:24:43 UTC