Case sensitivity of namespaced attributes of HTML elements in HTML documents

[SimonSapin]

https://html.spec.whatwg.org/multipage/scripting.html#selectors

When comparing the name part of a CSS attribute selector to the names of namespace-less attributes on HTML elements in HTML documents, the name part of the CSS attribute selector must first be converted to ASCII lowercase. The same selector when compared to other attributes must be compared according to its original case. In both cases, the comparison is case-sensitive.

(Emphasis added.)

Test case: https://jsfiddle.net/zbcoys5x/

<style>
  [*|FOO="bar"] { color: red; }
</style>
<div>text</div>
<script>
  document.querySelector("div").setAttributeNS("x", "foo", "bar");
</script>

In Firefox, Chrome, and Safari, the text is red. The lower-case name appears to be used for all attributes, not only namespace-less ones. Edge shows the test black, it appears to follow the spec on that point.

Note that the parser never produces an attribute where this makes a difference. Using setAttributeNS is required to create a namespaced attribute on an HTML element in an HTML document.

I’d like the spec to be changed to align with three implementations against one by removing “namespace-less” in the paragraph quoted above:

When comparing the name part of a CSS attribute selector to the names of attributes on HTML elements in HTML documents, […]

CC @bzbarsky

[domenic]

Sounds very reasonable to me. Would you be up for writing a pull request and/or web platform tests?

[annevk]

So you cannot match attributes with a name in uppercase?

This requirement also makes it harder to reuse a parsed stylesheet across HTML and XML documents. I wonder if there's not a better solution.

[SimonSapin]

@annevk With the current spec text, you cannot match namespace-less attributes with a name in uppercase in HTML elements in HTML documents (which are also never produced by the parser). With my proposed change, that would be the case regardless of namespace. But still only on HTML elements in HTML documents.

I don’t understand your point about sharing stylesheets. The "in HTML documents" bit is about the element being matched, not about the stylesheet.

[SimonSapin]

• Spec PR: Selectors: attr name in any NS on HTML elements are case-insensitive #2700
• Test PR: Selectors: attr name in any NS on HTML elements are case-insensitive. web-platform-tests/wpt#6008

While editing I noticed that the previous section has very similar text:

https://html.spec.whatwg.org/multipage/scripting.html#case-sensitivity-of-the-css-%27attr()%27-function

When comparing the attribute name part of a CSS 'attr()' function to the names of namespace-less attributes on HTML elements in HTML documents, the name part of the CSS 'attr()' function must first be converted to ASCII lowercase. The same function when compared to other attributes must be compared according to its original case. In both cases, the comparison is case-sensitive.

It may make sense to make a similar change here for consistency, though this case is less annoying to implement since (unlike attribute selectors) attr() does not support *|foo namespace wildcards, so case-sensitivity is decidable before attribute lookup.

[annevk]

@SimonSapin what are the chances of Selectors just defining this inline just like CSS defines how the HTML body element is special when it comes to overflow and such?

It still seems somewhat problematic from a theoretical angle, as this precludes the addition of a namespaced attribute with an uppercase letter from being used in HTML. It's unlikely we ever wanted to make such an addition, but I doubt that if someone in the future ever did make that decision, they'd realize it would break Selectors. Whereas not introducing namespace-less attributes with uppercase letters is how HTML already works.

[SimonSapin]

@annevk Are you proposing moving the whole “4.16 Matching HTML elements using selectors and CSS” section into the Selectors spec? I don’t have an opinion on that, you’d need to propose it to the editors of that spec and CSSWG.

[zcorpan]

Is there a performance or implementation complexity reason to prefer any namespace?

[SimonSapin]

Implementation complexity, yes. In particular for the namespace-wildcard case: when matching [*|Foo] in the current spec, you need to iterate all attributes, look if a given attribute has a namespace, and based on that decide to use the original or lower-cased name in the selector to compare against the content attribute’s local name. In every other case, or with the proposed change in every case, you can decide which of the original or lower-cased name to pick before doing attribute lookup.

(For what it’s worth, Servo and Stylo share a selector matching library that can be used with different content tree data structures, so there is an abstraction boundary there.)