Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lowercasing of element type selectors #4155

Open
gsnedders opened this issue Nov 1, 2018 · 12 comments
Open

Lowercasing of element type selectors #4155

gsnedders opened this issue Nov 1, 2018 · 12 comments

Comments

@gsnedders
Copy link
Member

gsnedders commented Nov 1, 2018

The spec currently says:

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

Selectors says:

The attribute name in an attribute selector is given as a CSS qualified name

As written, I believe this means that:

@namespace xhtml "http://www.w3.org/1999/xhtml";

XHTML|span {
  color: orange;
}

should be matched as xhtml|span.

See also: #3372

@gsnedders
Copy link
Member Author

web-platform-tests/wpt#13738 has tests for this, as well as plenty of other tests for the HTML ns specificity of this.

@gsnedders gsnedders changed the title Lowercasing of attribute name selectors Lowercasing of element type selectors Nov 1, 2018
@NOVALISTIC
Copy link

NOVALISTIC commented Nov 2, 2018

In your example, the type selector is not XHTML|span, but span. The former is a CSS qualified name; the spec says only to lowercase the type selector portion, not the entire qualified name. So the problem isn't in the type selector but in the namespace prefix XHTML.

Section 3.3 of css-namespaces-3 states that namespace prefixes are case-sensitive, so XHTML not matching the xhtml as declared in the @namespace rule seems correct to me.

@annevk
Copy link
Member

annevk commented Nov 2, 2018

Per https://drafts.csswg.org/selectors/#type-selector @gsnedders is correct. It seems like we should write something like "ASCII lowercase type selector's identifier".

Not sure what to write for attribute selectors though.

cc @tabatkins @fantasai

@gsnedders
Copy link
Member Author

So https://drafts.csswg.org/css-namespaces-3/#css-qualified-name makes me think we want "the CSS element type selector's local name must first be converted to ASCII lowercase", though the definition of local name (and namespace prefix) isn't defined as a term in Namespaces.

@tabatkins
Copy link
Contributor

Yeah, the namespace component is part of the type selector, per https://drafts.csswg.org/selectors/#type-nmsp.

This subsection should probably be slightly rewritten to use terms from DOM, yeah?

@NOVALISTIC
Copy link

I stand corrected, @annevk @tabatkins, so is the DOM text just confusing in that case?

@annevk
Copy link
Member

annevk commented Nov 5, 2018

@tabatkins the subsection in HTML or Selectors? I think Selectors could be clearer that a type selector is a struct that always has a name and sometimes a namespace (though perhaps it should be namespace prefix, it's a little unclear when resolution happens and what ends up in the data model). And then HTML could be updated to lowercase the type selector's name only.

@gsnedders
Copy link
Member Author

@annevk Is that any less clear than cases where DOM uses qualified names? I don't think it really is?

@annevk
Copy link
Member

annevk commented Nov 5, 2018

@gsnedders yes, DOM has dfns for all these bits and is specific about using them.

@fantasai
Copy link
Contributor

fantasai commented Nov 21, 2018

I think this should be fixed by using the wording @gsnedders proposes in #4155 (comment) . CSS Namespaces is fairly old,, so it doesn't have DFNs the way newer specs do (and it wasn't anticipated that a host language should be able to manipulate part of a qualified name e.g. by lowercasing it prior to matching, it's a pretty weird layering violation). But @gsnedders' wording seems pretty clear to me.

@domenic
Copy link
Member

domenic commented Nov 21, 2018

Thanks! @gsnedders any chance we can convince you to turn that into a pull request? :)

@gsnedders
Copy link
Member Author

@domenic I meant to do that several weeks ago. I, uh, probably should. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

6 participants