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

Re: vendor prefixes: co-cascading

From: David Singer <singer@apple.com>
Date: Thu, 17 Nov 2011 15:22:14 -0800
Cc: Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org list" <www-style@w3.org>
Message-id: <82899B63-64A7-497C-810E-EA40BCB24407@apple.com>
To: Brian Manthos <brianman@microsoft.com>

On Nov 17, 2011, at 15:04 , Brian Manthos wrote:

> And doing that with CSS specs, and then multiplying *that* by the vendor-product-version-matrix-size is better?

I am suggesting that rather than seeing

all over our specs, it might be better to see

where the 'this' feature has changed.

This would be painful for the spec. writers (every tag would need to say what its current 'experimental' prefix is, and that would change if the feature changed), but it's easy for
a) implementers: recognize the tag(s) that you saw in the spec(s) you implement
b) authors: write the tag in the specification you worked from

The current mess is easy for the spec. writers but hard for implementers and users, which (IMHO) may not be the right optimization.

> -Brian
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com] 
> Sent: Thursday, November 17, 2011 2:15 PM
> To: Brian Manthos
> Cc: Alex Mogilevsky; www-style@w3.org list
> Subject: Re: vendor prefixes: co-cascading
> I guess they could, of course; they don't, maybe because if we multiply N vendors by M versions we end up with O which is oh-much-too-large.
> whereas multiplying M by 1 is more palatable.
> just guessing...
> On Nov 17, 2011, at 12:45 , Brian Manthos wrote:
>>> At the moment, vendors can't easily version, and nor can we, and when vendors all do the same
>> Why can't they?
>> Why is "-mozilla27-simple" not viable if "-draft27-simple" is?
> David Singer
> Multimedia and Software Standards, Apple Inc.

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 17 November 2011 23:23:12 UTC

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