3 ms·

> Should work now. So you just fixed the issue? What was the problem causing the mis-render? Thanks for starting the project I think the basic premise of using

> Should work now. So you just fixed the issue? What was the problem causing the mis-render? Thanks for starting the project I think the basic premise of using the browser for selection & apply transforms manually is superb idea, possibly the only one that can work consistently in the current messy environment!

thangalin 12y ago
This works fine in Firefox, but not Chrome: <xsl:include href="xsl/chart.xsl"/> <xsl:include href="xsl/tags.xsl"/> To work in both Firefox and Chrome, all the XSL files need to be moved into the same directory and referenced without a relative path: <xsl:include href="chart.xsl"/> <xsl:include href="tags.xsl"/> I wouldn't recommend using client-side XSLT, though, for anything other than a quick proof-of-concept. There are technical differences that can create problems: https://greenbytes.de/tech/tc/xslt/ https://greenbytes.de/tech/tc/xslt/ The nice idea about client-side XSLT is that you can push the files to servers where you don't have server-side access, and still render the page. Once the XSLT is written, it's relatively easy to migrate to a server-side solution. Using a server-based XSL transformer then removes the headaches associated with client-side XSLT engine differences. As an aside, here's an interesting XSL file: https://bitbucket.org/djarvis/world-politics/src/master/xml/common.xsl https://bitbucket.org/djarvis/world-politics/src/master/xml/... It transforms any simple XML document (i.e., attribute-free) into a similarly DIV-nested HTML document. The result is that all the pages in the following web site use a single transformation combined with corresponding CSS files: http://djarvis.bitbucket.org/xml/ http://djarvis.bitbucket.org/xml/ Most places I've worked that employ XSLT use a different XSLT file for each (differing) XML document.

thangalin 12y ago

This works fine in Firefox, but not Chrome: <xsl:include href="xsl/chart.xsl"/> <xsl:include href="xsl/tags.xsl"/> To work in both Firefox and Chrome, all the XSL files need to be moved into the same directory and referenced without a relative path: <xsl:include href="chart.xsl"/> <xsl:include href="tags.xsl"/> I wouldn't recommend using client-side XSLT, though, for anything other than a quick proof-of-concept. There are technical differences that can create problems: https://greenbytes.de/tech/tc/xslt/ https://greenbytes.de/tech/tc/xslt/ The nice idea about client-side XSLT is that you can push the files to servers where you don't have server-side access, and still render the page. Once the XSLT is written, it's relatively easy to migrate to a server-side solution. Using a server-based XSL transformer then removes the headaches associated with client-side XSLT engine differences. As an aside, here's an interesting XSL file: https://bitbucket.org/djarvis/world-politics/src/master/xml/common.xsl https://bitbucket.org/djarvis/world-politics/src/master/xml/... It transforms any simple XML document (i.e., attribute-free) into a similarly DIV-nested HTML document. The result is that all the pages in the following web site use a single transformation combined with corresponding CSS files: http://djarvis.bitbucket.org/xml/ http://djarvis.bitbucket.org/xml/ Most places I've worked that employ XSLT use a different XSLT file for each (differing) XML document.