Re: CSS vendor extension issues

On Wednesday, November 9, 2011, 9:55:38 PM, Larry wrote:

LM> I'm trying to understand whether there is a difference between
LM> using "vendor" prefixes and prefixed values, compared to using
LM> URIs for XML namespaces and namespace prefixed values.

I believe there are some practical differences, yes. Also some theoretical differences that have little practical impact.

LM> Both are extensibility mechanisms. 

Yes. Furthermore, both are primarily syntactic, clash-avoidance extensibility mechanisms. Neither provides this-is-what-this means semantic extensibility or (except by accident) here-is-the-spec implementor guidance extensibility or here-is-the-code runtime extensibility.

LM> In the vendor-prefix case, the
LM> name of the namespace requires some registry (maintained by whom?)
LM> to map between vendor prefixes and vendor identities.

No, not really. That is, the function of the prefixes is unaffected by the vendor identity (for example, if a vendor was bought by another company and their identity changed, the stylesheets using the prefixes would be unaffected). In practice there is an informal registry - people know that -moz- is the mozilla prefix, -webkit- the webkit one, etc.

But then again, xml namespaces used in content are not much affected by what (if anything) is obtained by dereferencing the namespace URI,or if the URI goes away or redirects to another one as a result of organizational changes. So may be these are more similar than appears.

Of course, these have large theoretical effects if 'root everything in URI space' and 'follow your nose through the spec chain' are guiding principles. My point here is that in practice, the use of vendor prefixes and of namespaces in implementations is unaffected by such things.

LM> Are there any other distinctions? Is one better than the other?
LM> Do the same sorts of problems occur?

One problem that can occur is that the amount of stylesheets that use a particular vendor prefix for a commonly used feature (which is not yet standardised and does not have an unprefixed version) can reach somecritical mass such that other vendors start supporting that vendor prefix in their own implementations (possibly with different levels of support or different bugs). Thus, the simple 1:1 mapping between prefix and implementation is broken.

Another difference between vendor prefixes and xml namespaces is that the vendor prefixes are *intended* to be temporary - once there is a standardized version, stylesheets should use the unprefixed version. Although in practice with the wide range of browser versions in use at a given time, the prefixes stick (same problem as x- MIME types).

A third difference is that the combination of prefix and property name tends to come in sets, unlike namespaces. So for a new property 'blah' there may be a -webkit-blah in webkit and a -o-blahstyle in opera which take the same/similar/wildly different values. Then you may see a -moz-blah property in mozilla based on the first working draft syntax, and later a -ms-bikeshedding property after the working group has kicked around the syntax some for the second draft.

This can lead to client-side scripts or author-side tools to allow authors to write the property once and then automatically generate the various syntactic forms.

And a fourth difference is caused by the differences in handling of duplication and repetition in XML and in CSS. 


-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Thursday, 10 November 2011 00:33:48 UTC