Re: [selectors] Case-sensitivity of type and attribute selectors

On Nov 28, 2012, at 4:58 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> HTML defines that its tagnames and attribute names are
> case-insensitive.  The interaction of this with CSS type and attribute
> selectors, though, appears to be underdefined (or at least, browsers
> do different things).
> 
> In particular, it appears that FF's behavior is to do a
> case-insensitive comparison if the element is in the HTML namespace,
> and case-sensitive otherwise.  (I think IE does the same thing, but am
> not sure if it does in all circumstances.)  WebKit just lowercases the
> selector, and then does a case-sensitive comparison against the DOM
> name.  Opera is always case-insensitive.
> 
> WK's behavior is broken in the case of SVG elements, since some of
> them have canonical names with uppercase in them.  That means that,
> right now, we're completely unable to target mixed-case XML element
> names or attributes with selectors.
Just a note that this only happens for SVG-in-HTML case. XHTML and SVG documents will use case-sensitive matching.

Anyway, there's also the problem that SVG tags with lower-case types were matched using a case-insensitive comparison. Using 1 or 3 below will potentially break some existing content. It shouldn't be a problem if developers tested on multiple platforms though.

> 
> What should the correct behavior be?  We obviously have to maintain
> the HTML case-insensitivity, as there's tons and tons of content
> relying on that.  What should we do, though, about SVG elements (and
> in general, all non-HTML host languages)?  The choices seem to be:
> 
> 1. Everything but HTML is case-sensitive.
> 2. Everything is case-insensitive.
> 3. Host languages define whether they're case-sensitive (defaulting to
> case-sensitive in the absence of any other information).
> 
> Thoughts?
> 
> ~TJ
> 

Cheers,
Alex Chiculita

Received on Sunday, 2 December 2012 10:34:28 UTC