4267 - <html:style> doesn't work in XUL/XML/XHTML

Status: VERIFIED DUPLICATE of bug 36790

(Core :: XUL, defect, P3)

Description

[David Hyatt]

I have tried to duplicate what's in the other content sinks, but i'm running
into a problem.  I'm calling some method GetSkippedContent() (I don't even know
what it does, but I think it's supposed to give me the body of the style sheet.)
 Instead it gives me nothing.  Nisheeth, do you know what I need to do to make
sure this method works for me?

Comment 1

[gerardok]

David, please provide steps to reproduce the failure. Otherwise, I won't be able
to verify the bug fix later on. For more information, please refer to:

http://www.mozilla.org/quality/bug-writing-guidelines.html

Comment 2

[Nisheeth Ranjan]

I just searched for GetSkippedContent in nsXMLContentSink.cpp but did not
find it.  David, where did you copy the code from.  Vidur, do you know about
this function off the top of your head?

Comment 3

[Nisheeth Ranjan]

I did a little poking around on LXR and found the following.  GetSkippedContent
is a method on nsParserNode, the class that's passed into the content sinks. It
is referenced in only the "HTML" and the "logging" content sinks.  Go to
http://lxr.mozilla.org/seamonkey/search?string=GetSkippedContent for the list of
references.
http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsParserNode.cpp#193 is
the implementation of GetSkippedContent.  Im ccing Rick Gessner who'll be able
to give more context about what this method does and whether XUL, etc. is
supposed to use it.

Comment 4

[David Hyatt]

Moving to M7.  This isn't that critical, and people shouldn't be using inline
style inside XUL anyway.

Comment 5

[vidur (gone)]

In general, only the HTMLContentSink uses GetSkippedContent(). This is a
mechanism to get the contents of specific HTML tags that the HTML parser knows
don't contain element content (SCRIPT and STYLE). There is no equivalent in XML
(I suppose one could exist if we supported validation and the content type of an
element was CDATA). In fact, if you look at the XMLContentSink, it collects
content itself to deal with SCRIPT elements. Something similar would have to
happen for STYLE elements.

Peter and I have talked about whether we wanted to support the HTML STYLE
element in XML and our initial thought was no. We'll probably revisit the issue
at some point, though.

Comment 6

[David Hyatt]

I would love to not support it.  The only reason I've been trying is that people
have been complaining (some of them external).

Comment 7

[Peter Trudelle]

reassigning to vidur per hyatt,

Comment 8

[vidur (gone)]

In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Comment 9

[leger]

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.

Comment 10

[vidur (gone)]

It's not the XUL case that is important - this doesn't work in XML either. And 
if we want to eventually claim XHTML 1.0 support, this needs to work. 
Unfortunately, this means redundancy of code in the HTML and XML content sinks, 
unless some refactoring is done. Moving off to M17 based on conversations with 
[e-mail]. At that point, we'll decide it there's time for factoring code 
or whether we should just live with the redundancy.

Comment 11

[rbs]

Changing title from
  <html:style> doesn't work in XUL
to
  <html:style> doesn't work in XUL/XML/XHTML
in order to reflect the wider scope of this bug.

Comment 12

[rbs]

Now that refactoring the content code has been futured, it is doubtful that
any major revamp is going to happen. However, since a JavaScript script wrapped
in a CDATA section already works fine,
<script>
<![CDATA[
...
]]>
</script>

it would be valuable (at the cost of the redundancy in version 1.0) to 
also have something similar for <style> in XHTML, 
<style>
<![CDATA[
...
]]>
</style>

Since inline style is something that people have come to expect with HTML, 
its support will be helpful for us who are building modules (like MathML
fragments within XHTML), because it will provide a stimulus during this 
transition period between HTML and wide/full adoption of XHTML.

Comment 13

[Johnny Stenback (:jst)]

This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.

Comment 14

[David Hyatt]

This is definitely ok for XUL and XBL.  No objections here.

Comment 15

[rbs]

My comments above summarized my motivations for the support of this feature in
XHTML, if possible (given this tight schedule for Nav6).

Comment 16

[Chris Hubick]

dup of bug 36790 ?

Comment 17

[rbs]

*** This bug has been marked as a duplicate of 36790 ***

Comment 18

[Chad Austin]

verified dup