Vendor Prefixes and Generic Prefixes: who shall use which when and why?

> Vendor Prefixes
> ---------------
> 
>  Discussed problem of WebKit monopoly on mobile and the consequent
>  pressure for other engines to implement -webkit- properties.
>      https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology

>  Simon Fraser (Apple)
>  Tab Atkins, Luke Macpherson (Google)
>  Alex Mogilevsky, Rossen Atanassov, Sylvain Galineau (Microsoft)
>  David Baron, Tantek Çelik, John Daggett, fantasai Etemad (Mozilla)
>  Håkon Wium Lie, Florian Rivoal (Opera)

>  Alan Stearns, Steve Zilles, Vincent Hardy (Adobe)
>  Daniel Glazman (Disruptive Innovations)
>  Peter Linss (Hewlett-Packard)

>  Bert Bos (W3C)
>  Koji Ishii, Anton Prowse (Invited Expert)

> Vendor Prefixes
> ===============
> 
>  tantek: At this point we're trying to figure out which and how many webkit
>          prefix properties to actually implement support for in Mozilla
>  tantek: We don't consider this a long-term situation. The goal is to open
>          up the webkit-specific part of the web to others, same as implementing
>          parts of IE-specific web.

That’s sad.

>  Tab: Given the discussion is about webkit being a monoculture on Mobile, if
>       webkit decides to remove a prefix then it's okay for everyone to remove
>       prefixes also.
>  Florian: Some prefixes will not be dropped by webkit
>  glazou: None will be dropped.

… but many, most or even all will be supported unprefixed if and when they’re standardized.

>  Florian: If something is intended for internal use, then it is proprietary.
>  Florian: But once it's encouraged out on the Open Web, it cannot be
>           proprietary anymore.

That’s why those cases absolutely need different prefixes, and validity scopes.

>  alexmog: Once Apple ships -webkit-, it's frozen.
>  smfr: It's not necessarily frozen, might be changed.
>  alexmog: We will never drop -ms-, or change -ms- behavior.

I believe Microsoft’s commitment to backwards/bug compatibility is unprecedented and unchallenged, but I’m not so sure that’s a good thing (only).

>  glazou: Unbelieveable we are having this discussion.

I agree, not that it wasn’t necessary, but the style and definiteness surprises me.

You cannot decide on a cure for the current mess, if you don’t agree on how a healthy system should work.

>  dbaron: The more we can unprefix, perhaps the less we have this problem.
>  tantek: One possible proposal is to only parse other vendors' prefixes in
>          conjunction with parsing unprefixed.

That’s a minimum requirement. Anything less should not even be considered for discussion.

>  glazou: This is replacing standardization by turning one implementation
>          into a de facto standard.

That’s right. Thereby you lose one major benefit of open standardization, i.e. many brains with eyes, and you lose a major detriment of open standardization, i.e. many brains with mouths.

>  smfr: I can take a list of properties we need back and see if we can bring
>        it back for standardization
>  glazou: In a reasonable timeframe?
>  smfr: Yes.

What’s a reasonable timeframe: friday, summer, two years ago?

>  tantek: I think if you're working on open standards, you should propose
>          your features before you implement them and discuss that here.

You absolutely should.

>  smfr: We can't do that.
>  sylvaing: We can't do that either.
>  tantek: We're going to push you to do that sooner and sooner.
>  jdaggett: If you're proposing something that's going to be put on a Web
>            page, how is that proprietary?

I assume there’s a bit missing from the minutes, since nobody mentioned “proprietary” before. 

Vendors are free to implement all the proprietary stuff they can devise as long as it is opt-in or limited to local / internal resources or limited to experimental builds of the implementation. This can only work reliably if done with prefixes, because it could conflict with future features.

When a feature is available to everyone on the Web this must be obvious, therefore you cannot use the same vendor-specific prefix, if a prefix is to be used at all. I hence propose a set of prefixes further down.

>  glazou: We're not just here to do things. We're here to do things the right
>          way. We want things to be stable on the Web for 50 years.
>  glazou: I don't think this is the right way. And this is the first time in
>          this WG that we are proposing to do things that are not the right way.

Glazou is correct, of course, but being correct doesn't help.

