Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Sun, 29 Aug 2010 15:01:27 +0200, L. David Baron dba...@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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Monday 2010-08-30 14:28 +0200, Anne van Kesteren wrote: On Sun, 29 Aug 2010 15:01:27 +0200, L. David Baron dba...@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. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Mon, 30 Aug 2010 14:35:03 +0200, L. David Baron dba...@dbaron.org 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wednesday 2010-08-25 10:28 +0200, Anne van Kesteren wrote: On Wed, 25 Aug 2010 09:44:34 +0200, Christoph Päper christoph.pae...@crissov.de wrote: I for one would expect that selector to match that element, although I would never write HTML like that. Imagine a browser or user stylesheet where you would effectively have to list all possible casings. 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. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
Anne van Kesteren: On Wed, 25 Aug 2010 01:00:50 +0200, Ian Hickson i...@hixie.ch wrote: 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. I for one would expect that selector to match that element, although I would never write HTML like that. Imagine a browser or user stylesheet where you would effectively have to list all possible casings. That is, I expect attribute values that are predefined keywords to match no matter how I case them, because they are semantic – well, ‘center’ not so much –, but arbitrary strings should be case-insensitive unless specified otherwise (which is not possible in Selectors 3). I still think matching on attribute values in Selectors for HTML should always be case-sensitive and we should not have a magic list. How about “[align=center]” being case-sensitive and “[align=center]” being case-agnostic? ;)
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wed, 25 Aug 2010 09:44:34 +0200, Christoph Päper christoph.pae...@crissov.de wrote: I for one would expect that selector to match that element, although I would never write HTML like that. Imagine a browser or user stylesheet where you would effectively have to list all possible casings. We need a feature for case-insensitive matching in Selectors already for XHTML (if we really care about this, not sure we do). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Thu, 29 Jul 2010, Anne van Kesteren wrote: On Wed, 28 Jul 2010 01:32:13 +0200, Ian Hickson i...@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 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wed, 25 Aug 2010 01:00:50 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Jul 2010, Anne van Kesteren wrote: On Wed, 28 Jul 2010 01:32:13 +0200, Ian Hickson i...@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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wed, 28 Jul 2010 01:32:13 +0200, Ian Hickson i...@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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Thu, 1 Apr 2010, L. David Baron wrote: On Thursday 2010-04-01 23:10 -0700, wha...@whatwg.org wrote: [giow] (0) The CSS rules need to do attribute value matching consistently across HTML and XHTML, despite the rules for interpreting author style sheets. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9335 + p id=case-sensitive-selector-exceptionFor the purpose of the + rules marked case-sensitive, user agents are expected to use + case-sensitive matching of attribute values rather than + case-insensitive matching, regardless of whether a case-insensitive + matching is normally required for the given attribute./p + + p id=case-insensitive-selector-exceptionSimilarly, for the + purpose of the rules marked case-insensitive, user agents are + expected to use spanASCII case-insensitive/span matching of + attribute values rather than case-sensitive matching, even for + attributes in XHTML documents./p + + p class=noteThese markings only affect the handling of attribute + emvalues/em, not attribute names or element names./p Making attribute values case-insensitive in XHTML seems incompatible with longstanding Gecko behavior (though our handling of input's type attribute is buggy, at least) and with the clear intent of XHTML1, and doesn't seem implementable on top of a conformant CSS selectors implementation. 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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Thursday 2010-04-01 23:10 -0700, wha...@whatwg.org wrote: [giow] (0) The CSS rules need to do attribute value matching consistently across HTML and XHTML, despite the rules for interpreting author style sheets. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9335 + p id=case-sensitive-selector-exceptionFor the purpose of the + rules marked case-sensitive, user agents are expected to use + case-sensitive matching of attribute values rather than + case-insensitive matching, regardless of whether a case-insensitive + matching is normally required for the given attribute./p + + p id=case-insensitive-selector-exceptionSimilarly, for the + purpose of the rules marked case-insensitive, user agents are + expected to use spanASCII case-insensitive/span matching of + attribute values rather than case-sensitive matching, even for + attributes in XHTML documents./p + + p class=noteThese markings only affect the handling of attribute + emvalues/em, not attribute names or element names./p Making attribute values case-insensitive in XHTML seems incompatible with longstanding Gecko behavior (though our handling of input's type attribute is buggy, at least) and with the clear intent of XHTML1, and doesn't seem implementable on top of a conformant CSS selectors implementation. Do we really want to do this? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Thu, 01 Apr 2010 23:36:16 -0700, L. David Baron dba...@dbaron.org wrote: Making attribute values case-insensitive in XHTML seems incompatible with longstanding Gecko behavior (though our handling of input's type attribute is buggy, at least) and with the clear intent of XHTML1, and doesn't seem implementable on top of a conformant CSS selectors implementation. Do we really want to do this? I think we do want case-insensitive attribute values to be case-insensitive in both HTML and XHTML. I think ideally we remove the special casing of certain attributes with Selectors and introduce an ASCII case-insensitive flag for attribute value selectors to deal with this issue. -- Anne van Kesteren http://annevankesteren.nl/
