Closed
Bug 145684
Opened 22 years ago
Closed 22 years ago
After applying XSLT to generate HTML, CSS files are not called
Categories
(Core :: XSLT, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: markwatkins, Assigned: peterv)
References
()
Details
When sent to a page of XML source which uses an XSLT stylesheet to generate HTML, <link rel="stylesheet" href="blah.css" type="text/css" media="all/print" /> references are not followed - causing some problems in the layout. It also seems to have difficulty with nested div tags on this page (http://www.froggy.com.au/mrw28/index.xml) (or is this part of the same problem?) I've noticed this problem with the supplied link and a few other pages on my site (try the XML version of my cv for example) under Win2K and XP. Currently running 1.0rc2 - also noticed the problem on 1.0rc1 (sorry I didn't get around to adding it back then). This works in IE6 under both Win2K and XP. Mark.
Reporter | ||
Comment 1•22 years ago
|
||
Sorry, missed off a bit on the first message - should have read as: <link rel="stylesheet" href="blah.css" type="text/css" media="all/print/screen" /> (as in media="all" or media="print" or media="screen" for the pedants :) ) I'm guessing it doesn't work if you don't specify the media attribute at all - haven't tested this, sorry. Mark.
Comment 2•22 years ago
|
||
Mark, I see two problems with the testcase: 1) The source XML doesn't specify a namespace, so things like the style="" attributes won't be treated as you expect because the browser doesn't assume it's dealing with HTML. 2) Element selectors in the CSS are in uppercase; they will not match the lower-case XHTML elements because CSS selectors for XML are case-sensitive. Try correcting these and see if the problem still persists.
Comment 3•22 years ago
|
||
Mark, your output ain't html. Try DOM Inspector on your page to verify this. The page content happens to be just div, no namespace, for example. You probably want html output method, then no namespace get's mapped to the xhtml namespace that mozilla needs to render this stuff. That's the reason why your inline style doesn't work, the style attribute only works for html elements. And you need to change the stylesheet selectors do lowercase, 'til we fix that bug, like Jason said. A mere <xsl:output method="html" /> fixes the inline style problems.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 4•22 years ago
|
||
Thank you Jason and Axel - you've put me back on the straight and narrow. Here's a verbose report of my experiments. 1 CSS ----- The first change I made was to lowercase the CSS element selectors, and everything looked a whole lot better! It still isn't perfect as the scope of the background colour doesn't extend to the bottom floating divs (for want of a better way of explaining it, have a peek at http://www.froggy.com.au/mrw28/index.xml to see what I mean) - a difference in rendering from the html version (see http://www.froggy.com.au/mrw28/index.html for that) 2 xsl:output method="html" -------------------------- The second change I made was to change the <xsl:output method="html" /> - from its previous value of method="xml", as suggested by Axel, and it looks fine like this. Unfortunately I don't like using method="html" because when I use the same code to generate static html (i.e. index.html) it isn't good XHTML and that hurts my sensibilities :). The XSLT specification clearly states when using method="html" not to close <br> and <hr> tags (amongst others) - see http://www.w3.org/TR/1999/REC-xslt-19991116#section-HTML-Output-Method - this makes it unsuitable for generating XHTML. You're spot on Axel with saying Mozilla wasn't considering it as HTML - I should really have had a closer peek at what was going on in DOM Inspector before. When traversing the DOM tree the reported 'Namespace URI' becomes empty, instead of the preferred value of http://www.w3.org/1999/xhtml. It turns out it was loading the CSS all the time (as it was referenced from a namespace happy bit) but not being lower case caught me out. You refer to this as a bug but it's really the correct behaviour (see http://www.w3.org/TR/2000/REC-xhtml1-20000126 section C.13 point 1) and my code was just plain wrong. 3 method="xml" -------------- As I said earlier I don't like using method="html", but as I am using <xsl:copy-of /> to get the content out of index.xml I just make the root element to be copied <div xmlns="http://www.w3.org/1999/xhtml"> and it displays perfectly even if method="xml" is used. What I am finding it hard to work out is if this 'namespace forgetfulness' is proper behaviour or not. I suspect not - if it is going to empty its namespace that would mean the code having the attribute xmlns="" which none of the XSLT parsers I've used do in this case. This probably isn't the proper place to discuss that anyway... 4 DOM Inspector --------------- Here's a funny thing, in DOM Inspector when looking at a normal HTML page (i.e. index.html), unless my examples have been poor, the Namespace URI remains empty even if the root node is <html xmlns="http://www.w3.org/1999/xhtml">. Again, this probably isn't the proper place to discuss this - and I haven't used DOM Inspector too much so I might be misunderstanding it. 5 Potential issues raised by this discussion -------------------------------------------- 5.1) Vertical extent of the background colour of the body element when using html generated client-side from xml and xslt with floating div elements. 5.2) Namespace forgetfulness when using xsl:copy-of to generate html. This might be correct behaviour. 5.3) DOM Inspector doesn't recognise Namespace URI's for standard html content. Cheers, Mark.
Reporter | ||
Comment 5•22 years ago
|
||
Re:5.2, Mozilla's behaviour here matches the Microsoft XSLT parser, but not Apache's Xalan-Java. We'll say Mozilla is correct on this one. Cheers, Mark
You need to log in
before you can comment on or make changes to this bug.
Description
•