Closed Bug 126841 Opened 20 years ago Closed 16 years ago

alternate stylesheets (xsl) for xml


(Core :: XSLT, defect)

Not set





(Reporter: pch, Assigned: keith)




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

examples (let the names speak):

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?)

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

(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.
Ever confirmed: true
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
 *    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?
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. .

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.
Closed: 16 years ago
Resolution: --- → WONTFIX
*** Bug 262290 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 426365
You need to log in before you can comment on or make changes to this bug.