Add support for case-insensitive attribute value selectors

Add support for case-insensitive attribute value selectors

Selectors Level 4 adds the syntax '*[foo="bar" i]' for making an attribute
value selector case-insensitive.  Add support for that.

BUG=366563

[Jens Widell, 2014-04-28 14:12:56]

Please take a look.

First of all: please shout if you think that I should send an "intent to
implement" on this.

The reason I implemented this is that the counter added to investigate whether
http://crbug.com/327060 (dropping the auto-case-insensitivity on some HTML
attributes) can be fixed is triggered by the user agent stylesheet, and is thus
currently producing somewhat meaningless data.

With support for this case-insensitivity syntax, the user agent stylesheet can
be adjusted to use it instead of relying on the auto-case-insensitivity, which
would make the counter data more meaningful.  (Fixing the user agent stylesheet
this way is of course also a prerequisite for actually fixing 327060.)

[apavlov, 2014-04-28 15:58:40]

Grammar and Bison parser lgtm

[rune, 2014-04-28 19:18:49]

On 2014/04/28 14:12:56, Jens Lindström wrote:
> Please take a look.
> 
> First of all: please shout if you think that I should send an "intent to
> implement" on this.

Yes, I think so. You don't even have a runtime flag for it, so you're "shipping"
with this CL.

[Jens Widell, 2014-05-06 14:15:55]

On 2014/04/28 19:18:49, rune wrote:
> On 2014/04/28 14:12:56, Jens Lindström wrote:
> > Please take a look.
> > 
> > First of all: please shout if you think that I should send an "intent to
> > implement" on this.
> 
> Yes, I think so. You don't even have a runtime flag for it, so you're
"shipping"
> with this CL.

I've added a runtime flag, so no longer shipping it.

I made the new syntax available to UA stylesheets always, since the main idea is
to use it there instead of relying on automatic case-insensitivity.

It can be noted that the case-insensitivity is incorrectly implemented; the
specification says "case-insensitive within ASCII range" whereas this CL makes
selectors "unicode case-insensitive".  I couldn't find any ASCII
case-insensitivity utility functions.  If there aren't any, doing it right will
mean duplicating a whole bunch of string functions.  Also, we get
case-insensitivity wrong the same way in other places as well, so not a new
issue, really.

[eseidel, 2014-05-07 18:11:39]

If this shoudl only be ASCII case insensitive, then I would recommend that we
only do that.  ASCII case insensitive is much simpler/faster/easier than unicode
case sensitivity.

[eseidel, 2014-05-07 18:12:58]

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
File Source/core/css/CSSSelector.h (right):

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
Source/core/css/CSSSelector.h:268: unsigned attributeFlags() const;
Can't this return the enum?  Normally we store enums as unsigned (bitfields) but
cast them to/from their enum type in getters/setters to allow the rest of the
code to use the compiler's type-safety.

[eseidel, 2014-05-07 18:12:58]

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
File Source/core/css/CSSSelector.h (right):

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
Source/core/css/CSSSelector.h:268: unsigned attributeFlags() const;
Can't this return the enum?  Normally we store enums as unsigned (bitfields) but
cast them to/from their enum type in getters/setters to allow the rest of the
code to use the compiler's type-safety.

[Jens Widell, 2014-05-07 18:17:40]

On 2014/05/07 18:11:39, eseidel wrote:
> If this shoudl only be ASCII case insensitive, then I would recommend that we
> only do that.  ASCII case insensitive is much simpler/faster/easier than
unicode
> case sensitivity.

I agree, but couldn't find existing utility functionality. That's not difficult
to implement, obviously, but does mean a larger patch. Will do that, if you
prefer we do it all in one patch.

[eseidel, 2014-05-29 00:23:43]

Honestly, I consider this a mis-feature of CSS.  I think this is an easy
foot-gun for authors.

I am not surprised this is what the spec says, but the bigger question in my
mind is if we're moving closer or further from other browsers.  HTML is not
case-sensitive (mostly), but XML is.  client-side XML (at least as a
display-format) is going the way of the dodo... slowly.

If this is an XHTML-only feature and *especially* if other browsers don't
implement this, I recommend we just get CSS changed to always be case
insensitive.

[eseidel, 2014-05-29 00:24:07]

Oh, I misread.  I guess they're always case sensitive now, this patch is about
adding insensitivity.

[eseidel, 2014-05-29 00:25:00]

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
File Source/core/css/CSSSelector.h (right):

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
Source/core/css/CSSSelector.h:346: unsigned m_attributeFlags; // used for
attribute selector (with value)
I think we have a ton of CSSSelector objects... I worry this could be bad for
memory?  Ojan would know.

[apavlov, 2014-06-11 12:26:19]

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
File Source/core/css/CSSSelector.h (right):

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
Source/core/css/CSSSelector.h:346: unsigned m_attributeFlags; // used for
attribute selector (with value)
On 2014/05/29 00:25:01, eseidel (OOO until June 16) wrote:
> I think we have a ton of CSSSelector objects... I worry this could be bad for
> memory?  Ojan would know.

This is RareData. Consequently, it will be found in a small fraction of all
CSSSelectors...

[fs, 2014-06-12 16:42:31]

Attempted to resuscitate this at [1] since jl has been otherwise engaged
recently.

[1] https://codereview.chromium.org/330043003/

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
File Source/core/css/CSSSelector.h (right):

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
Source/core/css/CSSSelector.h:268: unsigned attributeFlags() const;
On 2014/05/07 18:12:58, eseidel (OOO until June 16) wrote:
> Can't this return the enum?  Normally we store enums as unsigned (bitfields)
but
> cast them to/from their enum type in getters/setters to allow the rest of the
> code to use the compiler's type-safety.

Sure (done in [1]). It doesn't really add much in terms of type-safety though
(all uses as of now imply widening conversions). Having a flag-field with a
single flag might be a bit overkill though =)

https://codereview.chromium.org/252683011/diff/80001/Source/core/css/CSSSelec...
Source/core/css/CSSSelector.h:346: unsigned m_attributeFlags; // used for
attribute selector (with value)
On 2014/06/11 12:26:19, apavlov wrote:
> On 2014/05/29 00:25:01, eseidel (OOO until June 16) wrote:
> > I think we have a ton of CSSSelector objects... I worry this could be bad
for
> > memory?  Ojan would know.
> 
> This is RareData. Consequently, it will be found in a small fraction of all
> CSSSelectors...

Yes, hopefully they are indeed "rare". Disregarding that though there's (at
least) two ways to pack this differently:

1) Move the field to the bitfield in CSSSelector (it's only 1 bit right now, and
there seems to be 10 bits left there).
2) Make a union of this and m_a/m_b.

Both of those will cause some "collateral damage" though
(renaming/initializer-lists/etc.)

Any preference there? ((2) sketched out in [1])