- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 20 Mar 2008 08:13:20 -0700
- 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 situation. 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. Thanks~ ~fantasai
Received on Thursday, 20 March 2008 15:14:11 UTC