Re: A List Apart: Articles: Prefix or Posthack

On Jul 9, 2010, at 6:50 AM, Eric A. Meyer wrote:

> As I have understood it, and as I think most authors who've done any work with prefixes have understood it, prefixed properties are 'in progress' and may change.  Once the changes are finished, they eventually become the same as the unprefixed property.  

Actually, I don't exactly want that either. The syntax or value meaning might change for the final version, but I will still want to have the prefixed versions in my style sheet, with their earlier (and in many cases, well established by years of use) syntax and value meaning, so that people with older versions of the browsers can get a fairly consistent effect (when possible).

>  I do not have the sense that people think that prefixed properties will just cease to be supported.  

Right. Many people need a little time to make sweeping changes to their style sheets; it doesn't mean that they are asleep at the wheel. You shouldn't have to follow this list, or have no other major time obligations in order to safely use a prefixed property that thousands of other authors have been using for many years. 

I propose that in 2.1, we change this line:

#Authors should avoid vendor-specific extensions [1]

to this:

#Authors should be careful about vendor-specific extensions, as they may change significantly or be removed at any time (especially early versions of experimental properties).

Or something like that (including a period at the end of the sentence).

And in CSS 3, we should change this:

#Although proprietary extensions should be avoided in general, there are situations (experiments, implementations of W3C drafts that have not yet reached Candidate Recommendation, intra-nets, debugging, etc.) where it is convenient to add some nonstandard, i.e., proprietary identifiers to a CSS style sheet. 

to this:

#Although proprietary extensions should be avoided in general, there are situations (experiments, implementations of W3C drafts that have not yet reached Candidate Recommendation, intra-nets, debugging, etc.) where it is convenient to add some nonstandard, i.e., proprietary identifiers to a CSS style sheet. Over time, authoring with these pre-standard extensions can add valuable feedback to the standardization process and help ease the Web into widespread use of new identifiers. To encourage this use, implementations are urged to maintain backward-compatible support for any prefixed identifiers that have seen stable, long-term use, even after the prefix has been dropped for Candidate Recommendation. This backward-compatible support can then be dropped during the Proposed Recommendation stage.


1) http://www.w3.org/TR/CSS2/syndata.html#vendor-keywords
2) http://www.w3.org/TR/css3-syntax/#vendor-specific

Received on Friday, 9 July 2010 15:21:02 UTC