Closed
Bug 225323
Opened 21 years ago
Closed 21 years ago
rendering differs between "<a></a>" and "<a/>"
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
INVALID
People
(Reporter: horsti4ever, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(3 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Indentation in nested DT DL differs if you use "<a></a>" instead of "<a/>". Reproducible: Always Steps to Reproduce: 1.Load attached zz.html Actual Results: First part should show the buggy output dt1 dd1 dt2 dd2 wrong indentation Second part should show correct output: dt1 dd1 dt2 dd2 expected indentation This is only the case while specifying the document as xhtml.
Reporter | ||
Comment 1•21 years ago
|
||
Comment 2•21 years ago
|
||
Confirming on 2003-11-10 fb build on WinXP
Assignee: blake → parser
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
Keywords: testcase
OS: Linux → All
Product: Firebird → Browser
Hardware: PC → All
Summary: rendering differs between "<a></a>" and "<a/>" → rendering differs between "<a></a>" and "<a/>"
Version: unspecified → Trunk
Comment 3•21 years ago
|
||
This screenshot might shed some light on what Mozilla does with the element in question (<a/>). The testcase validates fine at http://validator.w3.org/ even though according to the specs "All elements other than those declared in the DTD as EMPTY must have an end tag" (http://www.w3.org/TR/xhtml1/#h-4.3).
Comment 4•21 years ago
|
||
Comment 5•21 years ago
|
||
Nope, this is INVALID. You're sending an XHTML document as text/html, which you may only do if it complies to Appendix C, and in this case, it doesn't (see C.3), and even then it's not generally a good idea -- see http://www.hixie.ch/advocacy/xhtml for more information. In the first testcase, you've got an unclosed <a> tag: in SGML, your <a/> should actually be parsed as <a>> in tag-soup HTML, it'll probably end up as <a>, but it's never XML's <a></a>. Take a look at the second testcase (the third attachment). It's the same as your testcase, but served as application/xhtml+xml, so it's parsed using the XML parser. The two results are identical to the 'expected' result.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Comment 6•20 years ago
|
||
*** Bug 241594 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
*** Bug 279362 has been marked as a duplicate of this bug. ***
Comment 8•20 years ago
|
||
*** Bug 280018 has been marked as a duplicate of this bug. ***
Comment 9•19 years ago
|
||
*** Bug 283189 has been marked as a duplicate of this bug. ***
Comment 10•19 years ago
|
||
*** Bug 294765 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•