16

If CSS and HTML are both case-insensitive languages(*), and the W3C says

The case-sensitivity of attribute names and values in selectors depends on the document language.

How can I reconcile that with attribute values being case sensitive in selectors? For instance,

div[title=TITLE] {color:green}

does not make the text green for this HTML:

<div title="title">This is a div</div>

Fiddle here.

Is this a bug in the browser? And when I say "the browser", I mean all of them. Or am I looking at an unfinished version of the CSS3 specs? Which would be strange, as the same line of text was also in the CSS2 specs here.

(*) except for some features that are explicit exceptions, like class and ID names. Note that this example does not have class or ID names.

Jacek Laskowski
  • 72,696
  • 27
  • 242
  • 420
Mr Lister
  • 45,515
  • 15
  • 108
  • 150
  • 2
    Selectors 3 has been a recommendation for years now. I would say that it is finalized. This statement is unchanged in [Selectors 4](http://www.w3.org/TR/selectors4/#attribute-case) even outside of the new case-insensitive toggle. – BoltClock Dec 03 '13 at 15:02
  • As for classes and IDs, see http://stackoverflow.com/questions/12533926/are-class-names-in-css-selectors-case-sensitive – BoltClock Dec 03 '13 at 15:11

4 Answers4

14

You answered your own question:

The case-sensitivity of attribute names and values in selectors depends on the document language.

But further, I believe it is because to the browser, it and IT are not the same string. They are two different things to the browser.

EDIT--- You brought up something good in your comment. Let me explain: The HTML/CSS parser reads HTML and CSS as case-insensitive. That is because they are. But attributes are not, because they are defined by the user. So, it reads them as case-sensitive. Basically, HTML and CSS are standardized. Attributes are not.

EDITED AGAIN--- HTTP methods are standardized, (I Think) thus making it not necessary for them to be case-sensitive.

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
tjons
  • 4,749
  • 5
  • 28
  • 36
  • Yes, but HTML and CSS _are_ case insensitive! In fact, the same example does work if you write the tag name or the attribute name in uppercase. it's just the attribute value that has this issue. – Mr Lister Dec 03 '13 at 14:55
  • 1
    That makes sense. Because it's an actual `value` and not markup, it should be case-sensitive. I wouldn't want `doGS` and `dogs` to be equal. – DevlshOne Dec 03 '13 at 14:59
  • Also, in the markup, those values are always case insensitive. You can write `
     – Mr Lister Dec 03 '13 at 15:00
  • @MrLister That's because the `method` attribute is limited to `post, POST, get, GET`, specific values in a set. – DevlshOne Dec 03 '13 at 15:04
  • 1
    This answer seems to imply that it is entirely up to the browser - while it is, that doesn't automatically mean that there is no notion of conformance to some sort of spec, unless evidence exists that demonstrates otherwise (e.g. it is not defined in any spec how it should work). – BoltClock Dec 03 '13 at 15:20
  • @DevlshOne Then I used a bad example. Take ` – Mr Lister Dec 03 '13 at 15:21
  • @Mr Lister: By the way, if you want to test XHTML, you cannot use JSFiddle. It does not support XHTML because it never serves it properly even if you tell it to use an XHTML doctype. – BoltClock Dec 03 '13 at 15:23
  • 2
    Also: "But attributes are not, because they are defined by the user. So, it reads them as case-sensitive. Basically, HTML and CSS are standardized. Attributes are not." This is incorrect unless you're only referring to non-standard attributes. HTML has very clear definitions on which attributes are case-sensitive and which are not (HTML5 even accounts for custom data attributes). Even if you were referring to non-standard attributes, `title` is not one such attribute. – BoltClock Dec 03 '13 at 15:28
8

HTML5 actually contains an entire section dedicated to case-sensitivity for the purposes of selector matching. Here's what it says about attribute names and values:

Attribute and element names of HTML elements in HTML documents must be treated as ASCII case-insensitive for the purposes of selector matching.

Everything else (attribute values on HTML elements, IDs and classes in no-quirks mode and limited-quirks mode, and element names, attribute names, and attribute values in XML documents) must be treated as case-sensitive for the purposes of selector matching.

Of course, HTML 4 does not state anything about interop with selectors, but it does say that the title attribute in particular is case-sensitive. Since selectors depend on the document language for determining case-sensitivity, there is no difference here.

XHTML follows the same set of rules as XML does: all attribute values should be case-sensitive, so a selector must follow that case-sensitivity. Again, no difference.

So what you're seeing is entirely by design; there is no browser or spec issue.

Community
  • 1
  • 1
BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
  • OK. Now when testing, I did find some anomalies in how browsers handle case sensitivity in attribute values in XHTML markup; but that's outside of the scope of this question. Anyway, I couldn't see where the HTML4 spec says title is case sensitive, but that could be just me. – Mr Lister Dec 03 '13 at 15:29
  • @Mr Lister: "`title` = ***text* [CS]**" CS stands for case-sensitive. – BoltClock Dec 03 '13 at 15:30
  • OK! So to recap, I just happened to be testing with the wrong attribute! `title` happens to be just as case sensitive as `id` and `class`. That was my mistake. An [updated fiddle](http://jsfiddle.net/MrLister/zkw33/2/) shows that the other attribute I mentioned, `method`, does get the CSS applied if the cases don't match. – Mr Lister Dec 03 '13 at 18:29
  • @Mr Lister: `method` is [CI] http://www.w3.org/TR/html401/interact/forms.html#adef-method which means case-insensitive, so it does appear that browsers are following the original specs as they used to. Whether HTML5 intends to change the rules like this (making *all* attribute values case-sensitive for selector matching) is beyond me since doing so would break tons of pages, however. – BoltClock Dec 04 '13 at 05:22
  • That's what I meant, yes. I didn't know any better or only id and class were case sensitive, so this was kind of a revelation. I should have looked at the specs more carefully. Anyway, I don't think you need to worry about HTML5 breaking existing pages; the browsers have always worked very hard at keeping their backwards compatibility; and if that means breaking the formal rules, then so be it. – Mr Lister Dec 04 '13 at 06:05
1

Strings in attribute selectors are matched case-sensitively in HTML, and that’s pretty much that. I don’t know why they wouldn’t be – take name for example. name="foo" and name="FoO" get sent to the server differently, after all. Even ids are case-sensitive if you want them to be; this works fine and validates, and it seems like it should according to the spec (but I wouldn’t trust it to work everywhere).

See the specification (the relevant bit is in HTML’s spec, not CSS’s):

The Selectors specification leaves the case-sensitivity of IDs, classes, element names, attribute names, and attribute values to be defined by the host language. [SELECTORS]

The unique identifier of HTML elements in documents that are in quirks mode must be treated as ASCII case-insensitive for the purposes of selector matching.

Classes from the class attribute of HTML elements in documents that are in quirks mode must be treated as ASCII case-insensitive for the purposes of selector matching.

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.

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.

Everything else (attribute values on HTML elements, IDs and classes in no-quirks mode and limited-quirks mode, and element names, attribute names, and attribute values in XML documents) must be treated as case-sensitive for the purposes of selector matching.

Community
  • 1
  • 1
Ry-
  • 218,210
  • 55
  • 464
  • 476
  • No, no. If you change the CSS in the fiddle to read `DIV[TITLE=title] {color:green}`, it _does_ make the text green. So it's just how CSS responds to attribute _values_. – Mr Lister Dec 03 '13 at 14:57
1

Some newer browsers support this syntax 

div[title=TITLE i] { color:green; }

or 

div[title=TITLE I] { color:green; }

which both match this DIV: 

<div title="title">This is a div</div>

Note : Support: version : Chrome >= 49.0, Firefox (Gecko) >= 47.0, Safari >= 9

ankit
  • 125
  • 1
  • 3
  • This isn't widely supported. Your "latest browser" is Chrome only. – Mr Lister Mar 17 '16 at 13:02
  • this is supported in all latest browsers Support: version : Chrome >= 49.0, Firefox (Gecko) >= 47.0, Safari >= 9 – ankit Mar 22 '16 at 09:34
  • Sorry, but you can't honestly expect ordinary people to have Firefox Aurora installed on their machines. The current Firefox is at v45. Oh, and you didn't mention Edge. – Mr Lister Mar 22 '16 at 12:12
  • 1
    Score: **-1.** Meanwhile [the same solution](https://stackoverflow.com/a/26721521/6314667) on another question: **29.** Let’s pause and reflect here upon the quality and worth of SO scores... ⦁ @MrLister: And [“now”](https://en.wikipedia.org/wiki/2017) it’s [*every* browser](https://caniuse.com/#feat=css-case-insensitive) except Microsoft’s. You have failed the trial of time, @MrLister! But will it teach you anything? Or will you continue living in the present until your last breath? – 7vujy0f0hy May 23 '17 at 18:09
  • @7vujy0f0hy Oh, I have no doubt that many comments on this site will fail the test of time if you wait long enough. Do you expect everybody to go back and edit their old comments? – Mr Lister May 23 '17 at 18:47
  • 1
    @MrLister: No, I expect them to be less transient. Especially when that transience comes at a cost to a fellow user. Your concerns are no more valid but the negative score for +ankit persists. – 7vujy0f0hy May 25 '17 at 07:13
  • @7vujy0f0hy Well, sorry to disappoint, but I can't predict the future, and 14 months is a long time in browserland. – Mr Lister May 25 '17 at 07:17
  • 1
    @MrLister: But this particular development was inevitable. – 7vujy0f0hy May 25 '17 at 07:20