Closed Bug 12386 Opened 20 years ago Closed 19 years ago

Matching of case sensitive attribute values should be case sensitive

Categories

(Core :: CSS Parsing and Computation, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: dbaron, Assigned: pierre)

Details

(Keywords: css2, Whiteboard: [fix in hand] (py8ieh: verify with <foo title="sensitive"/> <foo media="sensitive"/> <html:p media="insensitive"/>))

Attachments

(2 files)

DESCRIPTION:  Attribute selectors with values of case sensitive attributes in
HTML should cause case-sensitive matching.  They aren't.  That is,

[title="A"]

is matching

<p title="a">text</p>

This is wrong because title is defined in HTML to be case sensitive "[CS]"
( http://www.w3.org/TR/REC-html40/struct/global.html#adef-title ).  CSS2 5.8.1
( http://www.w3.org/TR/REC-CSS2/selector.html#q10 ) says that "The
case-sensitivity of attribute names and values in selectors depends on the
document language."

This probably applies to some other attributes too.  I imagine this could be a
pain to deal with...

STEPS TO REPRODUCE:  Load attached test case.

ACTUAL RESULTS:  First line is red.

EXPECTED RESULTS:  It shouldn't be red.

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-08-20-13-M10
ALSO DOES NOT WORK CORRECTLY ON:
 * Windows, apprunner, 1999-08-24-09-M10
Pushing off non-beta 1 issues
Summary: Matching of case sensitive attribute values should be case sensitive → {css2} Matching of case sensitive attribute values should be case sensitive
Reassigning peterl's bugs to myself.
Accepting peterl's bugs that have a Target Milestone
Pushing my M15 bugs to M16
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Summary: {css2} Matching of case sensitive attribute values should be case sensitive → Matching of case sensitive attribute values should be case sensitive
See bug 24390 for recent changes to this code.  I imagine it's still wrong.
Target Milestone: M16 → M17
It would be nice if we could fix this before RTM, because it would be 
unfortunate to cause content developers to create a bunch of content that 
depends on case-insensitivity, not knowing that this is incorrect, only to have 
all that web content break when we fix this bug at a later date. Falls into the 
category of "let's fix this problem up front rather than creating a headache for  
ourselves down the road."

HOWEVER, we could just document this issue and educate content developers to do 
the right thing, so if we run out of time, this can be marked FUTURE and 
relnote. Top priority is making sure content developers *can* do the right 
thing. Making sure they *can't* do the *wrong* thing is a much lower priority. 
Caveat emptor.
Block moved M17 bugs to mozilla0.9
Target Milestone: M17 → mozilla0.9
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Chris, Marc: please review the attached fix.

I tested against the testcase above + the one in bug 24390 and also ran the app a 
little bit.
Whiteboard: [fix in hand]
Attached patch fixSplinter Review
I'll remove the tabs from the patch before I check in...
sr=waterson
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [fix in hand] → [fix in hand] (py8ieh: verify with <foo title="sensitive"/> <foo media="sensitive"/> <html:p media="insensitive"/>)
HTML issue, -> bindu
QA Contact: ian → bsharma
Updated QA contact
QA Contact: bsharma
verifying this withthe attached testcase 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.