NavQuirk: ID and CLASS shouldn't be case-sensitive

VERIFIED WONTFIX

Status

()

P3
normal
VERIFIED WONTFIX
19 years ago
18 years ago

People

(Reporter: pierre, Assigned: pierre)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

19 years ago
An article about Netsape 6.0 in Macworld reports that WebbedEnvironments.com 
doesn't render correctly with Mozilla while it displays just fine with Nav4x and 
IE4.5 or IE5. The article is at
   http://macworld.zdnet.com/2000/04/06/netscapenewdir.html

I looked into it and found the following error: in css/interface1.css, they
define "#scrollarea" but in home/index.html, they use <div id="scrollArea">.
The problem is that IDs are supposed to be case-sensitive:
   http://www.w3.org/TR/html4/struct/global.html#adef-id

I'll implement a quirk to make IDs and CLASSes case-insensitive because that's 
how all the current browsers work.
(Assignee)

Comment 1

19 years ago
Just in case, I'm sending a separate mail to rickg and troy asking for approval 
to implement that quirk.
Status: NEW → ASSIGNED
Target Milestone: --- → M16
(Assignee)

Comment 2

19 years ago
And the quirk would be for HTML content only...
(Assignee)

Comment 3

19 years ago
I'm giving up on that one. It requires 3 kinds of changes.
- The first one is fine: for the IDs to be case-insensitive, we have to do in 
SelectorMatches() the same kind of thing we already do for bug 24390 (see the 
comments in the function).
- The second one is fine too: for the classes to be case-insensitive, we should 
pass in HasClass() a boolean to specify if the string compare done at a lower 
lever should be case-sensitive or not, depending on whether we are in quirks mode 
and inside a HTML content. It requires changing several interfaces but it's still 
ok.
- The last change is more tricky. In RuleHash::EnumerateAllRules(), we keep hash 
tables for IDs and classes. These ones can't easily be made case-sensitive 
depending on the content and the compatibility mode. We can alwyas find a 
solution but it would be a bit hacky and hurt the performance, so I prefer to 
give up on that quirk. We may reconsider if other sites show the same problem. 
This one was fixed yesterday by the webmaster. Marking as LATER.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → LATER
(Assignee)

Comment 4

19 years ago
I'm going to attach a testcase based on the original version of 
www.webbedenvironments.com. The faulty ID is declared as "scrollarea" and used as 
"scrollArea".
(Assignee)

Comment 5

19 years ago
Created attachment 7606 [details]
testcase
(Assignee)

Comment 6

19 years ago
*** Bug 35878 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 7

19 years ago
Reopened: <http://www.eff.org/> has some case-insensitive CLASSes (bug 37831).
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: M16 → M17
(Assignee)

Updated

19 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 8

19 years ago
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another known 
resource will be working on this bug, or if it blocks your work in some way -- 
please attach your concern to the bug for reconsideration. 
Target Milestone: M17 → Future
Resolving WONTFIX. If we're not implementing a given NavQuirk for RTM, there's 
really not much point in implementing it post-RTM as content developers will 
have already had to fix their content to support RTM, and even if we implement 
the quirk for (say) 6.1, they'd still be faced with the need to fix their 
content to support the installed base of 6.0 browsers during the transition.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 10

19 years ago
*** Bug 44867 has been marked as a duplicate of this bug. ***
VERIFIED WONTFIX.

This is a compatability issue, but since we are not fixing it for this release,
web authors will have to write their markup to work around the way we render it
regardless of whether we 'fix' it in the future or not. Thus, fixing it in the
future is a waste of our time.

Note that the markup is invalid anyway; so the workaround is simply to fix the
page in question.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.