Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Thu, May 7, 2015 at 8:26 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Note that at least for <textArea> this matters, in that you could suddenly
> have selectors that are not meant to match it start matching it.

That's not part of SVG1.1 or SVG2; it's not supported on most (all?)
major browsers anyway, so that's not a big deal.

>> You mean case-sensitively in the implementation? Type selectors are
>> case-insensitive for html elements.
>
>
> <style>
>   * { color: green }
>   foo { color: red }
> </style>
> <script>
>   var e = document.createElementNS("http://www.w3.org/1999/xhtml", "Foo");
>   e.textContent = "Is this red?";
>   document.documentElement.appendChild(e);
> <script>
>
> If the matching were actually case-insensitive, the text would be red. It's
> not.
>
>> The WebKit implementation represents each type selector with two
>> strings, one lowered and one with original case, when the type
>> selector is not lower-cased in the source. What does Gecko do?
>
>
> Exactly the same thing.
>
>> To always match type selectors case-insensitively in html documents.
>
>
> I don't think that's acceptable to at least Gecko from a performance
> standpoint.  Not if it means we have to end up with red text in my testcase
> above.

I believe the SVGWG is fine with a parsing-based approach, exactly
like what HTML does.  An SVG element created with mixed casing, or
imported from an XML document, might not match a lowercase tagname
selector, but SVG written in HTML will.

~TJ

Received on Thursday, 7 May 2015 21:07:51 UTC