Bug 13335

Summary: html page anchor not always working (case sensitive problem)
Product: WebKit Reporter: Lachlan Deck <lachlan.deck>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Minor CC: ahmad.saleem792, ap, charles, darin, hyatt, mjs, webkit, webkit-bugs
Priority: P2    
Version: 523.x (Safari 3)   
Hardware: Mac   
OS: OS X 10.4   
URL: http://maven.apache.org/pom.html#Dependencies

Description Lachlan Deck 2007-04-11 14:34:29 PDT
Seems that the lookup is not case insensitive. The named anchor on the above url is "dependencies" rather than <a name="Dependencies">...
Comment 1 Rosyna 2007-06-25 21:31:46 PDT
This also happens with Wikipedia links

http://en.wikipedia.org/wiki/Bratz_%28dolls%29#Culture_confusion

vs

http://en.wikipedia.org/wiki/Bratz_%28dolls%29#Culture_Confusion

But we got this. http://www.w3.org/TR/html401/struct/links.html#edef-A

Which says

ILLEGAL EXAMPLE: 
The following example is illegal with respect to uniqueness since the two names are the same except for case:

<P><A name="xxx">...</A>
<P><A name="XXX">...</A>

And then says

Although the following excerpt is legal HTML, the behavior of the user agent is not defined; some user agents may (incorrectly) consider this a match and others may not.

<P><A href="#xxx">...</A>
...more document...
<P><A name="XXX">...</A>

So it seems to be undefined behaviour.

IE6 and IE7 treats anchors as case-insensitive. Firefox and Webkit treat them as case-sensitive.

Since the first example above is illegal then it'd make sense to allow them to be case-sensitive (also, because paths are evil, but that has nothing to do with this issue).
Comment 2 Rosyna 2007-06-25 21:46:35 PDT
oopsie, made a small huge typo.

Since the first example above is illegal then it'd make sense to allow anchors to be *case-insensitive* (also, because paths are evil, but that has nothing to do with this issue).

And because people keep asking, I used that page because of http://www.apple.com/trailers/lions_gate/bratz/
Comment 3 Charles Gaudette 2007-06-26 02:26:56 PDT
I did a browser survey, with the two Wikipedia links, opening each in its own tab.

Internet Explorer 7 (7.0.5730.11) on Win .... insensitive
Safari 3.0.2 (522.12) beta on Mac with WebKit r23772.... sensitive
Firefox 3.0a5 on Win .... sensitive
Firefox 3.0a5pre on Mac .... sensitive
Firefox 2.0.0.4 on Mac .... sensitive
Opera 9.21 Build 3678 on Mac .... sensitive
MSIE 5.2.3 for Mac (circa 2001) .... insensitive

Safari 3.0.2 beta 3.0.2 on Win was buggy. With http://en.wikipedia.org/wiki/Bratz_%28dolls%29#Culture_confusion it is first showing the top of the page, then you close the tab, and pop the link into a new tab and you get the bottom of the page. This is a known issue.

(Win = Microsoft Windows XP Pro w/ SP2, Mac = Mac OS X 10.4.10 US)

Comment 4 Lachlan Deck 2007-06-26 13:53:17 PDT
I'd be leaning towards thinking about "What does the average non-technical user expect to happen?" rather than what does the average browser currently do in this situation as interesting as that is.

I would tend to think that a case-insensitive graceful fallback would be the cleanest solution. Sure, the webpage is broken and you could just wait for them to fix it but that battle will never be won and in the mean time the user is none the wiser.
Comment 5 Robert Blaut 2008-03-06 10:58:11 PST
The bug report is Invalid. Per HTML 4.01 spec:
"Anchor names must observe the following rules:
* [...]
* String matching: Comparisons between fragment identifiers and anchor names must be done by ***exact (case-sensitive) match***." [http://www.w3.org/TR/html401/struct/links.html#h-12.2.1]


Comment 6 Lachlan Deck 2008-03-06 11:47:24 PST
Hmm. Well if every browser only honoured what the specs said -- rather than being tolerant of Invalid html, which is the reality is it not? -- then the browsing experience would be lower than it is.

What's the criteria for deciding when to be tolerant of bad html or not?
cheers,
Lachlan
Comment 7 Robert Blaut 2008-03-06 11:55:59 PST
(In reply to comment #6)
> Hmm. Well if every browser only honoured what the specs said -- rather than
> being tolerant of Invalid html, which is the reality is it not? -- then the
> browsing experience would be lower than it is.
> 
> What's the criteria for deciding when to be tolerant of bad html or not?

The main criterium is other browsers behavior. Based on performed tests from all of "big four" (Internet Explorer, Firefox, Safari and Opera) only Internet Explorer violates HTML4 specification. We want to follow other standard browsers behavior rather than emulate more and more IE bugs. If Firefox, Opera have no problem with it, Webkit have no problem with it either.
Comment 8 Alexey Proskuryakov 2008-03-06 13:25:27 PST
Such cases are far from obvious - IE is "only" a browser used by most people, so compatibility with it is very important. Also, there are several real life compatibility issues caused by this, as cited above.

I'm leaning towards counting this a bug that needs to be fixed, but ultimately, I think we need one of the project leaders to make the call here.
Comment 9 Robert Blaut 2008-03-07 02:32:24 PST
(In reply to comment #8)
> Such cases are far from obvious - IE is "only" a browser used by most people,
> so compatibility with it is very important. Also, there are several real life
> compatibility issues caused by this, as cited above.

I know that IE is the most popular browser, but it doesn't mean that we should implement every IE bug in Webkit to be "compatible" with IE. If Firefox (33% market share) doesn't do that and has no problem with it why we care about it? 

I found a bug report in Mozilla bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=286565 
3 years without activity. No duplicates! The problem is really minor. 

PS. Funny thing. I tested the behavior in IE8 beta 1 and found that anchors on the page: http://maven.apache.org/pom.html#Dependencies don't work at all in this browser.
Comment 10 Ahmad Saleem 2022-06-02 21:13:36 PDT
Since Safari was following Firefox and Opera behavior as per Comment 07 and Mozilla mentioned in Comment 09 got closed stating that it is Invalid as per Spec.

Spec Link (based on Mozilla bug) - https://html.spec.whatwg.org/multipage/browsing-the-web.html#the-indicated-part-of-the-document

I think since Safari is aligned with Firefox behavior and spec. It can be closed now as "RESOLVED INVALID". Thanks!
Comment 11 Alexey Proskuryakov 2022-06-03 11:31:32 PDT
Safari, Chrome and Firefox all seem aligned now, at least testing with https://en.wikipedia.org/wiki/Bratz#Bratz_Design_academy (case insensitive match for Bratz_Design_Academy anchor).

There might be special cases hiding somewhere (e.g. different behavior for quirks mode), but then again, there might be none.

BTW, https://maven.apache.org/pom.html#Dependencies now works with both "dependencies" and "Dependencies", but not due to case sensitivity. There is a second <a> element with a name attribute.

<h4 id="dependencies"><a name="Dependencies">Dependencies</a><a class="anchorjs-link " aria-label="Anchor" data-anchorjs-icon="" href="#dependencies" ...