888190 - Case-insensitive attribute selectors (from Selectors level 4)

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement, P5)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: fix

Since I absolutely needed it myself in BlueGriffon, I wrote a trivial patch to implement the case-insensitive attribute selector proposal from Selectors 4 in section 6.3 [1]. Not sure you want to adopt this patch right now given the status of the document but hey, the patch is at least preserved here and waits for decision.

From my point of view and given how is designed that extension to attribute selectors, it's probably quite harmless to ship it. The impact on existing web sites should be close to zero.

I'll add a test when decision to adopt the patch is made.

[1] http://dev.w3.org/csswg/selectors4/#attribute-case

Comment 1

[Simon Sapin (:SimonSapin)]

Exposing a feature to the web makes it harder to change later. Does the CSS WG consider this one mature enough?

If not, the feature could be behind a flag that defaults to off in Firefox and on in BlueGriffon, right?

Comment 2

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to Simon Sapin (:SimonSapin) from comment #1)

> Exposing a feature to the web makes it harder to change later. Does the CSS
> WG consider this one mature enough?
> 
> If not, the feature could be behind a flag that defaults to off in Firefox
> and on in BlueGriffon, right?

Agreed, of course. But:

1. It's not exposed to BlueGriffon users. I am using it in BlueGriffon's JS code but BlueGriffon offers no UI at all for this.

2. I said the decision is in Mozilla's hands

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 768829 [details] [diff] [review]
fix

This patch does most but not all of what we need to implement the feature.

The problem is that the current isCaseSensitive boolean in attribute selectors has two values:
 * true means case sensitive
 * false means case insensitive for HTML and case sensitive for other languages

See the two occurrences of "mCaseSensitive" in nsCSSRuleProcessor.cpp and the context around them.

However, for "i" we need a third state that is case-insensitive for all languages.  So fixing this properly requires turning nsAttrSelector::mCaseSensitive into an enum with 3 states.


As far as whether to ship this:  I think it's pretty stable at this point, and likely to go to CR pretty soon given https://lists.w3.org/Archives/Public/www-style/2015Jul/0296.html .  http://css4-selectors.com/selector/css4/attribute-case-sensitivity/ suggests other browsers haven't shipped it yet, although I'm not sure how current that is.

Is one of you interested in updating the patch, or should I do it?

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I'll see if I can carve out some time next week.

Comment 5

[yisibl]

(In reply to :Ms2ger from comment #4)
> I'll see if I can carve out some time next week.

WebKit has achieved most of the CSS Selector 4 functions.

Comment 6

[Philip Jägenstedt [:foolip]]

The "i" modifier will ship in Chrome 49:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/vAWK0ldpyrc/3I_RKXblAgAJ

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Rebased

Comment 8

[yisibl]

The "i" modifier will ship in Safari 9.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Note to self: the "trivial" patch attached above totally doesn't work.  It fails to even parse the relevant selectors.

Comment 10

[Boris Zbarsky [:bzbarsky]]

OK, so if I fix that, things are a bit better.  Next issue: the spec is light on detail in the usual way, so Chrome and Safari shipped non-interoperable implementations.  See https://lists.w3.org/Archives/Public/www-style/2016Jan/0166.html

I'm going to side with Chrome here, not least because the web platform tests do.  So accept 'i' but not 'I'.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Implement case-insensitive attribute value selectors from Selectors 4

OK, this actually works.  The web platform tests even have tests for the serialization bit, which was nice.  No new tests had to be written at all.  ;)

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8710855 [details] [diff] [review]
Implement case-insensitive attribute value selectors from Selectors 4

I guess I'll keep the needinfo on myself until dbaron is accepting review requests again...

Comment 13

[Boris Zbarsky [:bzbarsky]]

> I'm going to side with Chrome here

OK, spec editor says Chrome is wrong.  I guess I get the fun of updating the tests.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: Implement case-insensitive attribute value selectors from Selectors 4

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8710879 [details] [diff] [review]
Implement case-insensitive attribute value selectors from Selectors 4

Is there a Chromium bug filed?  And does somebody upstream that WPT change, or do you have to?  (If so, please do!)

r=dbaron

(I wonder if there are followups we should make for UA style sheet cleanups and/or conformance fixes.)

Comment 16

[Boris Zbarsky [:bzbarsky]]

> Is there a Chromium bug filed?

Yep.  https://code.google.com/p/chromium/issues/detail?id=580446 was filed as part of the www-style thread on this.

> And does somebody upstream that WPT change, or do you have to? 

jgraham upstreams them.  But also, since I wrote the patch this got fixed in wpt in https://github.com/w3c/web-platform-tests/commit/b62f9facbc5d0e56e79b9dee7958bed1d05826e9

If that gets merged to our tree before I land, I'll just adjust my patch appropriately.  If not, I'll update my patch such that it matches the upstream one, so hopefully the merge conflict jgraham gets (if any) is simple to resolve.

> (I wonder if there are followups we should make for UA style sheet cleanups and/or conformance fixes.)

Good question.  I'll think on this a bit.

Comment 17

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/53ea4b142e77

Comment 18

[Boris Zbarsky [:bzbarsky]]

> Good question.  I'll think on this a bit.

I haven't thought of anything so far.  Form stuff uses @value, which is matched case-insensitively anyway in HTML, and that's the obvious thing for which I know we need case-insensitivity.

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/53ea4b142e77

Comment 21

[Sebastian Zartner [:sebo]]

Documented the changes:
https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors
https://developer.mozilla.org/en-US/Firefox/Releases/Firefox_47_for_developers#CSS

Sebastian