Re: CSS Namespaces: Need multiple namespaces!

Ian Hickson wrote:

> On Wed, 29 Sep 1999, Peter Linss wrote:
> > The real issue here is how namespaces are really going to be used in
> > the real world. My takeaway from reading the Namespace Rec is that a
> > namespace is *just a name*, the URL doesn't actually point to
> > anything and shouldn't be overloaded to point to a schema or DTD or
> > anything (except perhaps someday some information about the
> > *namespace* not the document where it is used).
>
> Well, this is very much an open issue, but the Schema WG do seem to be
> considering using the namespace URI to point to Schemas and whatnot:
>
>    http://www.w3.org/TR/xmlschema-1/composition-tf.html
>
> However, this has no effect on CSS as far as I can tell.

Yes, the whole "what is a namespace anyway" and "how many of them should a
markup language have" debate is outside the realm of this list. But the
outcome of that debate can impact CSS, ie: if multiple namespaces are used it
makes it difficult, if not imposible, to author a single stylesheet that works
properly for different flavors of a namespace. CSS would have to be altered to
help the author out and maintain its usability...

>
>
>
> > If [the XHTML WG] set a stake in the ground and say "namespaces
> > don't have versions or flavors", then having this feature in CSS may
> > only lead to more confusion in the namespace arena. Which is
> > something I'd like to avoid.
>
> This feature is _not_ only for the case where we have versioned/
> flavored namespaces. A much more important reason for CSS to have this
> feature is for styling the elements with the same name in several
> namespaces. For example, you could have a stylesheet which styled
> documents that might have snippets in several other namespaces. If
> these namespaces had a common vocabulary subset, then you could do
> this:

I have to push back on this point a bit. I see the utility in what you're
trying to accomplish, but I disagree that this is the right way to go about
doing it.

If you start mixing @namespace declarations with completely foreign namespaces
(like xhtml and MathML) then you are in effect declaring equivalence between
the namespaces, if that were true, then there shouldn't have been different
namespaces to begin with.

For example, for me to say:
@namespace text url(xhtml) url(MathML);
text|foo { color: blue }

I'd be implying that a xhtml:foo *is the same kind of element* as a
MathML:foo. Which is simply not true, they are distinct entities or they
wouldn't be in distinct namespaces.

This would be the moral equivalent to some declaration like:
@equivalence heading { h1, h2, h3, h4, h5, h6 }
heading { color: blue }

rather than saying:
h1, h2, h3, h4, h5, h6 { color: blue }

I'm all for something like that as a general purpose mechanism to allows CSS
authors some indirection. But I'm against usurping namespaces to do it.


>
>
>    @namespace text url(xhtml) url(GuideML) url(ReviewML);
>
>    text|p { margin: 1em 0; } /* paragraphs in all our various text
>    markup languages should have 1em margins between them. */
>
> The alternative (and only way with the current draft) is:
>
>    @namespace xhtml url(...xhtml);
>    @namespace guideml url(...GuideML);
>    @namespace reviewml url(...ReviewML);
>
>    xhtml|p, guideml|p, reviewml|p { margin: 1em 0; } /* paragraphs in
>    all our various text markup languages should have 1em margins
>    between them. */
>
> Now, doing that with a simple type selector this doesn't cause many
> problems. But when you have this kind of situation:
>
>    @namespace metadata url(mdspec1) url(mdspec2) url(mdspec3);
>    @namespace text url(xhtml) url(GuideML) url(ReviewML);
>
>    text|p[metadata|status~=draft] { background: url(draft.png); }
>
> ...expanding that results in six namespace prefixes and nine
> selectors! The stylesheet becomes quickly unreadable for a large
> number of rules.
>
> Also, adding a new namespace later means editing just one line if
> @namespace can take more than one namespace, but a zillion lines if
> you have to add a prefix and update every relevant rule.
>
> --
> Ian Hickson
> : Is your JavaScript ready for Nav5 and IE5?
> : Get the latest JavaScript client sniffer at
> : http://developer.netscape.com/docs/examples/javascript/browser_type.html