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

On Wed, 25 Aug 2010, Anne van Kesteren wrote:
> On Wed, 25 Aug 2010 01:00:50 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 29 Jul 2010, Anne van Kesteren wrote:
> > > On Wed, 28 Jul 2010 01:32:13 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > > > I've been working under the assumption that we want to eradicate as
> > > > many differences between XHTML and HTML as possible, and that there's
> > > > virtually no compatibility constraint on the XHTML side.
> > > > 
> > > > If this is an area where we should keep the differences, though, I'm
> > > > quite happy to change the spec accordingly.
> > > > 
> > > > Do any other browser vendors have opinions here? Are there
> > > > compatibility constraints I'm not aware of?
> > > 
> > > I still think we should make matching on values always case-sensitive,
> > > including in HTML.
> > 
> > Does that not have compatibility problems? e.g. I'm sure people do:
> > 
> >   <P ALIGN=CENTER> ... </P>
> 
> Sure, but I highly doubt people do that and expect
> 
>  p[align=center]
> 
> to work, especially since that has not always worked in all browsers. 
> (Other than some popular Selectors test suite.)
> 
> 
> To clarify, what I meant to say is that I still think matching on 
> attribute values in Selectors for HTML should always be case-sensitive 
> and we should not have a magic list.

On Wed, 25 Aug 2010, 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).

On Sun, 29 Aug 2010, L. David Baron wrote:
> 
> 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.

On Mon, 30 Aug 2010, Anne van Kesteren wrote:
> 
> 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>.

On Mon, 30 Aug 2010, L. David Baron wrote:
>
> 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.

On Mon, 30 Aug 2010, Anne van Kesteren wrote:
>
> Yeah, maybe. But we could define it as some kind of token feature. As 
> far as I know we do not have any markup languages which use 
> compatibility caseless tokens. And hopefully we are not going to 
> introduce any either.
> 
> Alternatively you could have something like input:type(password) I 
> suppose. Would work slightly better for unknown controls that fallback 
> to text, too.
> 
> Or even more alternatively we could decide not to care about this being 
> difficult to select since in practice people will use lowercase values.

I haven't changed anything based on this discussion. I'm happy to change 
HTML to be whatever browsers end up implementing if it's different than 
what we have now, so long as we end up with convergence. I'm also happy to 
change the spec's text here pre-emptively on instruction from either the 
CSSWG or implementors, if we think that that would help with interop.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 6 December 2010 16:55:21 UTC