[Webkit-unassigned] [Bug 10960] New: self-closing anchor tab behavior inside nested divs inconsistent with IE/FF

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=10960

           Summary: self-closing anchor tab behavior inside nested divs
                    inconsistent with IE/FF
           Product: WebKit
           Version: 420+ (nightly)
          Platform: Macintosh
               URL: http://www.whiterose.org/test/testanchor3.html
        OS/Version: Mac OS X 10.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: mcroft at mac.com


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


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.