276223 - A valid XHTML document is parsed wrongly when using a short XML element notation

Status: VERIFIED DUPLICATE of bug 100930

(Firefox :: General, defect)

Description

[Vojtech Minarik]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

A valid XHTML 1.0 strict document is parsed wrongly and an invalid DOM tree is 
built in recent Gecko based browsers when the document contains an anchor 
element coded in short notation (<a name="a1"/>). Although the given example 
contains only one anchor named 'a1', DOM tree contains 5 such elements - as can 
be seen in DOM Inspector.

As a consequence, the page layout is affected by the extraordinary elements.

This issue was tested in recent Firefox (Mozilla/5.0 (Windows; U; Windows NT 
5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0) and Mozilla (Mozilla/5.0 
(Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217) on Windows 2000 
and Windows XP, every time with the same result.

The problem disappears, when the short notation of anchor element is replaced 
by an opening and ending tags.

Reproducible: Always

Steps to Reproduce:
1. Go to URL
2. Open DOM Inspector
3. Compare the occurrences of <a name="a1"> in DOM Inspector and the page source

Actual Results:  
DOM Inspector shows elements which do not exist in the source document.

Expected Results:  
A valid document should be parsed correctly.

Comment 1

[Bill Mason]

You cannot use the short <a/> syntax unless you serve the page as XML
(application/xhtml+xml).

Since you are serving the page as text/html, the page is parsed as HTML which
means HTML syntax applies.

Comment 2

[Vojtech Minarik]

I don't know if there is some strictly directive in HTML syntax prohibiting 
<a/> in an HTML document. If it is so, please let me know. 

My bug report was originally based on the fact that my example passed 
validation in W3C validator without any complaints, as well as it 
was 'correctly' displayed in Opera and MSIE.

If <a/> is prohibited by HTML parser, I still think Mozilla should be more 
friendly and accept it like e.g. Opera does. Otherwise, a web developer has to 
do extra processing of each web page, because for Mozilla a webserver must 
serve application/xhtml+xml in both HTTP header and <meta>, while for MSIE it 
must serve text/html (otherwise MSIE offers a download instead of rendering the 
page). For Opera it does not matter.

And imagine the origin of my example - page generated by an XSL transformation, 
e.g. in Xalan. If you want the page to be XHTML, you have to set output method 
of the transformation to XML (not HTML, not TEXT - and there is no other choice 
like XHTML method, http://www.w3.org/TR/xslt#output). As <a/> is legal in XML, 
you get it in the output.

So to conclude: AFAIK, currently there is no way how to serve XHTML pages 
generated by an XSL transformation that are both valid and visible in major 
browsers (without handling UserAgent string). Am I right?

Comment 3

[Erik Fabert]

Your bug is valid, but it is a duplicate...

Comment 4

[Erik Fabert]

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