W3C home > Mailing lists > Public > www-tag@w3.org > May 2012

Re: CSS vendor extension issues

From: Linss, Peter <peter.linss@hp.com>
Date: Tue, 15 May 2012 19:09:49 +0100
To: Larry Masinter <masinter@adobe.com>
CC: Kingsley Idehen <kidehen@openlinksw.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <10A8B167-F9C7-4584-9BE6-BFEBC6479339@hp.com>

On Apr 27, 2012, at 8:29 AM, Larry Masinter wrote:

> OK, so there wasn't an agreed on transition plan --  http://wiki.csswg.org/spec/vendor-prefixes is very tentative and I don't think the plan in it works in the use case we have, where a feature has been deployed widely enough that it is de-facto desirable
> If the browsers that knew the unprefixed versions implemented ; the transition plan requires a "flag day" where everyone switches.
> Of the rules:
> If you are implementing a feature which is only defined in a Working Draft (WD, including Last Call LCWD and Editorís Draft ED), your implementation:
>> SHOULD (per CSS-snapshot-2010) use a vendor-specific prefix for the implementation of the feature 
> I'm with Tantek, MUST would be better.

The actual text in the snapshot is:
"The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features" [1]

There is no SHOULD in the text. One could argue that the 'recommends' is a bit weak, but in fact, all of CSS is a 'recommendation'. I will though, have that changed to 'requires' as it's more explicit.

>> MUST NOT support an unprefixed version of the feature
> - This is the bad part. Content-providers can't transition easily to unprefixed as long as there are deployed browsers that followed this rule, which would be likely.   
> I think it would be better to encourage vendors to support both prefixed and unprefixed versions, and let content creators decide whether they really want to specifically call out this particular vendor's issue, or bet that the standard winds up to be compatible enough.

The CSS cascade and forward compatible parsing rules already allow for the transition to the standard version, i.e.:
p {
  -moz-opacity: 0.5;
  -webkit-opacity: 50%;
  opacity: 0.5;

A WebKit or Gecko browser that doesn't understand 'opacity' will accept the appropriate prefixed opacity property and ignore the others.
A browser that supports only the standard version will ignore the prefixed versions.
A browser that understands both will have the prefixed version overridden by the standard version.

In practice, browser vendors do continue to support the prefixed version for one or two releases after a property goes un-prefixed. However, the longer they support the prefixed version, the less pressure there is on web authors to convert their stylesheets to the standard.

>> MUST NOT support a prefix specific to a third party for the feature
> Why is this MUST NOT? What problem does avoiding this solve? You shouldn't support someone else's vendor prefix unless you match their behavior. If you do, what's wrong with it?

In principle, it would be OK so long as the other vendor is never going to change the behavior of their prefixed version (which they often do), and you match their behavior, bug for bug in all edge and corner cases. 

When the first vendor changes their behavior on a release schedule that you don't match, the authors will wind up in a world where they can't target Opera's bugs independently of WebKit's bugs and will have to rely on UA sniffing or script to have their stylesheets work properly.

I'd be OK with a vendor implementing another vendors prefix, only:
1) after the identifier in question is in a CR level spec or is otherwise blessed by the WG for un-prefixed use, and
2) the vendor supports the feature un-prefixed, and
3) the other vendor has publicly stated that their experimental version is stable and will not ever change, and
4) the second vendor has demonstrated perfect compatibility with the first vendor's experimental feature with a sufficient test suite, and
5) the second vendor removes support for the first vendor's prefixed version at the same time as the first vendor does

>> MAY use a prefix specific to the CSS WG for the feature, if one is ever introduced, e.g. -css- or -csswg- 
>>> disputed, could include level, e.g. -css4-
> I don't know what "disputed" means here for sure... a feature in the policy that was disputed?  Did this ever happen?

Disputed in the sense that having WG or CSS level prefixes was proposed on a mailing list and failed to get any traction within the WG. Those discussions were captured on that wiki page but are not official statements by the WG.

>>> MAY use a prefix specific to the W3C for the feature, if one is ever introduced, e.g. -w3- or -w3c-
>> Disputed
> I suppose this never happened? Either?
>>> MAY use a generic draft prefix, if one is ever introduced, e.g. -draft-, -wd-, -lc- or -ed-
>> disputed, could be versioned
> I suppose this didn't happen either?

No, none of those ever happened. The WG does reserve those prefixes in case we ever change our mind.


[1] http://www.w3.org/TR/css-2010/#experimental
Received on Tuesday, 15 May 2012 18:10:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:45 UTC