Closed
Bug 179182
Opened 23 years ago
Closed 22 years ago
when the file ending is ".html" an empty anchor causes mozilla to use the same properties on following elements
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: juggy, Assigned: asa)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021028
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021028
When you have an empty anchor like <a id="blalb" /> with assigned CSS-properties
such as color or hover the following elements receive the same properties!
This can only be circumvented by putting text or an empty space in it.
It does not happen with .xhtml ending.
Sample code:
-------------------------------------------------------------
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Mozilla bug</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css">
a { color: blue;
}
a:HOVER {
text-decoration: underline overline;
}
</style>
</head>
<body>
<div>
<a id="test" />
This should not have underline overline on hover, nor should the color be blue!
</div>
</body>
</html>
Reproducible: Always
Steps to Reproduce:
Check the sample above
Actual Results:
Sample result: Text turns blue, underline overline property on following elements
Expected Results:
The following elements should not be changed in any way since the causing
element is closed.
|
||
Comment 1•23 years ago
|
||
http://www.w3.org/TR/xhtml-media-types/
"3.1. 'text/html'
The 'text/html' media type [RFC2854] is
primarily for HTML, not for XHTML. In general, this media type is
NOT suitable for XHTML.
However, as [RFC2854] says,
[XHTML1] defines a profile of use of XHTML which is
compatible with HTML 4.01 and which may also be labeled as text/html.
[XHTML1], Appendix C
"HTML Compatibility Guidelines" summarizes
design guidelines
for authors who wish their XHTML documents to render on existing
HTML user agents. The use of 'text/html' for XHTML
SHOULD be limited for the purpose of rendering on
existing HTML user agents, and SHOULD be limited to
[XHTML1] documents which follow
the HTML Compatibility Guidelines.
In particular, 'text/html' is NOT suitable for
XHTML Family document types that adds elements and attributes from
foreign namespaces, such as XHTML+MathML
[XHTML+MathML].
XHTML documents served as 'text/html' will not be processed as
XML [XML10], e.g. well-formedness errors
may not be detected by user agents. Also be aware that HTML rules will
be applied for DOM and
style sheets (see C.11 and C13 of [XHTML1]
respectively)."
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_11
I think the rendering is correct. Minimization should not be used on elements
that defines an end tag (<a> has an endtag). If one does, CSS in the HTML mode
will just assume that the end tag is missing.
Served as application/xhtml+xml, the document renders correctly.
|
||
Comment 2•23 years ago
|
||
Marking INVALID. Mozilla (by design) does not support XML parsing for text/html
and it would be unreasonable to expect Mozilla to support it. (See
http://www.iki.fi/hsivonen/xhtml-the-point and
http://www.cs.tut.fi/~jkorpela/html/empty.html)
From the local disk .html is treated as text/html is treated when the file comes
from a server.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
I am sorry, but I think ignoring this bug and saying "mozilla does not support
xml parsing in text/html" is not the right thing to do. The W3C does not define
exactly, what to do when text/html instead of text/xml, ... is used, this is
correct.
However, I feel that if you are developing a platform should do what you EXPECT,
not have some undefined behaviour. For example, IE and Opera do it IMHO
correctly: Since the <a>-Tag is CLOSED, they also don't assign properties to the
following elements. If you cared to, I would very much prefer to learn why you
feel that a CLOSED element (note: writing <hr> or <br> as <hr /> and <br /> was
always correct as well, e.g.) should let the following elements inherit its CSS
properties?
Mozilla should do as a normal developer would expect: when an element is CLOSED,
don't give CSS to its successors. If you are really intend on the
"empty-element" thing: Ignore ALL elements! Or display them ALL! Just do things
in a defined and documented way.
I reopen this bug this one time only - if you close it again, it'll stay that
way. But please take that "do what you expect" idea into account.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
|
|
||
Comment 5•23 years ago
|
||
You are using a minimized <a id="test" /> in HTML on an element that has an
non-optional end tag (this is different from <br> and <hr> that have no end
tags). If you care to read the spec, you will see that *any* conforming SGML
parser will treat this is an unclosed element. In fact, it is SGML equivalent to
<a id="test">>, which should result in a ">" to be rendered after the anchor.
The minimization <a id="test" /> can only be understood properly with an XML
parser. XML parsers parse XHTML and XML, SGL parsers parse HTML. They have
different rules, and thus render differently.
It is irrelevant how this and that browser renders this. Mozilla is about
standards compliance, not quirky browser emulation.
|
||
Comment 6•22 years ago
|
||
Niklas is right.
>But please take that "do what you expect" idea into account.
We have to draw the line somewhere between doing what people expect, and doing
the "right" thing (in this case, following the HTML/XML specs).
->INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → INVALID
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•