Re: Extend use of namespaces

----- Original Message -----
> On Sat, 18 Sep 2010 16:25:21 +0200, Paul Duffin <pduffin@volantis.com>
> wrote:
> > 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
> 

I really don't understand why you would want to replace a general approach (namespaces) that will be familiar to everyone that needs to use it with some special cases (:svg). Would you add special cases for XForms, MathML, ..., as well? It seems like complicating things just for the sake of it. The way in which namespaces were added to XML may not be perfect but they work and they are effective. They mean I can take two separate languages defined by two separate groups and use them together even though that may not have been designed for that explicit purpose. Without them I would have to check for conflicts and pray that future enhancements to those languages did not introduce conflicts.

Namespaces are not as complicated as you make out, neither from an author's perspective or from an implementation perspective.

CSS 2.1 states:
"Pseudo-classes classify elements on characteristics other than their name, attributes or content; in principle characteristics that cannot be deduced from the document tree."

So using a pseudo class for this purpose goes against that principle because a document tree for a namespaced document will include namespaces.

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

They may not solve the problem but I think they help make it more manageable.

> 
> Wait. Besides using namespaces here, you also change the approach.
> That's
> cheating! ;-)

Sorry. :-)

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

Namespaces may not have been intended to be used this way but that does not mean that there is no advantage in reusing the capability to do so. I can't yet see a disadvantage, and no one has yet pointed one out.

I think that there is a distinction between vendor implementations of published specifications and of completely proprietary or unpublished specifications.

A published specification in whatever state is a milestone of some importance to W3C, browsers and authors. As I understand it a specification is published to solicit feedback from the community (i.e. those not directly involved in the development of the specification). To get that you *need* browser vendors to implement it and you *need* page authors to use it so that any issues with implementation or usability can be found and fed back into the specification development process. The more feedback you get the better so you *need* to provide both parties with encouragement / benefit to do this. Given that browser vendors are relatively well established in the W3C page authors probably need more encouragement.

Browser vendors will implement a solution because it gets them some advantage, usually in the form of marketing statements that state 'Our browser X supports standard Y'. They won't be prepared to wait years (if that is how long the specification takes to achieve recommendation status) to get a return on their investment. If they invest the resources to implement a feature according to a published specification version then why should they not be able to indicate it as such, and get some credit for their 'standards support' rather than be forced to treat it the same as a completely proprietary solution. It may even encourage them to do more standards work.

Similarly, page authors will use it if it gets them some advantage, which usually means making their pages look better or function better. Most of them won't want (or even be able) to spend the time downloading a beta version of a browser, and then modify their pages to use the new features and test them on the beta, only to have to wait years for the functionality to come in the main stream before they can use it in their production sites. If a page author wants to spend the time to modify their page to use features defined in a published specification version why should they not get some benefit by having that work on any browser that implements the published specification version.

You are right, a prefix will do the same job as namespaces.

You could just as well do (note no leading - as CSS specifications are guaranteed not to use them):
    ... {...; CR-css3-ui-20040511-box-sizing: border-box; ...}
    ... {...; CR-css3-ui-20040511-box-sizing: content-box; ...}
    ... {...; display: WD-css3-flexbox-20090723-box; ...}

As you would:
    @namespace ui "http://www.w3.org/TR/2004/CR-css3-ui-20040511/"
    @namespace fb "http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/"

    ... {...; ui|box-sizing: border-box; ...}
    ... {...; ui|box-sizing: content-box; ...}
    ... {...; display: fb|box; ...}

So you could think of namespaces as a way for page authors to define their own aliases for the 'prefix'. It will save both time and space.

Received on Sunday, 19 September 2010 10:47:48 UTC