Closed Bug 672171 Opened 13 years ago Closed 9 years ago

remove case-insensitive attribute value matching

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: annevk, Unassigned)

Details

Rather than having a magic list of attribute names whose value needs to be matched ASCII case-insensitively in HTML I think it would be better if attribute values were always matched case-sensitively.

If both Gecko and Opera do this I think we can get WebKit along and get the magic list removed from the HTML specification.

(The CSS WG indicated this was up to the markup language, fwiw.)
Our UA style sheet depends on this to function correctly, so if we wanted to do this we'd need to add a -moz- syntax for case insensitive matching, somehow.

I'm also skeptical that this is "better" -- HTML as a language has many attribute values that are case sensitive, and this would basically make it so that authors can't reasonably address HTML as a language using CSS selectors (unless we had syntax for case-sensitive matching and case-insensitive matching).
New attributes with case-insensitive values (e.g. preload) are not on the list and I believe the plan was to not expand the list over time.

As for UA style sheets, you need special handling there if you want this to work correctly in an XML context anyway. E.g. input[type=button] will not style <input type="BUTTON"/>. It looks like Gecko actually has a bug here:

data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><input type="BUTTON"/><input type="button"/></html>
(In reply to comment #2)
> As for UA style sheets, you need special handling there if you want this to
> work correctly in an XML context anyway. E.g. input[type=button] will not
> style <input type="BUTTON"/>. It looks like Gecko actually has a bug here:
> 
> data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><input
> type="BUTTON"/><input type="button"/></html>

That distinction isn't coming from CSS selectors.

The CSS selector matching code is correct in only applying the case-insensitivity to HTML and not XHTML (i.e., all tests of nsAttrSelector::mCaseSensitive are ||ed with !isHTML).
Yes, but the attribute values are case-insensitive in XHTML too, so any UA style sheet rules that need case-insensitive attribute value matching would need to have -moz- syntax to make the XHTML scenario work.
Really?  They were case-sensitive in XHTML1.  Is XHTML5 changing that?  Why?
To make HTML and XHTML just syntax for a language defined in terms of the DOM (more consistency).
Maybe we should add a new selector for matching case-insensitively, e.g. (just making up a syntax here)

[foo:=bar] value is bar case-insensitively 
[foo^:=bar] value beings with bar case-insensitively
[foo$:=bar] value ends with bar case-insensitively
[foo*:=bar] value contains bar case-insensitively

Then we could remove the magic list and use := selectors in the UA style sheet and have it work for both HTML and XHTML, and also allow authors to write selectors for new features like preload and allow them to write selectors that work in XHTML. But this would need to be proposed to www-style.
This is getting restored in HTML: https://github.com/whatwg/html/pull/74.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.