Closed Bug 265324 Opened 20 years ago Closed 20 years ago

Style applied improperly to text following a "single tag" empty anchor element.

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jason.cortezzo, Assigned: dbaron)

References

(
URL
)

Details

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

A stylesheet is used to underline an anchor when hovered over.

If the anchor is a single-tag empty element - e.g. <a name="content" /> then
text following the anchor will be underlined when hovered over as if it were
part of the anchor.

If a double-tag empty element is used, the problem does not occur - e.g. <a
name="content"></a>

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
<a name="content" />

Unless you're serving an XHTML page as application/xhtml+xml, then that code is
not valid.  You can't use XML closing syntax in a text/html document, so the tag
is not closed.

Reopen if you're serving an XML document.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
*** Bug 311367 has been marked as a duplicate of this bug. ***
The following source code, as I understand, should be treated like XML (because ist is XML) but the problem is the same as reported above: the end of the anchor is not recognized before the end of the link.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html><head>
	<base href="http://www.dimensionswandler.de/dsa/" target="_self"></base>
	<link href="css/screen.css" media="screen" rel="stylesheet" type="text/css"></link>
	<title>empty anchor single tag - Test</title>
</head><body>
	<a name="pageHeader"/>
	<p>This is no link ... <a href="news.shtml" target="content">... but this is.</a></p>
</body></html>

As long as I leave out the link- and the base-element in the head-section, Firefox does not treat the "no-link-part" as a link.

I hope this information is of use for you.
Is it really so difficult to treat a document served as text/html but validly claiming to be text/xhtml as XHTML?  I just lost a few hours of my life tracking a bizarre misrendering down to an <a name="..."/> in a completely different part of a file.  It's not quite what's reported here, but I can't really justify a separate bug because the bug disappears when you manually close the anchor or serve the file as XHTML.

If anyone's curious, the following code exposes the problem I was having;  in an HTML file, it appears on two separate lines.  My guess is that the second <a> implicitly closes the first <a>, causing Mozilla to prematurely close the <span> in an effort to avoid overlap.  It's funny, though; you'd think a <span> is just an inline <div>, but switching to <div>...</div> doesn't exhibit the problem.
    <a name="foosub"/>
    <span style="display:block">subtype of <a href="#foo">Foo</a></span>
At the very least, if the parser's going to make this sort of arbitrary decision, it ought to report it in some developer-visible way.

Anyhow, there are plenty of servers which don't serve XHTML files correctly;  I really don't think it's valid to treat text/html as being exclusive of text/xhtml.  If a file tells you three separate times that's it's well-formed XML, not ten-year-old HTML, I'd think you might eventually believe it.
Yes, but that was a very silly decision for exactly this reason.  If a server can serve text/xhtml documents to clients which only accept text/html, then those clients will fail to process the files correctly whenever the author hasn't specifically coded against that possibility -- so a conscientious author can't use XML constructions in XHTML anyway.  I guess the WG decided that it's better for the UA to display it incorrectly than not at all.

There isn't much Mozilla can do about it except recognize empty elements when processing text/html -- but is there a good reason why that can't be done?  UAs are free to process illegal HTML constructs in implementation-dependent ways;  I'd think recognizing authorial intent would be a better response than ignoring the character.
You need to log in before you can comment on or make changes to this bug.