Re: Selectors, getElementsByTagName() and camelCase SVG

On Apr 15, 2009, at 20:28, L. David Baron wrote:

> This has the disadvantage that it makes XHTML (in XML) partially
> case-insensitive.

I think that decision is orthogonal to the design of using dual atoms  
on selectors. With dual atoms, there'd be an atom for matching against http://www.w3.org/1999/xhtml 
  nodes and another one for matching against everything else.

If we don't want to make http://www.w3.org/1999/xhtml nodes in XML  
match the same way http://www.w3.org/1999/xhtml nodes in HTML do, the  
two atoms on the selector would be the same original-case atom in the  
context of XML documents.

However, over on www-style, I did suggest making the two atoms differ  
in the context of XML the same way they'd differ in the context of  
HTML, because doing so would eliminate a difference (in my opinion,  
not a useful difference) between HTML and XML. I care more about my  
suggestion #1 in the same email, though.
http://lists.w3.org/Archives/Public/www-style/2009Apr/0273.html

> We could avoid some confusion about whether
> things are case-insensitive by instead:
>
> * assuming DOM nodes have an internal notion of whether they're
>   case sensitive (which would be true for anything other than DOM
>   nodes in text/html that are in the HTML namespace)

If this internal notion is updated when a node is moved to another  
document, wouldn't the outcome be same regardless of whether the flag  
is on each node or whether it is on the owner document?

If the internal notion isn't updated when a node is moved to another  
document, wouldn't the outcome be even stranger edge cases than the  
outcome of putting the flag on the document?

I think having the flag on the document makes sense conceptually,  
because for parser-inserted nodes the difference depends on the  
content type which is a label of the entire document, and the flag can  
be changed by calling .open() on the document object.

Also, I think it's more confusing to do what Opera and Gecko do now  
and allow element nodes with XML traits to be inserted into HTML  
documents than to make the traits depend on the owner doc. The latter  
(which is what WebKit does and HTML5 now says) would make sure that  
you can't end up with mixed traits in one document. I've actually  
ended up with mixed-traits DOMs in the course of normal authoring as  
opposed to test case writing. The DOM Inspector view was confusing for  
a brief moment until I realized what was going on.

> This would avoid making nodes partially-case-sensitive, which seems  
> like it could confuse authors.

But that is already the case in a detectable way. Gecko, WebKit and  
Opera all leak the partiality of their case-sensitivity illusion  
somewhere if one deliberately pokes the right edge cases.

Also currently, if the author introduces uppercase ASCII letters into  
the names of HTML elements, the result is already failure, because the  
elements won't get the right behaviors and DOM interfaces.

> Partial case-sensitivity also has the problem that each API or spec
> that depends on whether something is case-sensitive (e.g., CSS
> selector matching, various DOM APIs) has to explicitly pick a side.
> It seems like there could be a lot of such specs, and I would expect
> the results to be inconsistent.

Since the implementations of those specs already 'pick a side' in  
practice in Gecko and WebKit at least, wouldn't it make sense to make  
the specs acknowledge this?

It seems to me that plugging the edge-case holes in the  
implementations that allow pages to detect that matching isn't really  
fully case-insensitive but relies on one side of the comparison  
getting ASCII-lowercased before a strict equality comparison would be  
less worthwhile than just standardizing the edge-case holes (assuming  
that leaving edge case behavior "up to the implementation" is not  
acceptable in Web specs).

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 16 April 2009 07:54:19 UTC