266447 - using the w3c recommended XHTML shorthand form for empty tags, <element/>, element visualisation does completely non-desired things

Status: VERIFIED DUPLICATE of bug 135425

(Core :: Web Painting, defect)

Description

[Mike Kamermans]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

The the page http://www.nihongoresources.com/downloads/firefox/ two snips of
code are shown, with as only difference that the first uses <element></element>
and the second uses <element/> mark-up for empty tags. The first is rendered
correctly. The second... well I have no idea what the second is doing, it seems
to not register that it's closed off and keeps it open until the element it's
nested in is closed off. This means that whatever component is responsible for
this, is nto being w3c compliant.

Reproducible: Always
Steps to Reproduce:
opening the mentioned link will reproduce the problem.
Actual Results:  
the first snip of html is rendered correctly, the second snip is rendered in a
non-compliant way.

Expected Results:  
it should have rendered the second snip in the exact same way as the first was
rendered.

If Moz does not support the <element/> shorthand form, it is not XHTML
compliant. This is a reasonably serious issue, since elements such as a
linebreak are <br/> in XHTML.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You need to use an XHTML namespace to get XHTML behaviour.

Comment 2

[Bill Mason]

*** This bug has been marked as a duplicate of 135425 ***

Comment 3

[Boris Zbarsky [:bzbarsky]]

Verified.  Note that the page in question doesn't even pretend to be XHTML, so
it's not clear to me why anyone expected XHTML behavior here.