- From: Tom Wardrop <tom@tomwardrop.com>
- Date: Thu, 7 Mar 2013 10:43:42 +1000
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style@w3.org
- Message-ID: <CAOvmfajiXmbxV-=K2XD=2q10OvPvF2tu0D5SV4kTXswWFG-8-g@mail.gmail.com>
There's a discrepancy between how vendor prefixed properties were intended to be used, and how they're actually used. Is that not what we're trying to fix? The problems I'm trying to solve right now are: * Vendor prefixes are very verbose, and completely unnecessary when the syntax between a particular draft property is identical between vendors. * As a consequence of the former, developers don't always included the non-prefixed property, and don't always account for all vendor prefixes. > If the Web were full of unprefixed uses of the properties, implementations would have to maintain compatibility with the syntax and behavior. I don't see how this is any different to the current situation. Vendor prefixed properties are used on many production websites. Any change to those properties has the potential to break those websites. My suggestion does not introduce any new problems, nor does it come with any side-effects that vendor-prefixes (or draft properties in general) don't already possess. If using draft properties, prefixed or not, on a production website, you must be vigilante in ensuring those properties you're using remain compatible. This is the current situation, and would remain the same under my proposal. Given that, can anyone provide a reason not to adopt my proposal? Cheers, Tom On Tue, Mar 5, 2013 at 2:49 AM, L. David Baron <dbaron@dbaron.org> wrote: > On Monday 2013-03-04 20:56 +1000, Tom Wardrop wrote: > > 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. > > This doesn't solve the problem that vendor prefixes were originally > designed to solve, which is that the draft status of the properties > is such that the group is not yet ready to commit to being backwards > compatible with content using those properties. If the Web were > full of unprefixed uses of the properties, implementations would > have to maintain compatibility with the syntax and behavior. > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla http://www.mozilla.org/ 𝄂 >
Received on Thursday, 7 March 2013 00:44:09 UTC