> This is actually a clever way to distinguish if the browser supports XSLT or not. Actual content is XHTML in https://xslt.rip/index.xsl
I agree it is a clever way. But it also shows exactly how hard it is to use XML and XSLT in a "proper way": Formal everything is fine to do it in this way (except the server is sending 'content-type: application/xml' for the /index.xsl, it should be 'application/xslt+xml').
Almost all implementations in XML and XSLT that I have seen in my career showed a nearly complete lack of understanding of how they were intended to be used and how they should work together. Starting with completely pointless key/value XMLs (I'm looking at you, Apple and Nokia), through call-template orgies (IBM), to ‘yet-another-element-open/-close’ implementations (almost every in-house application development in PHP, JAVA or .NET).
I started using XSLT before the first specification had been published. Initially, I only used it in the browser. Years later, I was able to use XSLT to create XSDs and modify them at runtime.
I agree it is a clever way. But it also shows exactly how hard it is to use XML and XSLT in a "proper way": Formal everything is fine to do it in this way (except the server is sending 'content-type: application/xml' for the /index.xsl, it should be 'application/xslt+xml').
Almost all implementations in XML and XSLT that I have seen in my career showed a nearly complete lack of understanding of how they were intended to be used and how they should work together. Starting with completely pointless key/value XMLs (I'm looking at you, Apple and Nokia), through call-template orgies (IBM), to ‘yet-another-element-open/-close’ implementations (almost every in-house application development in PHP, JAVA or .NET).
I started using XSLT before the first specification had been published. Initially, I only used it in the browser. Years later, I was able to use XSLT to create XSDs and modify them at runtime.