W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: Extend use of namespaces

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 19 Sep 2010 11:36:19 +0200
To: "Paul Duffin" <pduffin@volantis.com>
Cc: "Sylvain Galineau" <sylvaing@microsoft.com>, www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
Message-ID: <op.vi9wytin64w2qv@anne-van-kesterens-macbook-pro.local>
On Sat, 18 Sep 2010 16:25:21 +0200, Paul Duffin <pduffin@volantis.com>  
> 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.

See http://lists.w3.org/Archives/Public/www-style/2010Sep/0569.html

> Also, CSS is not just used on the web it is used in a number of document  
> authoring tools that do require namespacing.

Yeah, well, dealing with the web is complex enough as it is :-)

> 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.

Namespaces do not solve this problem.

> 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}

Wait. Besides using namespaces here, you also change the approach. That's  
cheating! ;-) People have indeed suggested that browser vendors use a  
common prefix, e.g. -wd1-box-sizing, which would be much shorter than what  
you have here and have the same effect, but the CSS WG rejected that  
because browsers will have implementation differences, and each wants to  
have their own strategy. Feel free to disagree with that decision but lets  
not add the cloud of confusion that is namespaces on top of that, as they  
have absolutely nothing to do with it.

> [...]
> 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.

The same goes for the approach you suggest with namespaces. (Or with the  
common prefix approach.)

Anne van Kesteren
Received on Sunday, 19 September 2010 09:37:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC