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

On Thu, 20 Mar 2008 16:13:20 +0100, fantasai  
<fantasai.lists@inkedblade.net> wrote:

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

Well, exactly. If the CSS WG thinks that the advantages to the author so  
outweigh the CSS principle of future changes to the language not changing  
the meaning of past selectors, then the spec should point it out in big  
letters, because it seems to be a big philosophical change.

But the choice should be made intentionally, and not just because  
implementations have been doing it this way for 9 years. And people should  
be warned on best practice for making stylesheets CSS-level agnostic now  
that the rules have changed.

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

But if it doesn't make any difference, there's nothing to talk about. It's  
places where it *does* make a difference that we are talking about.

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

This isn't what we are talking about. What we are talking about is that

	a {color: blue}

can mean different things depending on what level of CSS is implemented in  
the UA. This is a new concept in CSS. Up to now type selectors have meant  
one thing and one thing only.

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

Sure, and it breaks a principle that used to be held for CSS. If you think  
that's OK then go for it, but say so.

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

Are you rejecting the comment to add text pointing it out and advising  
against it if you want level-agnostic stylesheets as well?

Best wishes,

Steven

Received on Wednesday, 26 March 2008 12:42:20 UTC