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?

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

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?

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.

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

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.

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

reassigning to vidur per hyatt,

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

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

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 jst@netscape.com. At that point, we'll decide it there's time for factoring code or whether we should just live with the redundancy.

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.

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.

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.

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

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

dup of bug 36790 ?

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

verified dup