>  tantek: Request Opera and Microsoft to publish your methodology and what
>          properties you're thinking of implementing.

That’s helpful to decide which specs should be pushed to CR sooner than others.

>  plinss: As soon as we do this, vendor prefixes have failed.

As currently used – yes. Maybe that helps to form a consensus when and how and which prefixes should be used.

>  dbaron: So what should we do, disband the WG?
>  plinss: yes

That doesn’t work and neither does kicking out browser developers, since CSS is an open and voluntary standard without direct enforcements and sanctions.

>  glazou: I'm dead serious. Are you going to help them gain market share by
>          standardization?
>  smfr: We're members of this WG, and accepted the IP implications of that
>        for transforms and stuff.
>  glazou: But you submitted that directly. But not text-size-adjust.
>  smfr: Think it slipped between the cracks; not enough impetus to standardize
>        it.

That’s more than unfortunate. I firmly believe every member of the WG (or W3C) should or even must commit to document and propose each and every feature they make available on the Web, even if it’s “just” on mobile browsers – and they should commit to implement specs resulting from that, even if they differ from the initial implementation. In my opinion that includes ebooks, too, so Apple should submit their ‘-ibooks-’ additions and update their applications accordingly after they’ve been accepted, adapted or rejected.

>  Alan: These are things we need to standardize on *now*.
>  Alan: Make it something that the WG finalizes within the next 3 months.

The sooner the better, since we cannot change much about the details anymore anyhow.

>  jdaggett: You need to make public statements like "Here is an example of
>            a presenter presenting -webkit- things as if they are a standard,
>            and they are not."
>  jdaggett: Need multiple people here to do that.
>  howcome: Including Apple.

… and Google. Let’s not forget that Webkit has a monopoly on mobiles because there’s a oligopoly of operating systems, the biggest two backing that rendering engine, that means it’s not just Apple. 

>  Anton: Need the WG to agree and explain what problem they're trying to
>         solve with prefixes.
>  Anton: I think it is harmful to concentrate on this one problem and not
>         concentrate on the global problem. Send a very mixed message to
>         authors.

I wholeheartedly agree. Here’s my draft proposal, which only addresses the general process that should be the ideal we’d like to turn the current mess into:

Rules for implementors
======================

Use your vendor prefix for internal features. Register your prefix(es) with the W3C informally. Don’t choose one already existing. Have separate prefixes for your organization or company, for each implementation (product, e.g. browser and mail client) and for the rendering engine if it is used by more than one vendor, wisely choose between the options.

If you agree with another vendor on a feature, outside the W3C, you may use the common prefix ‘-vnd-’. This should never happen, though.

If you are submitting a proposal, but do neither have an implementation for it nor plan to make one soon, use the prefix ‘-proposal-’ (or ‘-x-’?). This should happen rarely. You and other implementors may use this prefix in experimental builds.

As soon as an editor has picked up a feature – no matter if proposed, undocumented or thought up themself – and put it into a public Editor’s Draft, you should use the prefix ‘-ed-’ if you try to implement the specified syntax and behavior, but keep using a vendor or proposal prefix otherwise.

When a feature makes it into a public Working Draft, you may use the prefix ‘-wd-’ for the same purposes you use ‘-ed-’ for, and with the same restrictions. You may implement the same feature with ‘-ed-’ and with ‘-wd-’ prefix differently from each other for testing purposes (or for compatibility, also see below). 

All prefixes described until this point must not be available to the public, i.e. they may be active by default for your nightlies, private betas or platform previews and you may offer an opt-in switch for testers in public betas and the like.

Furthermore, you should make WD features available to authors using the ‘-draft-’ prefix. Authors must never be able to rely on any other prefix on the Internet. For intranets, implementations may support an opt-in mechanism to support prefixed features, which effectively can be versioned as detailed above and below.

You must not prefix features from Candidate Recommendations and Recommendations, unless you know that their implementation is buggy and therefore considered experimental. You should then use the ‘-cr-’ or ‘-rec-’ prefixes.

