Re: Extend use of namespaces

----- Original Message -----
> On Sat, 18 Sep 2010 10:27:35 +0200, Paul Duffin <pduffin@volantis.com>
> wrote:
> > Ok, fair enough. What are your particular issues with @namespace,
> > and
> > how would you have addressed the need to style qualified XML
> > documents?
> 
> I do not think that is a use case worth addressing for the web. See
> also:
> 
> http://ln.hixie.ch/?start=1064828134&count=1
> http://annevankesteren.nl/2005/05/generic-xml
> 

Those links refer to the sending of custom XML and an associated XSLT to browsers rather than one of the Web standards markup languages. However, that is not the only use that is made of CSS namespacing. SVG, XForms, MathML all have their own namespace, and all require styling in some form. Also, CSS is not just used on the web it is used in a number of document authoring tools that do require namespacing.

The vendor extensions mechanism is a very poor substitute for a proper namespacing mechanism. It provides no real support for modularization, or versioning and the latter leads directly to the mess that currently exists for developers, http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html.

If you don't think the above is an issue then how about trying to address the issues that directly affect your customers, that is the web site developers. It is no good just saying that it is the specification process that is at fault, it has been that way as long as I can remember, I seriously doubt that it can be speeded up and I don't think specifications should be rushed anyway.

In the following examples I will use @namespace and CSS Qualified Names because like it or not that is the syntax that is available.

At the moment if I want to use box-sizing I have to add the following:
* box-sizing - for Opera (naughty naughty no vendor prefix)
* -moz-box-sizing - for Mozilla
* -webkit-box-sizing - for WebKit

Yet they ALL support exactly the same capability in terms of the standard (Mozilla adds an extra keyword but I will ignore that for now).

So I have to write things like:

div {-webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box}

If it was possible to use CSS Qualified Names as property names and each working draft of a CSS specification defined a namespace URI that had to be implemented (which could just be the versioned URL to the document) then a page author would only have to indicate the specification version to use. e.g.

@namespace wd-basic-ui-20040511 "http://www.w3.org/TR/2004/CR-css3-ui-20040511/"
div {wd-basic-ui-20040511|box-sizing: border-box}

On this simple example (and due in part to the verbose prefix I chose) the namespace approach results in a larger style sheet but over a realistically sized style sheet, with smaller prefix it will almost certainly be smaller but that is not the main reason for doing this.

Lets say that another browser vendor comes along that wants to support box-sizing, say IE9 (not sure if it does or doesn't). It would just implement the same versioned property and EVERY single page that currently used it would take advantage of it with NO CHANGES. With the vendor prefix IE would either have to create its own version -ms-box-sizing which will require all pages to be modified to take advantage of it, use one of the existing vendor prefixes, e.g. -moz-box-sizing (I don't see that happening), or go the Opera way and not use a vendor prefix at all. The latter approach is obviously easier but then you lose all benefits of vendor prefix.

The extra Mozilla keyword is a vendor specific keyword, it is not in the specification and so it should be qualified by a Mozilla specific namespace, or continue using the vendor extension mechanism.

Lets take a look at border-image.

WebKit and Mozilla both implement border-image as defined at http://www.w3.org/TR/2008/WD-css3-background-20080910/#the-border-image. At least I think they do, but it is difficult to know exactly as they do not say which one they support. That is another advantage of using namespaces and the versioned document as the URI it is perfectly clear exactly what version is being used and browser vendor document would have to describe exactly which version is supported.

Unfortunately, border-image syntax has changed since then and is now very different, see http://www.w3.org/TR/2010/WD-css3-background-20100612/#the-border-image. So what options do WebKit and Mozilla have to support the new definition.
* Use a different vendor prefix, e.g. -webkit2-border-image -moz2-border-image, which will require all pages to be modified to make use of each version.
* Change the behaviour of their existing property to match the new version of the specification, which would break every single page that relies on it.
* Try and merge the functionality from both specifications into one, it may not be possible to do it without any ambiguity and even if it is possible it will mean that their implementation matches neither version of the specification.

Contrast that with the CSS Qualified Name approach.

To use the WebKit and Mozilla implemented versions you could use:

@namespace back3-08 "http://www.w3.org/TR/2008/WD-css3-background-20080910/"

.... {back3-08|border-image: ....}

Now if they want to implement the latest version you could do:

@namespace back3-08 "http://www.w3.org/TR/2008/WD-css3-background-20080910/"
@namespace back3-10 "http://www.w3.org/TR/2010/WD-css3-background-20100612/"

.... {back3-08|border-image: ....; back3-10|border-image: ....}

When a new version of a specification is released it can also have a set of test pages for it that can be used by any vendor to test their browser's implementation. That will aid both in browser development and also improve consistency between browsers. There will still be many installations of the older versions of a browser installed on millions of devices such as mobile phones, some of which will be easily upgradeable, some of which will not. Web pages will still have to work properly on those so won't be able to remove support for the older versions immediately. Similarly, when browser vendor releases support for a new version of a specification they can't remove support for older versions either as they will break existing web pages. What is needed is an end-of-life process for specification versions that are not recommendations, so that both web page authors and browser vendors can plan for it.

This may not be the absolute best approach, however at least it is trying to address the real issues that affect page author's and browser vendors and which are not addressed by the existing vendor prefix. It also makes use of and doesn't break existing functionality, so you wouldn't need to spend years creating a new specification to describe a new feature to address how to implement features that are not recommendations yet.

It wouldn't take much to use this approach, you would just have to:
* Document that CSS Qualified Names could be used everywhere an IDENT can currently be used which shouldn't affect backwards or forwards compatibility.
* Document that when implementing features in working drafts that they MUST be qualified with the versioned URI of the document.

The above doesn't need to be a formal specification, although it should be merged into the specifications at the earliest opportunity. You would also need to extend the syntax of CSS defined in CSS 2.1 to allow qualified names (without wildcards) everywhere that IDENT is currently used.

Browser vendors could add support for these in their next releases, possibly namespacing all their existing vendor specific implementation of working draft features, and even namespacing their own properties and keywords.

Received on Saturday, 18 September 2010 14:25:56 UTC