With xml/xslt, the browser fetches, eg, somefile.xml that looks like: <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="somefile.xsl"?>

With xml/xslt, the browser fetches, eg, somefile.xml that looks like: <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="somefile.xsl"?> ... Then the browser fetch somefile.xsl and uses that to transform the xml into html (which is then rendered as per the uzhe). Whether the browser does all that in C or C++ or Rust or Javascript or by sending it to an LLM is an implementation detail. If the browser drops xslt support and just displays it as text (or syntax-hilighted xml), I, as the xml author, can't polyfill that by adding javascript to the xml because it won't be executed. You need to back up a level. You could set up a web page that fetches the xml and fetch the xslt and transforms it into html and then displays it (so a browser in your browser so you can browse while you browse) but I wouldn't call that a polyfill exactly. If you're going to do that, it would be less work and a better user experience to do the transform server side.