3 ms·

The sample page (http://djarvis.bitbucket.org/xml/support.xml http://djarvis.bitbucket.org/xml/support.xml) is in XML which is an input Quill and many other WYS

by jhchen 12y ago

The sample page (http://djarvis.bitbucket.org/xml/support.xml http://djarvis.bitbucket.org/xml/support.xml) is in XML which is an input Quill and many other WYSIWYG editors do not support (nor claim to). Right now Chrome will not even render this page.

thangalin 12y ago
Yet another unfortunate difference in browser implementations. Firefox can use relative paths in XSL includes, whereas Chrome cannot find files included using (for example): <xsl:include href="xsl/chart.xsl"/> <xsl:include href="xsl/tags.xsl"/> Should work now. To clarify, the XML page is first transformed using the browser's internal XSLT engine. This produces a standard HTML DOM. The browser passes that HTML DOM to its HTML rendering pipeline. The JavaScript and CSS operate no differently on an XML-transformed-HTML page than they would a static HTML file.
- dingdingdang 12y ago
  > 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.

by jhchen 12y ago

thangalin 12y ago

Yet another unfortunate difference in browser implementations. Firefox can use relative paths in XSL includes, whereas Chrome cannot find files included using (for example): <xsl:include href="xsl/chart.xsl"/> <xsl:include href="xsl/tags.xsl"/> Should work now. To clarify, the XML page is first transformed using the browser's internal XSLT engine. This produces a standard HTML DOM. The browser passes that HTML DOM to its HTML rendering pipeline. The JavaScript and CSS operate no differently on an XML-transformed-HTML page than they would a static HTML file.

dingdingdang 12y ago
> 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.