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




20 years ago
10 years ago


(Reporter: hyatt, Assigned: vidur)




Firefox Tracking Flags

(Not tracked)




20 years ago
Target Milestone: M5


20 years ago
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

20 years ago
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:


Comment 2

20 years ago
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

20 years ago
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
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.


20 years ago
Target Milestone: M5 → M7

Comment 4

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

Comment 5

20 years ago
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

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


20 years ago
Target Milestone: M7 → M10


20 years ago
Target Milestone: M10 → M15


19 years ago
Assignee: hyatt → vidur

Comment 7

19 years ago
reassigning to vidur per hyatt,

Comment 8

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

Comment 9

19 years ago
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL

Comment 10

19 years ago
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.
Target Milestone: M15 → M17

Comment 11

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

Comment 12

19 years ago
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,

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

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.
Target Milestone: M17 → Future

Comment 14

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

Comment 15

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

Comment 16

18 years ago
dup of bug 36790 ?

Comment 17

18 years ago

*** This bug has been marked as a duplicate of 36790 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 18

18 years ago
verified dup


10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: gerardok → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.