- From: Florian Rivoal <florianr@opera.com>
- Date: Tue, 21 Feb 2012 13:30:24 +0100
- To: www-style@w3.org
On Mon, 20 Feb 2012 20:39:09 +0100, David Singer <singer@apple.com> wrote: > I do wonder whether it would help us, and the web community, if we > differentiated more clearly between > > A) experimental features that vendors introduce, that are truly > vendor-specific > and > B) 'early' (before spec. stability) implementations of specifications > that are in process at the W3C. I welcome the open-minded discussion, but I am not really enthusiastic about this proposal, for a few reasons. 1) -csswg- prefixed implementations share the same prefix, even if they behave quite differently due to bugs or different understanding of the spec, losing one of the advantages of the current prefix scheme 2) once we get a few inter-operable implementation on the same prefix, dropping that prefix will be very hard. See X- mails headers for evidence. 3) I suspect we mean different things by vendor-specific. For me, vendor specific or proprietary features are things that are only meant to be found in style-sheets bundled with the browser, or in a walled garden, or similar. Things that are invented/introduced by a browser, but meant to be used in web sites delivered over the regular open Internet may be experimental, but they cannot be vendor specific due to how the web works. If another UA than the one for which it was developed may run into it while being used normally (ie: trying to open mozilla's UI files in Opera doesn't count, browsing a site developed for the iphone does), then it is a generic feature. For example, we don't consider the building blocks of Opera Reader[1] proprietary. We certainly hope to get a competitive advantage by doing this earlier and better than others, but we recognize that if successful, this can will inevitably become a generic an enhancement to the open web platform, and have made sure that the relevant css extensions are proposed to the WG (by including it in gcpm drafts). Using a different prefix for things that are truly proprietary to make it clear to authors that these are not meant to be used on websites could be useful, but this does not apply to things that are meant to be used on websites, even when you don't expect the competition to support it. So here is what I would propose instead. I) use an -internal- or -vendor-internal- or something like that for things that are not meant to be found on servers serving content to arbitrary UAs. II) When introducing something new, support it from the start both vendor-prefixed and unprefixed, with the two behaving as aliases. Authors can and should use the unprefixed version, unless they need to work around browser differences (intentional or not) in which case they can use the prefix. Any such feature should be proposed to the WG with a draft specification, preferably before launch, but in anycase as soon as possible. - Florian [1] http://people.opera.com/howcome/2011/reader/
Received on Tuesday, 21 February 2012 12:30:56 UTC