Re: vendor prefix properties diverging from official properties

On Wed, Feb 24, 2010 at 7:15 PM, Zack Weinberg <zweinberg@mozilla.com> wrote:
> I think divergence in behavior between -<vendor>-<property> and
> the unprefixed <property> is a terrible idea.  From the implementor
> side, we want the vendor-prefix name to be a trivial alias for the
> unprefixed name.  From the Web author side, they want to write the
> unprefixed property and its value, then copy and paste it for every
> vendor they care about, add the prefixes, and be done -- especially,
> not have to worry about one of them doing something slightly different
> than the others.

Somewhat tangential, but this relates to something I've thought about
before.  If what you say is the case, why don't we make authors' lives
easier by giving a shared syntax for draft properties?  So instead of
-webkit-border-radius, -moz-border-radius, -o-border-radius, and
-ms-border-radius all saying the same thing, instead say
draft-border-radius.  This would have several benefits:

1) Less typing and repetition for authors.

2) If one browser implements a draft property, then a while later
another one does, authors don't have to update their pages to work
well with the new one too.  This will give greater immediate benefits
to vendors who implement draft properties that another vendor has
already implemented, and it will also help out minority browsers that
authors might not think of at all.

3) It will reduce author confusion between draft properties and vendor
extensions.  I don't speak to many authors who aren't standards
junkies, but a while ago I spoke to one who was under the impression
that -moz-border-radius and -webkit-border-radius were non-standard,
because of the prefixes.  If it were draft-border-radius, it could
also be arranged so that it validates (possibly with a warning), which
no vendor-prefixed property does.

If syntax in a draft changes incompatibly and there are already
released implementations, the prefix could be changed to "draft2", and
so on as needed.  Upon reaching the appropriate level (CR?), the
draft- prefixes would all be dropped.  Authors should be encouraged to
use draft properties so they can provide feedback, but
"draft-border-radius: foo; border-radius: foo" should be discouraged
before the property is finalized, in case it changes.  Consequently,
UAs should be encouraged to support draft- properties for a long time,
if not indefinitely, so as not to punish authors who use draft
features correctly.

What does everyone else think of this?

Received on Friday, 26 February 2010 01:07:44 UTC