Closed
Bug 285024
Opened 21 years ago
Closed 21 years ago
A CDATA section that appears inside a STYLE tag will cause the contents of the STYLE tag to be ignored.
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: houghtoa, Unassigned)
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xml:lang='en-US' xmlns='http://www.w3.org/1999/xhtml'>
<head>
<title>Title</title>
<meta http-equiv='Content-Type' content='application/xhtml+xml; charset=utf-8'/>
<style type='text/css'>
<![CDATA[
@media all
{
body { background-color: pink; }
}
]]>
</style>
</head>
<body>
<p>Some text</p>
</body>
</html>
Reproducible: Always
Steps to Reproduce:
1. Copy XHTML tags from Details section and paste to a file.
2. Open the file in Firebird.
3.
Actual Results:
The background of the body was white.
Expected Results:
The background of the body should have been pink.
|
||
Comment 1•21 years ago
|
||
Whilst this behaviour is certainly surprising (and I consider it a defect),
could you convince me by quoting a standard that your observed behavour
violates.
I may be wrong, but I believe that modern browsers treat comment markers
as CDATA, and the attached document which works, is the recommended way
of doing what you want.
|
||
Comment 2•21 years ago
|
||
In XHTML you should set the background on the <html> element.
http://www.w3.org/TR/CSS21/colors.html#q2 paragraph 4,
"This does not apply to XHTML documents"
-> INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
|
|
||
Comment 3•21 years ago
|
||
Mats, your statement is (of course) correct, and would be accepted even
without the reference. I appreciate the the Reporter would have helped
his cause by attaching rather than pasteing his document.
I fear that you may not have answered his question.
I enclose a testcase with the style properly applied to the
html element, which still doesn't work. In fact it doesn't work
if there is only a CDATA section delimiter, videlicet:
<style type="text/css">
<![CDATA[ < ... no markup here! ... > ]]>
html { background-color: pink; }
</style>
IMHO, this is not a problem for modern browsers as comment delimiters
work; but I was under the impression that it was usual to (also) use
a CDATA section as the Reporter had, to prevent older browers skipping
the style strings with the comment. I don't have a reference to a
standard either deprecating the Reporter's usage or mandating
Mozilla's behaviour.
This is why the observed behaviour looks surprising; but I certainly
don't exclude a simple explanation, merely assert that I don't know
of one!
|
|
||
Comment 4•21 years ago
|
||
(In reply to comment #3)
> I enclose a testcase with the style properly applied to the
> html element, which still doesn't work. In fact it doesn't work
> if there is only a CDATA section delimiter, videlicet:
>
> <style type="text/css">
> <![CDATA[ < ... no markup here! ... > ]]>
> html { background-color: pink; }
> </style>
>
> IMHO, this is not a problem for modern browsers as comment delimiters work
Comment delimiters?
With the markup above, you are asking the CSS parser to parse
< ... no markup here! ... >
html { background-color: pink; }
which is rejected because the selector "< ... no markup here! ... > html"
is invalid. The following works fine for me:
<style type="text/css">
<![CDATA[ html { ]]>
background-color:
<![CDATA[ pink; ]]>
}
</style>
CDATA sections are just a way to tell the XML parser that it should not
parse that section as XML, just read it as character data.
See http://www.w3.org/TR/2000/REC-xml-20001006#sec-cdata-sect
|
|
||
Comment 5•21 years ago
|
||
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050227
Firefox/1.0+
I certianly understand your latest comment, and I am quite prepared to
accept that I am wrong (perhaps in some way that I am yet ignorant
of).
I pasted your snippet into my document, and it does not work for me.
When I spoke of the mere presence of a CDATA section marker, I was using
this:
<style type="text/css">
<![CDATA[]]>
html { background-color: pink; }
</style>
and I put in the dummy text for clarity.
|
|
||
Comment 6•21 years ago
|
||
(In reply to comment #4)
> (In reply to comment #3)
> > [ snip ]
> Comment delimiters?
I was going by
http://www.cs.rit.edu/~ats/xml-2001-3/rec/REC-css1.html#containment-in-html
http://www.w3.org/TR/xhtml1/#C_14
I will have to check with an XML reference as I cannot find the page that
I had a few days ago which dealt with this.
My working testcase https://bugzilla.mozilla.org/attachment.cgi?id=176495
shows what I meant.
|
|
||
Comment 7•21 years ago
|
||
(In reply to comment #6)
The chapter heading for the XHTML1 C.14 URL you cited is
"Referencing Style Elements when serving as XML"
but you are *not* serving the content as XML, you are serving it as text/html
which is an entirely different ball game...
Please see Chapter 4 and Appendix C of the XHTML spec if that is what you
intend to do.
http://www.w3.org/TR/xhtml1/#diffs
http://www.w3.org/TR/xhtml1/#guidelines
See also 27403 comment 24 as to why we do not support CDATA sections for XHTML
sent as text/html.
|
|
||
Comment 8•21 years ago
|
||
Comment on attachment 176709 [details]
Non-working case with CDATA
Changing MIME type to text/xml - should work now
Attachment #176709 -
Attachment mime type: text/html → text/xml
|
|
||
Comment 9•21 years ago
|
||
Many thanks. I think that I have grasped all the points now.
1. It is possible that the Reporter may have thought that the element
<meta http-equiv='Content-Type' content='application/xhtml+xml; charset=utf-8'/>
would switch on the behaviour that he wanted.
In fact, to get the defective behaviour it seems necessary for the
local file in step 1 to have the extension .html .
If there is no extension then (I'm guessing) Firefox's content
sniffing picks up the XML declaration on the first line.
2. I wasn't aware that it was possible to have Bugzilla apply a
content type of application/xhtml+xml or equivalent to an attachment;
as there was no matching choice in the drop down menu.
If I could have done this, I would probably have posted the full answer
early on, as I was thinking that it might be a content-type problem:
but was put off once I had reproduced the Reporter's problem using
his recipe.
Grateful for your explanations.
You need to log in
before you can comment on or make changes to this bug.
Description
•