styles for empty elements propagate to their immediate parent




12 years ago
12 years ago


(Reporter: conor+mozilla, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



12 years ago
User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv: Gecko/20060606 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv: Gecko/20060606 Firefox/

View the following HTML in Firefox:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
		<title>Test Case</title>
		<meta http-equiv="Content-Type" CONTENT="text/xml; charset=UTF-8" />
		<style type="text/css">
			div { color: #000000; }
			span { color: #FF0000; }
			i { color: #00FF00; }
			b { color: #0000FF; }

		<div><span />This should not be red</div>
		<div><i />This should not be green or italic</div>
		<div><b />This should not be blue or bold or italic</div>

The styles applied to the empty elements appear to be applied to their parent (<div>) elements.

Reproducible: Always

Steps to Reproduce:
1. View the supplied HTML in Firefox

Comment 1

12 years ago
In HTML 4.01 all three of those tags require an end tag, so you cannot use the minimized tag syntax.  And I see nothing in the XHTML spec that overrides that.  

And from XHTML 1.0:

In SGML-based HTML 4 certain elements were permitted to omit the end tag; with the elements that followed implying closure. XML does not allow end tags to be omitted. All elements other than those declared in the DTD as EMPTY must have an end tag.

From the XHTML 1.0 strict DTD you can see that those tags are not empty:
<!ELEMENT span %Inline;> <!-- generic language/style container -->
<!ATTLIST span
<!ELEMENT i %Inline;>   <!-- italic font -->
<!ATTLIST i %attrs;>

<!ELEMENT b %Inline;>   <!-- bold font -->
<!ATTLIST b %attrs;>

while the break tag is declared empty
<!ELEMENT br EMPTY>   <!-- forced line break -->
Marking invalid due to invalid code.
Last Resolved: 12 years ago
Resolution: --- → INVALID

Comment 2

12 years ago
1) The XHTML provided is valid. It validates against the XHTML 1.0 Strict DTD.

2) I did not omit the end tags. I used the minimized form of empty tags. This is perfectly legal behaviour within XML and hence within XHTML.

3) There is a recommendation in the XHTML 1.0 spec that only elements with EMPTY content models are minimised. (Section C.3) This is explicitly labelled as a recommendation to XHTML authors who are trying to make their XHTML render within legacy HTML-only user agents. It does not specify that user agents should reject correct XML/XHTML constructs.

4) I believe this is still a bug as it is incorrect behaviour in the context of XHTML. The fact that the XHTML provided is not compatible HTML should be irrelevant.

5) I first noticed this behaviour in XHTML produced by the DocBook XSL stylesheets. They produced empty 'a' elements and the link underlining "leaked" to the surrounding text.
Resolution: INVALID → ---
Created attachment 227819 [details]
Testcase, served as xhtml

This is the testcase corrected to have a correct xhtml namespace and served as the correct xhtml content type.
When served correctly as xhtml firefox parses this correctly. If however the file is interpreted as text/html then firefox uses its normal tag parser which doesnt understand the short style of empty tags.

Comment 5

12 years ago
And those styles are not propagating to the parent if you test this piece of code: 
<div>first<span style="color:green" /> Second piece</div>
you'll see that the word first is not colored green.  But after the span tag things goes awry because an end tag for the span is expected per html rules.  

From Bug 135425 comment #5:
To cut a long story short, remember that if you're serving 
this kind of markup as text/html, it will be accepted by older user-agents and 
probably throw a monkey wrench into their parsing.  If you don't care about 
these user-agents, you should just switch to text/xml or application/xml to 
deliver your content :)  We uphold this (and the W3C Markup Working Group 
agrees) so that people aren't tempted to try to throw XML constructs at these 
old user agents.
Last Resolved: 12 years ago12 years ago
Resolution: --- → INVALID

Comment 6

12 years ago
OK, things make a little more sense now. Thanks.

I guess it's too late to switch parsers by the time it gets to the namespace declaration? It would be nice if it were possible to view local XHTML without this problem. How does one work around this in the case where headers cannot be supplied?

Thanks again for the clarifications.

Comment 7

12 years ago
Change the file's extension to xhtml.  Then the application/xhtml+xml content type will be used.  Or you could use a local web server to serve your files using an xml content type.

Comment 8

12 years ago
You need to log in before you can comment on or make changes to this bug.