On 5/7/15 10:53 AM, Rune Lillesveen wrote:
So there's no author-rationale here?
Well... that depends.
The way things used to work before SVG-in-HTML existed is that selector
matching was case-sensitive in SVG and apppeared case-insensitive in
HTML. I say appeared because it wasn't, actually: if you created an
HTML element with local name "Foo" (e.g. via createElementNS or
importNode from an XHTML document) then the selector "foo" would not
match it in at least some implementations.
When we were trying to design how this should work in a document with
mixed HTML and SVG, we aimed to preserve the existing behaviors of HTML
and SVG while also not forcing UAs into doing any actual
case-insensitive matching at selector-matching time, which allows much
faster compares on pre-interned strings.
The "depends" part is whether you consider "aimed to preserve the
existing behaviors of HTML and SVG" as author rationale or not.
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.
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.
-Boris
