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

Sylvain... :-)

My comments regarding border-radius and ::selection are very different.
First the former has a wide user base, not the latter. Second, the
former is widely interoperable accross browsers while the latter's holes
can pose huge issues to colour- or constrast-blind people. Third, the
current situation behind ::selection is caused by call for implem policy
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. 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.

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?

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?-)

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.

</Daniel>

Received on Sunday, 16 May 2010 15:08:52 UTC