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

> From: Daniel Glazman [mailto:daniel.glazman@disruptive-innovations.com]
> Sent: Sunday, May 16, 2010 8:08 AM


> 
> Sylvain... :-)
> 
> My comments regarding border-radius and ::selection are very different.
> First the former has a wide user base, not the latter. 

That something does not yet have a user base is no reason to make it 
costlier to use. Forcing authors to add a new ruleset with every new 
browser that adds support for ::selection seems unlikely to help with 
its adoption.

> Second, the former is widely interoperable accross browsers 

I must beg to differ. That may be true for the most basic testcases. 
But it doesn't take much effort to find glaring differences. I suggest 
you go back through Brian Manthos' feedback over the past few months.

Or simply try non-solid borders across browsers, for one.

> while the latter's holes can pose huge issues to colour- or constrast-blind 
> people. 

I fail to see how adding -ms will plug any of these holes.
Discussing them to standardize of the feature is the proper course
of action, however. Demanding that vendors reinstate prefixes until 
that is done is not helpful, assuming it's even necessary.

> Third, the current situation behind ::selection is caused by call for implem
> policy

Can you elaborate on what that means ? Does the call for implementation policy 
require a CR feature to be re-prefixed if it's pulled ? Even if such policy is 
explicitly stated, there seems to be disagreement as to its desirability.
And it is clearly ignored in practice. 

> while the burden on web authors' shoulders using border-radius is
> caused by the time the CSS WG sometimes needs to move a stable feature from
> stable proposal to CR. 

That is already a significant burden for any new CSS feature. Requiring some
of these features to move back to a prefixed version *after* they have shipped 
without a prefix increases that burden yet again.

> And I don't forget that even all up-to-date
> versions of major browsers implement an unprefixed version of border
> radius, most web authors will still write stylesheets including the
> prefixed version to cope with legacy browser versions :-( From a web
> author's point of view, it's hell. With my editor implementor's hat on,
> it's hell.

But you're suggesting we make that hell even longer. Because if a feature 
might have to go back to its prefixed incarnation, authors are better 
off keeping prefixed declarations until a module is REC. Which, for today's 
author is practically synonymous with 'forever'. 

> CR means, for us, call for implementation. But a CR is not a PR nor a
> REC! A CR _can_ go back to WD. So We have a serious issue here: if we
> call for implementations, we end up with shipped implementations and
> then we cannot go back to vendor prefixes since "it's shipped and we
> have users". And the shipped features can have serious holes,
> discovered
> _in the spec_ after that CR's release. But we still need unprefixed
> implementations for tests. Superb vicious circle, isn't it?

Which is why I am baffled that you'd suggest promoting the WD-to-CR-to-WD 
yo-yo of specs to runtime status by requiring that certain features go 
from prefix to unprefixed back to prefixed.

How does that improve on the status quo ? Who does that help ?

> If we can come up with an harmonized specification for ::selection in
> the coming weeks, let's do it so we don't need vendor prefixes again.
> If we cannot come up rapidly with such an harmonization, what's your
> preference here? Let different versions of ::selection in the wild or
> vendor prefixes? Charybdis or Scylla? Cheese or dessert?-)

Let us try it. But then where does it go ? Are you suggesting taking
CSS3 Selectors back to WD ? 

As to what I want to do now: 
a) you seem to be of the opinion that this feature has very limited uptake.
You even referred to it as 'hyper-minor' compared to other things authors 
want, which is a relief. I think you're right.
b) as Anne and you noted, vendor prefixes here mean repeating entire rulesets.
That is a lot of author pain for a relatively minor and unused feature.
c) the accessibility issues you raise will not be fixed by adding a prefix.
d) there are, to my knowledge, no formal rules on what we should do.
e) existing implementations don't give us a clear answer either.

So I'd rather improve the interoperability of our implementation as much as
we can during the rest of this product cycle, and aim to ship without a 
prefix. Such a course of action seems far preferable for authors and our 
product for this particular feature. We'll reassess as progress is being made.

> 
> At least one conclusion can be drawn from these issues: our vendor
> prefix policy and its relation to CR needs to be discussed in details.

There is much to learn from the past few months.

Take Backgrounds & Borders, which went CR late last year. Shortly afterwards, 
Opera 10.5 was released with a partial unprefixed implementation. 
Their background shorthand, for instance, does not include the new longhand 
properties, while for border-image only the shorthand is supported.

Is it OK for vendors to pick and choose among a set of related properties,
implementing either longhands or shorthands ? I would think such partial 
implementations would be pretty frustrating for authors, especially if
unprefixed.

But even if Opera had implemented all CSS3 Background & Borders properties fully 
per the CR they'd still have a problem today as the module has gone back to WD 
and both background-clip and the background shorthand have been updated. So pretty 
soon Opera 10.5x may well ignore valid unprefixed declarations that a future IE9 
Preview or Beta might handle fine. (We're not going to prefix the background shorthand; 
sorry). Hopefully Opera and IE9 will be compatible by the time the latter ships.

This is the kind of messy reality we have. We all converge, eventually, but it takes
time. To the extent this process needs fixing, that won't happen by wagging an indignant 
self-righteous finger at the usual suspect when they miss a prefix on a cool but rarely 
used feature other browsers already support as such.

Received on Sunday, 16 May 2010 16:32:20 UTC