W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: vendor prefixes: co-cascading

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 18 Nov 2011 11:38:58 +0200
Message-ID: <CAJQvAudtM1mAgWjzrCbK3sYELcs0w0PyzuihU5mUhyrGR=OfKg@mail.gmail.com>
To: www-style@w3.org
On Thu, Nov 17, 2011 at 9:36 PM, David Singer <singer@apple.com> wrote:
> How about prefixes that are vendor-indepdendent but spec-version-dependent?
>
> -draft1-font-weight: itsy-bitsy
> and then someone in CSS realizes that that's not a good word, the spec. changes, and so now
> -draft2-font-weight: flimsy
> and so on.  Ie. you change the X in 'draftX' whenever there is an incompatible change to the spec.  and there will always be an N such that -draftN-something is the same as -something.

This would either not be necessary or be bad for competition in the
form of creating a barrier to the entry to the market for new browser
engines.

If by the time draft #2 comes along there's so much content using
-draft1-font-weight: itsy-bitsy that vendors who have already
implemented it don't want to remove support for it, a new entrant to
the market might have to support it, too, in order to be able to
render the Web the way incumbents do. This would create a situation
similar to the one described as bad in
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
(though in the CSS draft version prefix case it would be slightly
better if the after the new entrant to the market has figured out
which -draft prefixes they need to support the new entrant could use
public old draft docs as documentation instead of having to reverse
engineer everything). Since one of the purposes of standards is to
avoid barriers to the entry to the market, I think it doesn't make
sense for standardization group to set up a policy that could very
well create such barriers.

On the other hand, if when draft #2 comes along vendors who've already
implemented the -draft1 prefix are willing to remove the
implementation, property declarations of the form -draft1-font-weight:
itsy-bitsy start getting ignored. In that case, the prefix was
unnecessary to begin with, because font-weight: itsy-bitsy would get
ignored in implementations that supported font-weight: flimsy instead
thanks to the CSS parsing rules if itsy-bitsy no longer counts as a
recognized keyword. Thus, if vendors are willing to drop support for
old drafts, grammar-incompatible changes are already taken care of by
the mechanisms designed into the CSS parsing rules.

I think changes that don't change the grammar but change the semantics
(e.g. changing what percentages refer to) simply should not be made
after the feature has been adopted widely enough that the change would
break too much existing content. Maybe such a constraint would leave
an occasional unideal feature in the standard but it's better than
keeping the standard pure while a parallel prefixed less well
documented group of de facto standards grows up on the side.

Evolving features in place is quite possible without versioning and
without creating barriers to entry by proliferating the number of
historical variants that need to be supported in order to render the
Web. For example, the HTML canvas API has been tweaked many, many
times without vendor prefixes. Browsers don't implement multiple
snapshots of the spec. They just try to implement the latest whenever
they refresh their implementation. This works for the incumbents,
because changes that'd break too much existing uses of canvas aren't
made. This works for entrants to the market, since they don't need to
implement multiple legacy snapshots--just the latest. The design of
the canvas API is known not to be ideal, but I think the current
situation is still better than having 4 prefixed canvas APIs while
waiting for the perfect standard.

(BTW, prefixing has allowed unfortunate behavior in the canvas case. I
remember an Opera rep expressing disapproval when Mozilla added some
prefixed canvas API extensions without first circulating the idea in
the relevant WG. If prefixes weren't a card one can play to make
unilateral changes OK, it would be easier to make it the norm to
circulate feature evolution ideas in the WGs before moving to
implementing or even shipping them.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Friday, 18 November 2011 09:39:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT