interpreting the [type] attribute selector as case-insensitive
Reported by
chrishar...@gmail.com,
Jan 6
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Example URL: https://codepen.io/chharvey/pen/xmZdmp Steps to reproduce the problem: 1. go to https://codepen.io/chharvey/pen/xmZdmp 2. read through the HTML and CSS code written in the Pen What is the expected behavior? The first list should be styled with lower-latin markers ('a', 'b', 'c') and a red color. The first list is tagged with `<ol type="a">`, and should be matched by the selector `ol[type="a"]`, and no other selectors in the Pen. What went wrong? The first list is in fact styled with upper-latin markers ('A', 'B', 'C') and an orange color. In addition to being (correctly) matched by the selector `ol[type="a"]`, it is also *incorrectly* matched by the selector `ol[type="A"]`. This second selector results in the uppercase orange style (due to rules of CSS precedence). The `<ol type="a">` element should not be matched by `ol[type="A"]`. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? No Firefox 64, Safari 12 Chrome version: 71.0.3578.98 Channel: stable OS Version: OS X 10.12.6 Flash Version: The HTML5.2 Recommendation [1] says that values of the `[type]` attribute should be treated as case-insensitive, under one exception: The `[type]` attribute on `<ol>` elements as specified in a stylesheet should be treated as *case-sensitive* [2]. It appears that Chrome is ignoring this exception, since `<ol type="a">` matches both `ol[type="a"]` and `ol[type="A"]`. [1]: https://www.w3.org/TR/html52/matching-html-elements-using-selectors.html#matching-html-elements-using-selectors [2]: https://www.w3.org/TR/html52/rendering.html#section-lists
,
Jan 6
,
Jan 6
,
Jan 6
This works the same in every browser and is defined by the spec. You can fix it by using the s flag in the type selectors, though only Firefox supports that right now, see https://drafts.csswg.org/selectors-4/#attribute-case.
,
Jan 8
OL's type as a counter type is matched sensitively as you point out, but for selectors, https://html.spec.whatwg.org/multipage/semantics-other.html#case-sensitivity-of-selectors says: "Attribute selectors on an HTML element in an HTML document must treat the values of attributes with the following names as ASCII case-insensitive:" Where 'type' is one of the attributes listed. Ideally, we should've supported [type="a" s] and [type="a" i] to allow for separate styling.
,
Jan 8
Ah, so it's a deficiency/bug/whatever of the HTML spec. Like maybe it's impossible to define a per-tag exception or just not worth bothering.
,
Jan 8
re #7 (futhark): You’ve found yet another discrepancy between the W3C Recommendation and the WHATWG Specification. As you mentioned, the WHATWG says `type` is one of the attributes that is listed under case-insensitive. However, the W3C (https://www.w3.org/TR/html52/matching-html-elements-using-selectors.html#matching-html-elements-using-selectors) explicitly makes an exception for `ol[type]` rendering. I think this issue ultimately depends on the philosophies/goals of Chromium: whether to abide by W3C or WHATWG. |
||||
►
Sign in to add a comment |
||||
Comment 1 by woxxom@gmail.com
, Jan 6