Closed Bug 36790 Opened 24 years ago Closed 24 years ago

style elements not recognized in XHTML documents

Categories

(Core :: XML, defect, P3)

Product:
Core
Component:
XML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: dbaron, Assigned: hjtoi-bugzilla)

References

Details

(Keywords: xhtml, Whiteboard: [fixinhand])

Attachments

(5 files)

testcase #1 (uses CDATA section)
316 bytes, text/xml
Details
testcase #2 (does not use CDATA section)
304 bytes, text/xml
Details
Proposed fix 1 (with some other changes)
14.00 KB, patch
Details | Diff | Splinter Review
Proposed fix, also fixes some other CDATA section bugs
7.66 KB, patch
Details | Diff | Splinter Review
testcase #3, style, title, textare - in and out of CDATA
558 bytes, text/xml
Details 
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Moving XML/HTML content sink factoring related bugs out to M17...
Target Milestone: M16 → M17
Keywords: testcase
Whiteboard: [TESTCASE]
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
(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.
Blocks: html4.01
Severity: normal → major
Keywords: testcase
Whiteboard: [TESTCASE]
Nominating for nsbeta3.  I'd like to see this fixed rather than futured.  XHTML 
is the way of the future.
Keywords: nsbeta3
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.
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-.
Whiteboard: [nsbeta3-]
QA Contact: chrisd → petersen
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.
Assignee: nisheeth → heikki
Status: ASSIGNED → NEW
Severity: major → normal
OS: Linux → All
Hardware: PC → All
Target Milestone: Future → mozilla0.9.1
*** Bug 53615 has been marked as a duplicate of this bug. ***
*** Bug 26026 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.1 → mozilla0.8
*** Bug 60605 has been marked as a duplicate of this bug. ***
Moving to mozilla0.9.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.8 → mozilla0.9
I would like to see this fix soon. This is a commonly used element and must be
supported in XHTML.
Severity: normal → blocker
Whiteboard: [nsbeta3-]
Nominating for beta1.
Keywords: nsbeta3 → nsbeta1
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...
Severity: blocker → major
Whiteboard: [fixinhand]
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.
Severity: major → 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.
Keywords: mozilla0.9
*** 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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: