client side xslt conversion
I am an xml supporter. I really like the approach to the design of web applications in which business logic is separated from the presentation by means of xml / xslt . I am not a supporter of the invention of bicycles ( Smarty type template makers ), and generally, fasten horns and pedals to a shovel.
The other day I set out to find out what progress the browser developers in the field of client side xslt transformations have achieved. Because it is not interesting to perform the conversion on the server - resources are consumed, the channel is consumed (which is especially important for users of weak channels and powerful computers). And in general, the transformation on the client side, in my opinion, is simply more correct. The task of displaying a document is the task of the browser. So let him do it.
The benchmark for the correctness of the conversion was taken the result of the program xsltproc.
Here is what I got:
')
For some reason, when specifying the xsl: output method = "xml" method, neither Opera nor Firefox stubbornly wants to perform the conversion. More precisely, they somehow perform it for some reason, but they do not correctly display it - just a test falls out on the screen without any formatting.
If xsl: output method = "html" is specified (by default), then the conversion is performed, but the output of the xsltproc program becomes pure html - <br>, <hr>, nowrap. I do not know how to see the result of the transformation of the Opera and Firefox engine. (maybe they have everything and great ...) Everything is displayed and in this and that browser correctly, which is encouraging.
It turned out all somewhat interesting. I have a number of banners on my site with well-known banner networks as well as a couple of buttons and counters. The banner display code is a banal document.write ('<a href=s some.site "> <img src = " path / to / banner "> </a>'); (Yes, the tag <img> of course does not have /> - people earn money, they have no time to keep standards. :)). I carried all this nonsense into separate .js files and where it was necessary to simply make inserts <script src = "banner1.js"> </ script>. xsltproc overtook such a layout in a valid xhtml / strict. Opera simply ignored this code. Firefox first stumbled when trying to process the first banner, then just fell - document.write just overwritten the entire DOM model and, accordingly, only the first banner was displayed. When trying to re-write the DOM-model, firefox apparently just fired the tower.
As a result, I rewrote the banner display code to normal, through the DOM model, and everything began to display normally.
Some time after setting these experiments, I learned that there is XSL 2.0 , in which xsl: output method = "xhtml" is added. (So far, only Opera understands this output method. The result of the work is no different from method = "html". Although I may have just tested it with a very simple example. Firefox does not understand it at all.) It's funny, but this standard is practically not implemented yet. what kind. There is an implementation on java . But gnom 'libxml / libxslt ovs (which are used by the PHP interpreter) have not yet been pulled.
The other day I set out to find out what progress the browser developers in the field of client side xslt transformations have achieved. Because it is not interesting to perform the conversion on the server - resources are consumed, the channel is consumed (which is especially important for users of weak channels and powerful computers). And in general, the transformation on the client side, in my opinion, is simply more correct. The task of displaying a document is the task of the browser. So let him do it.
The benchmark for the correctness of the conversion was taken the result of the program xsltproc.
Here is what I got:
')
For some reason, when specifying the xsl: output method = "xml" method, neither Opera nor Firefox stubbornly wants to perform the conversion. More precisely, they somehow perform it for some reason, but they do not correctly display it - just a test falls out on the screen without any formatting.
If xsl: output method = "html" is specified (by default), then the conversion is performed, but the output of the xsltproc program becomes pure html - <br>, <hr>, nowrap. I do not know how to see the result of the transformation of the Opera and Firefox engine. (maybe they have everything and great ...) Everything is displayed and in this and that browser correctly, which is encouraging.
Javascript and xslt.
It turned out all somewhat interesting. I have a number of banners on my site with well-known banner networks as well as a couple of buttons and counters. The banner display code is a banal document.write ('<a href=s some.site "> <img src = " path / to / banner "> </a>'); (Yes, the tag <img> of course does not have /> - people earn money, they have no time to keep standards. :)). I carried all this nonsense into separate .js files and where it was necessary to simply make inserts <script src = "banner1.js"> </ script>. xsltproc overtook such a layout in a valid xhtml / strict. Opera simply ignored this code. Firefox first stumbled when trying to process the first banner, then just fell - document.write just overwritten the entire DOM model and, accordingly, only the first banner was displayed. When trying to re-write the DOM-model, firefox apparently just fired the tower.
As a result, I rewrote the banner display code to normal, through the DOM model, and everything began to display normally.
PS
Some time after setting these experiments, I learned that there is XSL 2.0 , in which xsl: output method = "xhtml" is added. (So far, only Opera understands this output method. The result of the work is no different from method = "html". Although I may have just tested it with a very simple example. Firefox does not understand it at all.) It's funny, but this standard is practically not implemented yet. what kind. There is an implementation on java . But gnom 'libxml / libxslt ovs (which are used by the PHP interpreter) have not yet been pulled.
Source: https://habr.com/ru/post/23401/
All Articles