Last Comment Bug 145684 - After applying XSLT to generate HTML, CSS files are not called
: After applying XSLT to generate HTML, CSS files are not called
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: XSLT (show other bugs)
: Trunk
: x86 Windows XP
: -- minor (vote)
: ---
Assigned To: Peter Van der Beken [:peterv] - away till Aug 1st
: Keith Visco
Mentors:
http://www.froggy.com.au/mrw28/index.xml
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-20 05:38 PDT by Mark Watkins
Modified: 2002-06-03 19:59 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Mark Watkins 2002-05-20 05:38:38 PDT
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.
Comment 1 Mark Watkins 2002-05-20 05:46:02 PDT
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 Jason Johnston 2002-05-27 22:23:13 PDT
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 Axel Hecht 2002-05-27 23:40:40 PDT
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.
Comment 4 Mark Watkins 2002-06-03 16:01:47 PDT
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.
Comment 5 Mark Watkins 2002-06-03 19:59:53 PDT
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

Note You need to log in before you can comment on or make changes to this bug.