There is this menu entry, View->Use Stylesheet, that works well with alternate stylesheets for html pages. Alternate xsl stylesheets for xml transformations dont show up there, but instead the stylesheet that comes last in the xml document overrides the former one (thusly violating http://www.w3.org/TR/xslt#import). examples (let the names speak): http://cuco.dyndns.org/xsl-test/html.xml http://cuco.dyndns.org/xsl-test/text.xml http://cuco.dyndns.org/xsl-test/altern.xml they resp. include html.xsl, text.xsl and both. obviously, contrary to what one might expect, the text output gets rendered like html (wrong font, newlines missing, if there are any?) regards,

There are a few issues: Multiple xslt stylesheets should behave like import. -> FUTURE. This requires an interface change. alternate stylesheets shoudn't be loaded (EASY), and stylesheet switching is either WONTFIX of *WAY* FUTURE (The html testcase is not html, btw. And adding a bit of foo so that one can see if the stylesheets are applied is good, too) Leaving unconfirmed 'til we figure out how to proceed.

html case changed to output html (never seen the output, only what mozilla rendered, so thought it might be xhtml - xsltproc now proves me wrong though.) added some "foo" to text output, to make it visible.

I thought this was covered by one of the [AltSS] bugs... Are those CSS specific? This should probably block bug 107023 if it is not a dup.

confirmed.

I'm not 100% sure we want to do this. Or at least i'm not sure how we would do it. As it is now the result of an xslt transformation can contain several alternative stylesheets, i.e. a resulting html-page can have several <link rel="alternative stylesheet"> which are shown in the list of alternative stylesheets for the page. So what happens if you on top of that have several alternative stylesheets in the original xml-page? I think it could very easily get very confusing if we allowed alternative XSLT stylesheets. That would mean that when you selected one stylesheet you could get a new range of stylesheets available, which would disappear (or be replaced with a new range of stylesheets) if you selected another styelseet. So before any work on this is done i would recommend that we get a proper UI proposal on how the result should look. (yes, i'm evil. The best way to halt progress on a bug is to ask that people agree on a good UI :-) )

One idea would be to show all available xsl styles in View->Use Style Below the active xsl style all available css styles for it should then be diplayed indented and the currently active css style marked: Basic Page Style * Default Alternate CSS Style Alternate XSL Style after selecting 'Alternate XSL Style' it should display: Basic Page Style Alternate XSL Style * Default Alternate CSS Style 1 Alternate CSS Style 2 after selecting one of the alternate CSS styles: Basic Page Style Alternate XSL Style Default * Alternate CSS Style 1 Alternate CSS Style 2 Additionally Mozilla should remember the currently selected CSS style for each XSL style so that if I change the XSL style it will use any previously selected CSS style for that XSL style. Example: If I now change back to 'Basic Page Style' and then again back to 'Alternate XSL Style' Mozilla should automatically use the 'Alternate CSS Style 1' because I used it before in the 'Alternate XSL Style'.

This might be cool, but which UI must we provide for this? XSLT-generated (X)HTML may have alternate CSS stylesheets within, therefore menu View/Use Style must be structurized.

Sorry for spam, I haven't read comment #6. Must bug 35995 be marked as a dependency?

35995 is unrelated

I just ran into this problem also. I was attempting to style a query result in such a way as to allow a link (on the column heading) to reorder the result (obviously without a round trip to the server). This would be similar to the books.xml example, but styled with xslt instead of css. For my use, ui is not important. I just need to be able to activate and deactivate a stylesheet using javascript.

It's not clear to me that you will ever be able to do it via script by manually enabling sheets. Does script even have access to the original pre-transform XML (which is what you'd need to do it)? I'd think that any scripts that run are running in the transformed document....

Yep, bz is right, i don't think this will ever be scriptable

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

The discussion so far seems to assume that the document generated by XSLT is HTML, possibly itself with alternate CSS sheets. It could get worse than that: The generated document can be XML itself, with alternate XSLT sheets, and possibly infinite recursion. So I guess the UI would have to be an expanding tree of submenus. Start by listing the sheets given in the document itself. Whenever a sheet is used, and turns out to contain alternate sheets itself, its menu item should be replaced by a submenu. Hopefully the user gets tired of choosing styles before we reach stack overflow?

Quickfix suggestion: Allow CSS sheet selection in page generated by the only XSLT sheet. As you apperaently do, e.g. http://landsbank.fo/test/cascade.xml . Also allow choice between XSLT sheets at the top level, but then lock the generated page to the default style sheet.

I'm going to WONTFIX this. In order to retransform we would have to keep the original document around, which in the vast majority of cases is a waste. We could reload from cache, but what would we then do if the document isn't there any more? And in all cases a retransform would nuke all form-control values. I see no way of making a consistent and good solution. If you want alternative stylesheets then use multiple CSS stylesheets in the result of the transform. If you want features that CSS can't do, such as sorting, then either include multiple tables in the result document and hide the ones that you don't want using CSS, or use scripting which can call xslt.

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