Feedback wanted on bug: remove case-insensitive attribute value matching

[Simon Pieters]

In https://code.google.com/p/chromium/issues/detail?id=327060 I suggest
that we make attribute values in Selectors be case-sensitive by default.
This might break some sites, hence this thread.


== Background ==

Currently, some HTML attributes match their values case-insensitively in
Selectors. For example:

<input type="text">

input[type="TEXT"] { ... }

matches. This seems fine on the face of it, but the behavior in browsers
is a bit unintuitive: for performance reasons (I presume) the tag name is
not checked, only the attribute name, so e.g. <ol type="i"> or <span
type="foo"> are also case-insensitive even though <ol type> is
case-sensitive in HTML and <span type> doesn't exist. Also, this list of
case-insensitive attributes only includes "old" attributes and not e.g.
<video preload="auto"> despite that being a case-insensitive attribute in
HTML.

Selectors supports a way for authors to opt-in to case-insensitive
attribute values with an "i" flag:

input[type="TEXT" i] { ... }


== Proposal ==

Implement the "i" flag in Selectors, use it in the UA stylesheet (as
specified in the HTML spec), and make attribute values case-sensitive in
Selectors.

Old spec: http://www.whatwg.org/specs/web-apps/2009-10-27/#selectors

New spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#case-sensitivity

Spec for "i": http://dev.w3.org/csswg/selectors4/#attribute-case


== Impact ==

The Web compatibility impact of this change is not yet known. No other
browser has implemented this yet.

There exist tests that expect the current behavior that would need to be
updated, e.g. http://www.css3.info/selectors-test/

This would improve performance of Selector matching according to Jens
Lindström: the performance test in crbug.com/315087 changes from 160
runs/s to 195 runs/s.

The behavior for attribute value selectors becomes more predictable for
authors and consistent between different attributes.


== Next steps ==

If the community doesn't strongly object to this idea I think the first
order of business would be to get a better idea of the Web compat impact,
probably by adding a use counter that triggers if an attribute value
selector matches and the case was different. It might be useful to count
different attributes separately in case we have to keep the list but want
to make as short as possible.

Feedback welcome.

--
Simon Pieters
Opera Software

[Eric Seidel]

I like the idea of case-sensitivity from a simplicity/performance
perspective. Presumably we could use-count the number of pages
affected by counting every time a match succeeds that would not have
succeeded case-sensitive? If we're using AtomicString the
case-sensitive part is just a pointer compare.

[Nico Weber]

Are these case-sensitive in HtmL? No, right?

[Mathias Bynens]

On Fri, Jan 17, 2014 at 8:20 PM, Nico Weber <tha...@chromium.org> wrote:
> Are these case-sensitive in HtmL? No, right?

Attributes and enumerable attribute values are generally
case-insensitive in HTML.

[Tab Atkins Jr.]

On Fri, Jan 17, 2014 at 4:19 AM, Simon Pieters <sim...@opera.com> wrote:

> If the community doesn't strongly object to this idea I think the first
> order of business would be to get a better idea of the Web compat impact,
> probably by adding a use counter that triggers if an attribute value
> selector matches and the case was different. It might be useful to count
> different attributes separately in case we have to keep the list but want to
> make as short as possible.

I strongly support making this change, subject to the UseCounter data.
If UseCounter says that we can't reliably do this, I support still
implementing the "i" flag, but also specifying the case-insensitive
behavior.

~TJ

[Simon Pieters]

On Fri, 17 Jan 2014 20:20:24 +0100, Nico Weber <tha...@chromium.org> wrote:

> Are these case-sensitive in HtmL? No, right?

<ol type> is case-sensitive in HTML but is in the list because type on
other elements is case-insensitive in HTML. Some attributes in the list
have no effect (e.g. axis), some are boolean attributes which ignore the
value (e.g. selected), some are case-insensitive but are obsolete (e.g.
bgcolor).

[Jens Lindström]

On Fri, Jan 17, 2014 at 7:42 PM, Eric Seidel <ese...@chromium.org> wrote:
> I like the idea of case-sensitivity from a simplicity/performance
> perspective. Presumably we could use-count the number of pages
> affected by counting every time a match succeeds that would not have
> succeeded case-sensitive? If we're using AtomicString the
> case-sensitive part is just a pointer compare.

I uploaded a patch adding such use-counting:

https://codereview.chromium.org/140323003/

It needs some reviewing attention. :-)

It does affect matching performance (both positively and negatively)
but hopefully we can go with it anyway. I would guess (but have no
data) that attribute selectors are not overwhelmingly common in the
first place.

--
Jens