Closed Bug 285024 Opened 19 years ago Closed 19 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)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: houghtoa, Unassigned)

Details

Attachments

(3 files)

Working testcase
518 bytes, text/html
Details
Style on html
504 bytes, text/html
Details
Non-working case with CDATA
538 bytes, text/xml
Details 
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.
Attached file Working testcase — 
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.
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: 19 years ago
Resolution: --- → INVALID
Attached file Style on html — 
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!
(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

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.
(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.

(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 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
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.

Attachment

General

Creator:
Created:
Updated:
Size: