286565 - Allow case insensitive matches for anchor names in quirks mode

Status: RESOLVED INVALID

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

Description

[Aaron Leventhal]

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.

Comment 1

[Aaron Leventhal]

See also bug 177269, although according to that the spec says radio buttons
*should* be case insensitive.

Comment 2

[Aaron Leventhal]

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.

Comment 3

[Aaron Leventhal]

Attachment: In quirks mode use new MatchNameAttributeIgnoreCase() for comparison function

Comment 4

[Aaron Leventhal]

Attachment: Simple testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

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?

Comment 6

[Aaron Leventhal]

(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?

Comment 7

[Bob Clary [:bc] (inactive)]

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.

Comment 8

[Aaron Smith]

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.

Comment 9

[Aaron Leventhal]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 12

[Mats Palmgren (inactive)]

(In reply to comment #10)
> I seem to recall that it did, but I can't find the relevant bug

bug 241063 perhaps?

Comment 13

[Aaron Smith]

(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.

Comment 14

[Aaron Leventhal]

(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.

Comment 15

[Aaron Smith]

(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 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 18

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Invalid per spec: <http://www.whatwg.org/html/#the-indicated-part-of-the-document>.