W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Possible Vendor Prefix Solution

From: Tom Wardrop <tom@tomwardrop.com>
Date: Mon, 4 Mar 2013 20:56:04 +1000
Message-ID: <CAOvmfagB2C291qPOrU9_hQJLCc-3YUGLfcd92bGY7bctpcvDCg@mail.gmail.com>
To: www-style@w3.org
Hey Everyone,

I've been reading about the problems with vendor prefixing, but also about
the problem they solve and hence why we can't just get rid of them. There
are two main problems. There's the problem the prefixing aims to solve, and
the problem(s) they create.

The aim of vendor prefixes is to allow browser vendors to get new features
out before they're fully standardised, without worrying about conflicting
implementations, like syntactic or behavioural differences.

The problem vendor prefixes currently create is verbosity. Often, all the
vendor-prefixed properties are consistant and stable, so it's obviously
frustrating having to constantly account for all these vendor prefixes for
many years down the line. Let's remember that not everyone will have the
latest browser version, so there's incentive for web developers to keep
adding vendor prefixed properties long after they've been standardised, as
older browsers versions won't support the non-prefixed property.

The solution I propose is to keep vendor prefixes as they are, but to
encourage browser vendors to implement draft properties using the standard
property name as well. To use Firefox as my example browser, Firefox should
support both -moz-box-sizing and box-sizing. One should simply be an alias
of the other.

How does this help? If two browsers have different implementations of
box-sizing for example; either a different syntax, or perhaps a particular
browser is buggy and you'd like to set the property to the default value
for that particular browser, then you can simply redeclare the property
using the vendor-specific property name, e.g.

.mystyle {
    box-sizing: border-box;
    -moz-box-sizing: bordered-box; /* Example of different syntax, so we
override */

This way, you don't need to know every browser prefix, you only need to
care about the browsers that don't behave, and so you only need to declare
vendor-specific properties when they're actually needed.

We're taking the current idiom of explicitly opting in to new draft
properties, and making the opt-in implicit. Vendor prefixes should be used
by exception to target a specific browsers bugged or quirky implementation.

Using the above style example, once the spec that includes box-sizing is
finalised, then new version of Firefox would ignore the sub-sequent

Would this not solve the majority of problems with vendor prefixing? Look
forward to the feedback. Hopefully I've considered everything.

Received on Monday, 4 March 2013 10:56:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:27 UTC