Closed Bug 266372 Opened 20 years ago Closed 20 years ago

empty anchor A tags in source are not closed in internal mozilla DOM

Categories

(Core :: DOM: HTML Parser, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: urkle, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 Galeon/1.2.14 (X11; Linux i686; U;) Gecko/20040503
Build Identifier: Mozilla/5.0 Galeon/1.2.14 (X11; Linux i686; U;) Gecko/20040503

the sample page is a page generated from the docbook XSL which generates <a
id="someid"/>  to mark anchor points for internal links within the
documentation. The page is valid XHTML 1.1.  The issue is that when "viewing
selected source" in Firefox (0.8 and 0.10.1) the <a> seems to be not close and
seems to bleed onto other elements causing the entire paragragh of text to
respond to a:hover CSS selectors, even though in the original source the A is
closed (via />)  If you have the webdeveloper plugin and Display ID anc class
name you can see the anchro ID bleeding on other nodes. This occurs in Firefox
0.8, 0.10.1, mozilla 1.4 and mozilla 1.6 on both windows and linux. 

Reproducible: Always
Steps to Reproduce:
This is INVALID. You're sending your XHTML content as text/html. Therefore it
goes through our HTML parser which refuses to auto-close tags like that. You
need to actually send your document as application/xhtml+xml so that it actually
passes through our XML parser.

Please see http://www.hixie.ch/advocacy/xhtml for more information.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
I don't find this "solution" acceptible unfortunately. In an ideal world
browsers would all follow the standards, however, this is not so.  Originally
while desigining outoforder.cc and working on the mod_transform module I was
using the application/xhtml+xml mime type, however this completely broke
internet explorer, Opera 6 (works in 7), elinks, lynx, and probably several
other browsers.  So the only "solution" at the time was to stick with the
text/html mime type as it worked more consitantly across browsers. The only
browsers I have found that correctly use the application/xhtml+xml mime type are
Mozilla based browsers and Konqueror (KDE 3.3.1 tested).  And with mozilla
growing in populatity, yes unfortunately things may have to "bend" slightly to
get increased acceptance, as happened with the document.all introduction in
firefox 0.10.0 (which I was QUITE surprised was even done at all.)

I'm am going to seek out a solution to "fudge" mime types in apache and
mod_transform, however this issue should be re-evaluated as these issues do make
it extremely hard to develop websites, and there seems to be no way to convince
the other browser players to conform to the standards better.
> So the only "solution" at the time was to stick with the text/html mime type

The XHTML specification is very clear about the conditions under which an XHTML
document may be sent as text/html.  They are listed in Appendix C
(http://www.w3.org/TR/xhtml1/#guidelines).  The document in question in this bug
violates condition C.3.  So in fact, sending this document as text/html is a
violation of the XHTML specification.  It's nice when browsers follow standards,
as you point out, but it's also nice when content authors do so; had this
document followed the XHTML specification, there would have been no issue.
You need to log in before you can comment on or make changes to this bug.