W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 30 Aug 2010 08:35:03 -0400
Message-ID: <20100830123503.GA23871@pickering.dbaron.org>
On Monday 2010-08-30 14:28 +0200, Anne van Kesteren wrote:
> On Sun, 29 Aug 2010 15:01:27 +0200, L. David Baron
> <dbaron at dbaron.org> wrote:
> >On Wednesday 2010-08-25 10:28 +0200, Anne van Kesteren wrote:
> >>We need a feature for case-insensitive matching in Selectors already
> >>for XHTML (if we really care about this, not sure we do).
> >
> >Allowing case-insensitive matching beyond matching of a fixed set of
> >ASCII-only values seems scary.
> >
> >If such a general selectors feature were defined as ASCII-only, then
> >it would appear to work but then break for cases where it needed to
> >be more than ASCII-only (or where the standard ASCII-only algorithm
> >is incorrect, such as Turkish, where where I/i are not
> >case-equivalents; ?/i and I/? are).
> >
> >If it weren't ASCII-only, it would involve significantly more
> >complexity than what's needed to support HTML.
> I think it can be ASCII-only. You "need" it for input[type=password]
> and such. The only attributes that are currently "compatibility
> caseless" are name on <input type=radio> and name on <map>.

But the problem with adding a new general selectors feature is that
authors will discover it and try to use it for things that aren't ok
being ASCII-only.


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Monday, 30 August 2010 05:35:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:26 UTC