Seems that the lookup is not case insensitive. The named anchor on the above url is "dependencies" rather than <a name="Dependencies">...
This also happens with Wikipedia links
But we got this. http://www.w3.org/TR/html401/struct/links.html#edef-A
The following example is illegal with respect to uniqueness since the two names are the same except for case:
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.
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).
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/
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 220.127.116.11 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)
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.
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]
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?
(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.
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.
(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.
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!
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" ...