Bug 13335
Summary: | html page anchor not always working (case sensitive problem) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Lachlan Deck <lachlan.deck> |
Component: | DOM | Assignee: | 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 |
Lachlan Deck
Seems that the lookup is not case insensitive. The named anchor on the above url is "dependencies" rather than <a name="Dependencies">...
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Rosyna
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).
Rosyna
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/
Charles Gaudette
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)
Lachlan Deck
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.
Robert Blaut
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]
Lachlan Deck
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
Robert Blaut
(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.
Alexey Proskuryakov
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.
Robert Blaut
(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.
Ahmad Saleem
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!
Alexey Proskuryakov
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" ...