Re: CSS Namespaces: Need multiple namespaces!

Ian Hickson wrote:

> On Wed, 29 Sep 1999, L. David Baron wrote:
>
> >> In the CSS3 namespace draft, a namespace prefix can be associated
> >> with only a single namespace at a time.
> > I did actually already mention this problem [1].
>
> Oops. I must have missed that when I did my www-style catch-up (I lost
> two weeks' worth of mail around that time due to quota problems...).

I saw David's original post and I thought it was a good idea, depending.

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

With that in mind, I didn't see the need or desire for using multiple namespaces for
XHTML as had been proposed and hotly debated since.

If you presume that languages identified by namespace are going to have one and only
one namespace for all schemas/DTD and all versions (as I believe the namespace was
meant to be used), then you don't really need this mechanism in CSS. I was waiting to
see what precedent XHTML sets before adding this feature to CSS. If they go the multi
namespace route then I believe others will follow and CSS really needs this. If they
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.

As to the argument that you need to identify both the HTML and XHTML namespaces, you
don't. There is NO HTML namespace and there may never be. HTML does not exist as XML
markup, that's XHTML, so how can it have an XML namespace?. So a user agent that's XML
+ CSS namespace savvy could choose to interpret HTML as content in the XHTML namespace
(what Gecko will most likely do), or see it as content with no namespace. That's
outside the realm of control of CSS or XML for that matter.

You should also remember that down-level browsers have no idea what a namespace is, so
any CSS that uses them (especially for HTML) is going to be ignored. The default
namespace behaviors in the CSS namespace proposal are meant to allow authors to write
CSS that will work for both XHTML and HTML in both current and down-level browsers.

>
> > I did so at a time when XHTML only used one namespace, though.
> > Multiple namespaces for the same vocabulary bug me...
>
> I agree; but as devil's advocate I suppose one could argue that they
> are not the same vocabulary. One may be a subset of another, but they
> are not actually the same. For example, one allows <font> inside <p>,
> whereas another does not.
>
> When|If Schemas are pointed to by namespace URIs (as suggested in
> various packaging ideas recently), then namespaces will fill basically
> the same role as PUBLIC/SYSTEM FPIs/DTDs, and so n (where here n=3)
> namespaces will become a necessity.
>
> >> I suggest that the @namespace syntax be extended to allow an
> >> arbitrary number of url()s. Comments?
> > As I mentioned in [1], this causes some problems with the attr()
> > pseudo-function.
>
> Aha. It would appear, however, that you have already suggested a
> solution (namely, using the first matching attribute) and this
> solution would seem to be fine.
>
> If one wanted a particular attribute, then one could explicity qualify
> it. For example, with this document:
>
>    <!DOCTYPE x>
>    <x xmlns:n="NewsML" xmlns:g="GuideML" xmlns:h="HTML4-s">
>       <y title="Well" n:title="Hello" g:title="Exciting" h:title="World"> </y>
>    </x>
>
> ...and this CSS:
>
>    @namespace texts url(HTML4-s) url(NewsML) url(GuideML);
>    @namespace html4s url(HTML4-s);
>    * { tooltip: attr(title); } /* uses "Well" */
>    * { tooltip: attr(html4s|title); } /* uses "World" */
>    * { tooltip: attr(texts|title); } /* uses "Hello" because its the first match */
>
> ...you can see that attr(unqualified) gives the element's attribute,
> attr(nslist:attr) gives the first matching attribute from those
> namespaces given by "nslist", and attr(ns:attr) gives the attribute
> which matches the one namespace.
>
> As for default values, see section 5.8.2 of CSS2:
>
> # 5.8.2 Default attribute values in DTDs
> #
> # Matching takes place on attribute values in the document tree. For
> # document languages other than HTML, default attribute values may be
> # defined in a DTD or elsewhere. Style sheets should be designed so
> # that they work even if the default values are not included in the
> # document tree.
>
> Since both David and I have independently suggested this, it _must_ be
> a good idea... ;-)
>
> --
> 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