W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: [css21][css3-selectors] case-insensitive selectors (was: attribute values)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 15 Apr 2009 12:19:33 +0300
Cc: fantasai <fantasai.lists@inkedblade.net>, "Boris Zbarsky" <bzbarsky@mit.edu>, www-style@w3.org
Message-Id: <B65021FC-FD93-4B8F-973A-E5D689D11949@iki.fi>
To: Anne van Kesteren <annevk@opera.com>
On Apr 14, 2009, at 10:02, Anne van Kesteren wrote:

> On Tue, 14 Apr 2009 08:26:54 +0200, fantasai <fantasai.lists@inkedblade.net 
> > wrote:
>> And said document language says they're case-insensitive.
> Well, part of the problem is that there's not really such a thing as  
> "document language". The rules for what should happen when e.g. SVG  
> nodes are part of the tree are not exactly clear.
> Also, to avoid magic lists and "violating" Selectors we could make  
> HTML5 say that attribute values are case-sensitive as far as  
> Selectors are concerned.

Two related issues:

  1) Could the notion of case-insensitivity in CSS specs be changed to  
match the implementation reality in Gecko and WebKit? That is, instead  
of saying that two strings are compared case-insensitively, the spec  
would say that the selector ident is ASCII-lowercased and then  
compared codepoint-for-codepoint. This matters when HTML elements with  
uppercase letters are created with createElementNS or when they are  
created by the XML parser and then moved into a tree that has been  
flagged as an HTML document. It seems to me that it would make more  
sense to spec the current implementation reality of Gecko and WebKit  
instead of trying to plug the holes on the edges.

  2) On public-html, the issue of how to deal with both upper-case  
selectors matching HTML nodes on one hand and with camelCase selectors  
matching SVG camelCase nodes in the same tree on the other hand  
converged on making selectors have two internal local name atoms: one  
that is ASCII-lowercased and is used when compared against HTML nodes  
and another that is in the original case and used for comparing  
against other element nodes.


If this is indeed the solution that gets implemented for HTML  
documents, is there any practical reason to make the behavior  
conditional on the document being an HTML document? Wouldn't it make  
sense to eliminate special casing and use the lowercased selector  
atoms when matching against http://www.w3.org/1999/xhtml nodes in  
XHTML documents, too?

Henri Sivonen
Received on Wednesday, 15 April 2009 09:20:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:35 UTC