Iff your implementation supports an opt-in switch, it may also differentiate features by their origin. 
That means if, for instance, CSS, SVG and EPUB all use the same keyword with slightly different semantics, your implementation may implement all three of them and automatically select a default for the unprefixed case, but still make them available to intranet authors with prefixes ‘-css-’, ‘-svg-’ and ‘-epub-’ respectively. If the W3C specs, i.e. CSS and SVG, agree with each other, but differ from a third party, you may use the prefix ‘-w3c-’ as a collective alias for both, ‘-css-’ and ‘-svg-’. 
Also, if you wish to support a feature that differs between levels of CSS, you may use the prefixes ‘-css2-’, ‘-css3-’ etc. 
The W3C and other standardization organizations try to make sure that there’s little to no need for any of this.

Guidelines for Web authors
==========================

You should not use prefixes at all!

Forget you ever heard about them!

The only one left available to you is ‘-draft-’ anyhow. Expect browsers to change their implementations of such properties at any time. You may safely assume that nothing will ever change for non-prefixed features (except that they will get more bells and whistles in a backwards compatible manner).

Guidelines for intranet authors
===============================

Try to use no prefixes at all. Carefully select the best version if you have to. 

If you need certain functionality you have to make sure your admins make it available throughout your network, i.e. they have to change browser configurations and they won’t like it. You cannot rely on the W3C to document the behavior of prefixed features, consult your browser vendor instead.

>  glazou: If the user requests another -webkit- property, they will implement
>          it. It's a Pandora's box.

Authors, collectively, will expect that indeed.

>  tantek: My experience with authors is that they Hate using prefixes.
>  tantek: They complain that CSSWG takes too long.

It does, but authors also are too careless when they use prefixed features. Vendors, evangelists and W3C don’t have a good track record in making clear that they’re using them at their own risks. Supporting prefixes from a competitor would send the worst imaginable signal here, even if it’s (initially) limited to a conservatively chosen set.

>  glazou: Even if we only take 3 months from FPWD to unprefixed, it's too
>          slow compared to shipping an implementation, which is then used
>          immediately.

Features should be submitted with the first (semi-)public beta version of an implementation, not when shipping the stable release.

>  dbaron: The IETF has a motto "rough consensus and running code"

That sounds like being roughly equivalent to LC.

>  sylvaing: Both us and Apple document our things on our site, but not enough
>            for standardization
>  Steve: Suggest that group establish a goal that members who introduce
>         experimental properties submit a description to the WG

Absolutely. I don’t care if it’s member-only at first.

>  Florian: Some people are saying don't do this. But all the vendors need
>           to do this.
>  Florian: Blocking the conversation here just means don't do this in this room.

This discussion should be blocked – at least – until the WG has ultimately decided and written down how prefixes are supposed to be used.

>  dbaron: Email headers with X-. Supposed to be experimental. But the world
>          still works.

I we had just ‘-x-’ and no other prefix you probably wouldn’t have had this conversation. That prefix would never be dropped and vendors wouldn’t submit proposal for prefixed features. Numerous specifications offering an extension mechanism like that have shown this, because it’s just too much a (frustrating) effort to standardize something if it already works for you.

>  plinss: We should assert leverage to get MS and Webkit to change their mind.
>  plinss: Prefix has half-life. It will live for so many years, then go away,
>          by definition. That will help this problem.

I don’t know if temporal decay is the best way to go, but at least it is one. Maybe it should be applied to specifications instead. Maybe in a positive form, though: WDs freeze after, say, six months without neither an update nor a new issue raised, all features then may be implemented unprefixed and it is the WG’s job to make sure later drafts and recommendations don’t introduce incompatibilities, even if the WD is later withdrawn.

>  glazou: Prefixes for web authors, they don't think it's a bug. They think
>          it's a burden. It's not the same thing.
>  glazou: It's a burden b/c they don't know how long they have to maintain them.
>  glazou: If prefixes were only implemented for 3 years, that would help.

It’s more serious than that: many don’t think about maintenance at all.

>  tantek: mozilla has a policy of dropping prefixes when we implement unprefixed

That’s a good policy, but it only worked well if at least two major players (out of four or five) would follow it.

>  fantasai: What if -webkit- was implemented only for mobile?

I assumed that was implied anyway. None of this was about desktop browsers.

Received on Tuesday, 7 February 2012 14:01:38 UTC