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)
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:
| Reporter | ||
Updated•20 years ago
|
Comment 1•20 years ago
|
||
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
| Reporter | ||
Comment 2•20 years ago
|
||
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.
Comment 3•20 years ago
|
||
> 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.
Description
•