DESCRIPTION: style elements are not recognized in pseudo-XHTML documents (I say pseudo-XHTML because it's the wrong namespace). See section 4.8 of http://www.w3.org/TR/xhtml1/#h-4.8 STEPS TO REPRODUCE: * load either of the attached testcases ACTUAL RESULTS: * text should be red EXPECTED RESULTS: * text is black DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-04-21-08-M16

This will be fixed when we share code between the XML and HTML content sinks. Marking M16 for now but it is beginning to look like the content sink factoring work will slip till after beta 2.

Moving XML/HTML content sink factoring related bugs out to M17...

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.

(David: Note that the test cases are invalid since they point to SGML DTDs and not XML DTDs.) If we do not support this then we are not going to be fully XHTML compliant.

Nominating for nsbeta3. I'd like to see this fixed rather than futured. XHTML is the way of the future.

1) There is not now and never has been any commitment from Netscape for any XHTML support in Netscape 6 FCS, much less full support. 2) Wasn't there another bug on XHTML and style in which we concluded that inline STYLE attributes weren't going to be supported but that external stylesheets could be linked to? If this bug is about inline style elements not working but it's possible to link to an external stylesheet (David, Nisheeth--please confirm whether I'm right here), then I say our XHTML and style support is done for FCS. 3) Time to ship, folks. Even WSP agrees, and the way to do it is by cutting out new feature work that we can FCS without, which this very much is if I understand the situation correctly. Recommend nsbeta3- and OUT for FCS if I understand the situation correctly.

dup of bug 26026?

Now that I think about it (and as Peter mentioned on bug 7835): If it's acceptable to link a stylesheet this way in a pure XHTML XML document, should it be acceptable in a document with mixed XML vocabularies? If so, authors would start using it to link (or embed) stylesheets into XML documents that otherwise have nothing to do with HTML. This would force anyone who implemented any displayable XML vocabulary for use on the Web to understand HTML's style an link elements. Is that a good thing? Should we fix this bug?

Adding myself to cc.

Marking nsbeta3-.

XHTML adoption by many web developers including myself is going to happen before pure XML so I hope the importance of this doesnt get ignored. If I create a welformed XHTML dynamic document complete with attached script, it loads and runs exactly the same in Explorer 5.5 in XHTML form as well as in HTML/DHTML form (That is excellent). Sorry to bring up the IE comparison, but it is all standards based stuff and it works in IE so Mozilla should be there also. That same HTML/DHTML document runs great in the latest Mozilla build 18, but does not when it is converted to XHTML. All CSS properties are set dynamically in script but no changes occur in the XHTML document. So the JavaScript/DOM side of this bug is there as you would expect.

I just worked with the script element, and this is related. Taking.

*** Bug 53615 has been marked as a duplicate of this bug. ***

*** Bug 26026 has been marked as a duplicate of this bug. ***

*** Bug 60605 has been marked as a duplicate of this bug. ***

Moving to mozilla0.9.

I would like to see this fix soon. This is a commonly used element and must be supported in XHTML.

Nominating for beta1.

Um, how is this a blocker? Major I will credit for it... Anyways, as it happens I have a fix in my tree. I'll do a little testing and try to add the diff here rsn...

This is a major problem with my XHTML tests. I have over fifty tests (a, table, ul, ol, dir) which use a style element for display. Since they all fail to render with the specified style setting, I consider this a blocker.

Changing to blocker.

Johnny, can you review? The patch contains some cruft that is not meant for this bug because it is in my new content dir, but that should be easy to notice. The patch fixes 2 bugs: this bug and the case where we recognize XHTML element names that are in wrong case (there is a bug on that on pierre's list but the bug is about 3 different things... maybe there was another bug as well but can't remember...). The case problems I have fixed for content sink and document's createElementNS. Are there other places that would need the same fix?

Nomination for mozilla0.9. This is *ahem* important not least because of the large number of books teaching HTML/XHTML that use embedded stylesheets. Besides, I just spent ages trying to figure out why my document wasn't working and was pointed here by Hixie. Sigh.

*** Bug 4267 has been marked as a duplicate of this bug. ***

r=harishd.

Patch looks good to me but according to the XHTML spec it's not possible to load style sheets with <style src="..."> so please #if 0 that out for now, if we decide to support that in XHTML later we can easily turn it on again. r=jst

I #ifdeffed out the style src part and added a comment why, otherwise unchanged. Fix checked in.

Verfied fixed in the March 1 build. Style elements and inline style attributes are working. The only remaining issue, http://bugzilla.mozilla.org/show_bug.cgi?id=68185, which deals with the LINK element's href attribute not working. External css files are loaded via the href attribute.