W3C home > Mailing lists > Public > public-forms@w3.org > March 2008

Re: [css3-namespace] Last call comments from XHTML2 WG

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 20 Mar 2008 08:13:20 -0700
Message-ID: <47E27F10.4060509@inkedblade.net>
To: Steven Pemberton <steven.pemberton@cwi.nl>
CC: Anne van Kesteren <annevk@opera.com>, www-style@w3.org, Forms WG <public-forms@w3.org>, XHTML WG <public-xhtml2@w3.org>

Steven Pemberton wrote:
> Hi Anne,
> The XHTML2 WG discussed this issue yesterday.
> There was a fairly strong opinion that we disagree with this. A last 
> call is a last call, and if it has been broken for 9 years, then it 
> still really ought to be fixed.
> As far as we are aware there is no other case where the semantics of a 
> selector changes depending on which level of CSS is implemented, and 
> that CSS's principle of upwards and downwards compatibility is a good 
> one, that this breaks for the first time, making it harder to write 
> interoperable cascading style sheets.

Actually, this makes it easier to write interoperable CSS.

Nobody is forcing authors to declare a default namespace. They can rely
on prefixes only. But they also have the option of declaring a default
namespace. This allows the author to choose whether backwards-compatibility
would be better served by hiding the rules or letting them fall back to
more generous matching.

For example, if an author is writing an XHTML document, he might decide
to add a default @namespace declaration instead of prefixing each element.
Because he knows he is only importing this style sheet into XHTML documents,
the @namespace rule is not strictly necessary, but he wants to be explicit.
In this case falling back to unnamespaced selectors is very reasonable
behavior for down-level clients.

If the author is writing a style sheet for a compound document that mixes
two or three languages that use the same local names, then he might decide
that using prefixes is the better way to go.

Defining both mechanisms, prefixes and default namespaces, allows authors
to choose which fallback behavior is the most useful for their particular

Now, as Anne says, this technology is already widely and interoperably
implemented. We don't really have the option of removing the feature. And
as I've explained above, I see no reason to deprecate it either. So we
are rejecting the XHTML2WG's comment. If you want to raise a formal
objection, please let us know.


Received on Thursday, 20 March 2008 15:14:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:56 UTC