Bug 10960 - self-closing anchor tag behavior inside nested divs inconsistent with IE/FF
Summary: self-closing anchor tag behavior inside nested divs inconsistent with IE/FF
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.whiterose.org/test/testanc...
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-20 22:11 PDT by Michael Croft
Modified: 2011-06-01 19:58 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Croft 2006-09-20 22:11:41 PDT
This is a better reduction/report of defect 8879.

testanchor3.html is valid XHTML 1.0 Traditional, displayed as HTML 4.01 because of MIME typing (as described in <a href="http://webkit.org/blog/?p=68">maciej's Surfing Safari post</a>).

While HTML requires the anchor tag to be closed, XHTML seems to think it's OK for it to be self-closing.  All browsers I looked at keep the anchor tab open until something closes it (another anchor is what I've found).  Safari (release version and revision 16490) does not close the a tag if second anchor with the closing tag is inside two nested divs.  One div and it's fine, two divs and it won't close the first a.  IE/FF do close it.

expected behavior: Safari will close an improperly self-closing anchor tag on finding a closing tag later in the document, even if the closing tag is inside two nested div elements. (like FireFox and IE 6)

actual behavior: Safari will not close an improperly self-closing anchor tag  on finding a closing tag later in the document when the closing tag is inside two nested div elements. 

desired behavior: (Don't expect it, but it's what seems to make sense) Safari will treat a self-closing anchor tag as closed if it is used a target, but not a link (e.g. if the tag is to be used as a target for linking to, but doesn't have text to highlight).  That's what I think the author wanted with an &lt;a name="target" /> and it does make sense.  The downside is that while it's logical, it might break things that are already out there & there'd have to be some thought about all the properties an anchor might have to see if the solution was right in each case, which might be too much work for handling "bad" HTML.
Comment 1 Mark Rowe (bdash) 2006-09-20 23:30:34 PDT
Michael, thanks for refiling this bug!
Comment 2 Michael Croft 2006-09-21 05:24:26 PDT
"testanchor3.html is valid XHTML 1.0 Traditional"

I find my typo above very funny, since according to maciej, most pages that are Valid XHTML 1.0 Transitional are traditionally slightly broken in current browsers. I blame lack of caffiene after midnight.
Comment 3 Michael Croft 2008-02-28 05:45:56 PST
retested with Safari 3.0.4 and r30628: Safari now acts like Firefox.
Minefield (FF 3.0b4pre) is the same.
Opera 9.50 beta closes the anchor when the enclosing paragraph is closed.

So, it's no longer broken in the real world case this came from (or at least not moreso than FF).

I don't suppose the HTML 5 spec resolves this, does it?
Comment 4 Alexey Proskuryakov 2011-05-25 22:58:59 PDT
HTML5 certainly specifies this behavior. I didn't check the spec, but since this works the same way in Firefox 4 and in WebKit nightly builds (both implement HTML5 compatible parsing), we must be good.