Closed Bug 286565 Opened 20 years ago Closed 14 years ago

Allow case insensitive matches for anchor names in quirks mode

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: aaronlev, Unassigned)

Details

(Keywords: access)

Attachments

(2 files)

Technically this is not just a keyboard bug, but I couldn't think of a better component. When jumping to a named anchor link, currently we follow the W3C HTML 4.01 spec strictly and will not succeed if there is only a case insensitive match. For example <a href="#SkipNav"/> will not jump to <a name="skipnav">. This causes a problem for pages which are coded for IE. The above examples was taken from audible.com. I recommend that in quirks mode we allow cae insensitive matches.
See also bug 177269, although according to that the spec says radio buttons *should* be case insensitive.
Changing GetElementsByName() to respond to quirks mode would also affect document.all, but I think that is probably good since document.all is an IE'ism, it should act like IE anyway.
Component: Keyboard: Navigation → DOM
Attachment #177737 - Flags: superreview?(jst)
Attachment #177737 - Flags: review?(bzbarsky)
Attached file Simple testcase
Whoa there. GetElementsByName is used in a LOT of places (both in our UI in editor, and out on t he web). It's a DOM api. It's NOT just used for scrolling to anchors. Not only that, but this case-insensitivity of anchors thing has come up before, and been rejected, iirc. Is this really such a huge problem on so many sites that we have to introduce a quirk, break all existing callers of this method, etc?
(In reply to comment #5) > Whoa there. GetElementsByName is used in a LOT of places (both in our UI in > editor, and out on t he web). It's a DOM api. It's NOT just used for scrolling to anchors. This is just a proposal. I realize that it's also used in document.all -- but that is an IE-ism already and this makes us more like IE there, which is good. Looking at where it's used in LXR I don't see any problems: I don't think the UI is in quirks mode, and I don't see any problems with changing this with respect to editor. Perhaps the proposal before didn't include the idea to do this just for quirks mode?
I don't have a deep feeling either way on this other than it should not break anything. I would like to know the previous arguments for and against this change. I would also like some quantification on the benefits this change might bring about. For example, out of the top 70 sites and the pages linked to from their home pages, how many pages would see a benefit from this? Using the techniques I have used in the past would allow you to check intrapage links but not interpage links. I don't have time to run the scan at the moment but could easily help someone else do it.
A quick google search for skipnav shows the occasional site using mixed case in their anchors, but whether or not their matching names/ids are also mixed is not immediately clear. I'm inclined to believe that their code was generated by a third party utility (the numerous blank lines at the top are usually a dead giveaway) rather than coded by hand, so if there's an application out there that enables this problem, you can bet it's going to happen more than just once. How often, however, is anyone's guess, and not really something that can be measured easily. I know in our own development, we've run across situations where we've said, "Surely that type of senseless thinking is limited to one person," only to find more sites that exhibted the same problem.
Certainly acting like IE only when in quirks mode is the point of quirks mode. I don't see how we could break sites that are doing this if IE supports it.
> I don't think the UI is in quirks mode The UI is not; the document it's editing (which is what the call is being done on) could be. And again, this isn't just about document.all. You're changing the behavior of our W3C DOM implementation as well. See http://www.google.com/search?q=getElementsByName > Perhaps the proposal before didn't include the idea to do this just for quirks > mode? I seem to recall that it did, but I can't find the relevant bug (the only bugs a quick search shows are bug 208656 and bug 154754). > Certainly acting like IE only when in quirks mode is the point of quirks mode. No. The point of quirks mode is to act like IE as necessary to avoid breaking pages too badly. Emulating every single IE quirk and bug is not the point. Hence the question about how common this issue is. If it's not common, the cost of having multiple codepaths doesn't seem worthwhile. > I don't see how we could break sites that are doing this if IE supports it. Not all sites code with IE in mind, frankly (especially true of intranets). One other question I have -- does IE's behavior depend on whether it's in quirks mode?
If there aren't significant numbers of real[*] web pages that are broken by this problem, then there shouldn't be a quirk. * real means that the bug was reported by a user of the page rather than the author
(In reply to comment #10) > I seem to recall that it did, but I can't find the relevant bug bug 241063 perhaps?
(In reply to comment #11) > * real means that the bug was reported by a user of the page rather than the author FWIW, this bug was initially reported by a user of audible.com (a site heavily used by people who are visually impaired, who in turn heavily lean on same page links). He, like most users, just wants the @#$%! thing to work. In IE it does (unfortunately); in Firefox it does not. At least, that's what it appears like to users as they fire up IE to help them spend their money at Audible. Despite the fact that this is a flagrant standards violation on the part of IE, it's one that provides visually imapired users better access to the page. That's one quirk that I would be in favor of.
(In reply to comment #13) > (In reply to comment #11) > That's one quirk that I would be in favor of. The architects on this bug are being reasonable. We need to answer their questions satisfactorily before we take any additional steps.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) > > That's one quirk that I would be in favor of. > The architects on this bug are being reasonable. We need to answer their > questions satisfactorily before we take any additional steps. Oh, I absolutely agree. I just feel the bug is important enough to add a little pathos (working daily with people who rely on even the most trivial things makes me a tad biased; I appologize for that). But I also agree completely that empirical data is necessary before anything changes. And I do appreciate the open-mindedness of those in charge of any potential changes.
Comment on attachment 177737 [details] [diff] [review] In quirks mode use new MatchNameAttributeIgnoreCase() for comparison function I think we can all agree that this patch is not the solution in either case. *If* we want to have a quirk here it should only affect scrolling, which this patch does not.
Attachment #177737 - Flags: superreview?(jst)
Attachment #177737 - Flags: review?(bzbarsky)
Attachment #177737 - Flags: review-
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
QA Contact: bugzilla → general
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: