6 ms·

i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call som

by em-bee 1y ago

i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.

youngtaff 1y ago
How do you format a raw XML file in the browser without XSLT?
- em-bee 1y ago
  instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395 https://stackoverflow.com/a/16426395
  - youngtaff 1y ago
    But can it transform / format the XML?
    - em-bee 1y ago
      why should it not? once loaded it should find the XML in the DOM and transform that any way you like.
      - em-bee 1y ago
        for the record, i just tested that the loaded javascript can access the DOM.
  - LegionMammal978 1y ago
    That's only if the original document is an XHTML document that will have scripts loaded. Other XML documents, such as RSS feeds, will not have any support for JS, short of something silly like putting it in an iframe.
    - em-bee 1y ago
      i didn't test it, but the stackoverflow answers suggested otherwise. are they wrong?
      - youngtaff 1y ago
        Perhaps you should have tried testing it before commenting?
        em-bee 1y ago
        if you know that the solution does not work, then just say so and maybe explain why, instead of being snarky. all i did was to share a link to a resource. if you don't trust that resource you need to do your own testing. what ever i say, whether i tested it or not, doesn't add much more value. you can't trust my words any more than the resource i linked. you asked half a dozen times in the last few days how a plain xml file can be transformed without xslt. and you claimed that xslt can be used to transform an rss feed. well, guess what, i just tested this: an rss feed with the standard mimetype application/rss+xml doesn't load either an xsl stylesheet or javascript. to make that work you have to change the mimetype, and if you do that, both the xsl stylesheet or the javascript load. (just not both at the same time)
        youngtaff 1y ago
        At least one of the suggested answers in SO doesn’t work and the other is somewhat painful Why answer if you don’t know the answer Here’s one that used application/xml and it works https://www.ellyloel.com/feed.rss https://www.ellyloel.com/feed.rss People are using xslt in the wild today and JS isn’t really a replacement
        em-bee 1y ago
        the specific answer that i linked to does work. i have verified that too. application/xml is not the same as application/rss+xml. application/xml also loads javascript just fine. again, i tested that. so far i have not found a single mimetype that can load xslt, but could not load javascript. i am coming to believe that there isn't one. if xslt works, then javascript works too. whether javascript itself is a suitable replacement for xslt is not the question. your argument was that it is not possible to replace the builtin xslt support with anything written in javascript, because xml files can't load javascript. since i have now verified that an xml file that can load xslt in the browser can also load javascript, this is proven wrong. all we need now is a good xslt implementation written in javascript or maybe a good binding to a wasm one and then we are ready to remove the builtin xslt support in the browser.
account42 1y ago
It solves the problem of not requiring a full turing machine with a giant API that has a history of actual exploits and not just FUD behind it.
- em-bee 1y ago
  i believe XSLT is touring complete, and regarding exploits, you rather want to read this: https://news.ycombinator.com/item?id=44910050 https://news.ycombinator.com/item?id=44910050 it turns out that because XSLT was largely ignored, it is full of security issues, some of which have been in there for decades. so the reason XSLT doesn't have a history of exploits is because nobody used it.
xg15 1y ago
True, but that raises the question, why don't the browsers do that? I think no one would object if they removed XSLT from the browser's core and instead loaded up some WASM/JavaScript implementation when some XSLT is actually encountered. Sort of like a "built-in extension". Then browser devs could treat it like an extension (plus some small shims in the core) while the public API wouldn't have to change.
- em-bee 1y ago
  because there is no demand for it.
lenkite 1y ago
You can have template includes that are auto interpreter by the browser - no need to write code AFAIK using XSLT.
- em-bee 1y ago
  XSLT is code. code written with XML syntax. let me give you an example: in order to create a menu where the current active page is highlighted and not a link, i need to do this: <a> <xsl:choose> <xsl:when test="@name='home'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/</xsl:attribute> </xsl:otherwise> </xsl:choose> home </a> | <a> <xsl:choose> <xsl:when test="@name='about'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/about.xhtml</xsl:attribute> </xsl:otherwise> </xsl:choose> about </a> | XSLT is interesting because it has a very different approach to parsing XML, and for some transformations the resulting code can be quite compact. in particular, you don't have an issue with quoting/escaping special characters most of the time while still being able to write XML/HTML syntax. but then JSX from react solves that too. so the longer you look at it the less the advantages of XSLT stand out.
  - ndriscoll 1y ago
    You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be: <xsl:variable name="nav-menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$nav-menu-items/item"> <xsl:with-param name="current" select="@current-page"/> </xsl:apply-templates> </ul> </nav> </xsl:template> <xsl:template match="item"> <xsl:param name="current"/> <li> <xsl:choose> <xsl:when test="@href=$current"> <a class="selected"><xsl:apply-templates/></a> </xsl:when> <xsl:otherwise> <a href="{@href}"><xsl:apply-templates/></a> </xsl:otherwise> </xsl:choose> </li> </xsl:template> One nice thing about XSLT is that if you start with a passthrough template: <xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> You have basically your entire "framework" with no need to figure out how to set up a build environment because there is no build environment; it's just baked into the browser. Apparently in XSLT 3.0, the passthrough template is shortened to just `<xsl:mode on-no-match="shallow-copy"/>`. In XSLT 2.0+ you could also check against `base-uri(/)` instead of needing to pass in the current page with `<nav-menu current-page="foo.xhtml"/> and there's no `param` and `with-param` stuff needed. In modern XSLT 3.0, it should be able to be something more straightforward like: <xsl:mode on-no-match="shallow-copy"/> <xsl:variable name="menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$menu-items/item"/> </ul> </nav> </xsl:template> <xsl:template match="item"> <li> <xsl:variable name="current-page" select="tokenize(base-uri(/),'/')[last()]"/> <a href="{if (@href = $current-page) then '' else @href}" class="{if (@href = $current-page) then 'selected' else ''}"> <xsl:apply-templates/> </a> </li> </xsl:template> The other nice thing is that it's something that's easy to grow into. If you don't want to get fancy with your menu, you can just do: <xsl:template match="nav-menu"> <nav> <ul> <li><a href="foo.xhtml">Foo</a></li> <li><a href="bar.xhtml">Bar</a></li> <li><a href="baz.xhtml">Baz</a></li> </ul> </nav> </xsl:template> And now you have a `<nav-menu/>` component that you can add to any page. So to the extent that you're using it to create simple website templates but you're not a "web dev", it works really well for people that don't want to go through all of the hoops that professional programmers deal with. Asking people to figure out react to make a static website is absurd.

by em-bee 1y ago

youngtaff 1y ago

How do you format a raw XML file in the browser without XSLT?

em-bee 1y ago
instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395 https://stackoverflow.com/a/16426395
- youngtaff 1y ago
  But can it transform / format the XML?
  - em-bee 1y ago
    why should it not? once loaded it should find the XML in the DOM and transform that any way you like.
    - em-bee 1y ago
      for the record, i just tested that the loaded javascript can access the DOM.
- LegionMammal978 1y ago
  That's only if the original document is an XHTML document that will have scripts loaded. Other XML documents, such as RSS feeds, will not have any support for JS, short of something silly like putting it in an iframe.
  - em-bee 1y ago
    i didn't test it, but the stackoverflow answers suggested otherwise. are they wrong?
    - youngtaff 1y ago
      Perhaps you should have tried testing it before commenting?
      - em-bee 1y ago
        if you know that the solution does not work, then just say so and maybe explain why, instead of being snarky. all i did was to share a link to a resource. if you don't trust that resource you need to do your own testing. what ever i say, whether i tested it or not, doesn't add much more value. you can't trust my words any more than the resource i linked. you asked half a dozen times in the last few days how a plain xml file can be transformed without xslt. and you claimed that xslt can be used to transform an rss feed. well, guess what, i just tested this: an rss feed with the standard mimetype application/rss+xml doesn't load either an xsl stylesheet or javascript. to make that work you have to change the mimetype, and if you do that, both the xsl stylesheet or the javascript load. (just not both at the same time)
        youngtaff 1y ago
        At least one of the suggested answers in SO doesn’t work and the other is somewhat painful Why answer if you don’t know the answer Here’s one that used application/xml and it works https://www.ellyloel.com/feed.rss https://www.ellyloel.com/feed.rss People are using xslt in the wild today and JS isn’t really a replacement
        em-bee 1y ago
        the specific answer that i linked to does work. i have verified that too. application/xml is not the same as application/rss+xml. application/xml also loads javascript just fine. again, i tested that. so far i have not found a single mimetype that can load xslt, but could not load javascript. i am coming to believe that there isn't one. if xslt works, then javascript works too. whether javascript itself is a suitable replacement for xslt is not the question. your argument was that it is not possible to replace the builtin xslt support with anything written in javascript, because xml files can't load javascript. since i have now verified that an xml file that can load xslt in the browser can also load javascript, this is proven wrong. all we need now is a good xslt implementation written in javascript or maybe a good binding to a wasm one and then we are ready to remove the builtin xslt support in the browser.

account42 1y ago

It solves the problem of not requiring a full turing machine with a giant API that has a history of actual exploits and not just FUD behind it.

em-bee 1y ago
i believe XSLT is touring complete, and regarding exploits, you rather want to read this: https://news.ycombinator.com/item?id=44910050 https://news.ycombinator.com/item?id=44910050 it turns out that because XSLT was largely ignored, it is full of security issues, some of which have been in there for decades. so the reason XSLT doesn't have a history of exploits is because nobody used it.

xg15 1y ago

True, but that raises the question, why don't the browsers do that? I think no one would object if they removed XSLT from the browser's core and instead loaded up some WASM/JavaScript implementation when some XSLT is actually encountered. Sort of like a "built-in extension". Then browser devs could treat it like an extension (plus some small shims in the core) while the public API wouldn't have to change.

em-bee 1y ago
because there is no demand for it.

lenkite 1y ago

You can have template includes that are auto interpreter by the browser - no need to write code AFAIK using XSLT.

em-bee 1y ago
XSLT is code. code written with XML syntax. let me give you an example: in order to create a menu where the current active page is highlighted and not a link, i need to do this: <a> <xsl:choose> <xsl:when test="@name='home'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/</xsl:attribute> </xsl:otherwise> </xsl:choose> home </a> | <a> <xsl:choose> <xsl:when test="@name='about'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/about.xhtml</xsl:attribute> </xsl:otherwise> </xsl:choose> about </a> | XSLT is interesting because it has a very different approach to parsing XML, and for some transformations the resulting code can be quite compact. in particular, you don't have an issue with quoting/escaping special characters most of the time while still being able to write XML/HTML syntax. but then JSX from react solves that too. so the longer you look at it the less the advantages of XSLT stand out.
- ndriscoll 1y ago
  You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be: <xsl:variable name="nav-menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$nav-menu-items/item"> <xsl:with-param name="current" select="@current-page"/> </xsl:apply-templates> </ul> </nav> </xsl:template> <xsl:template match="item"> <xsl:param name="current"/> <li> <xsl:choose> <xsl:when test="@href=$current"> <a class="selected"><xsl:apply-templates/></a> </xsl:when> <xsl:otherwise> <a href="{@href}"><xsl:apply-templates/></a> </xsl:otherwise> </xsl:choose> </li> </xsl:template> One nice thing about XSLT is that if you start with a passthrough template: <xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> You have basically your entire "framework" with no need to figure out how to set up a build environment because there is no build environment; it's just baked into the browser. Apparently in XSLT 3.0, the passthrough template is shortened to just `<xsl:mode on-no-match="shallow-copy"/>`. In XSLT 2.0+ you could also check against `base-uri(/)` instead of needing to pass in the current page with `<nav-menu current-page="foo.xhtml"/> and there's no `param` and `with-param` stuff needed. In modern XSLT 3.0, it should be able to be something more straightforward like: <xsl:mode on-no-match="shallow-copy"/> <xsl:variable name="menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$menu-items/item"/> </ul> </nav> </xsl:template> <xsl:template match="item"> <li> <xsl:variable name="current-page" select="tokenize(base-uri(/),'/')[last()]"/> <a href="{if (@href = $current-page) then '' else @href}" class="{if (@href = $current-page) then 'selected' else ''}"> <xsl:apply-templates/> </a> </li> </xsl:template> The other nice thing is that it's something that's easy to grow into. If you don't want to get fancy with your menu, you can just do: <xsl:template match="nav-menu"> <nav> <ul> <li><a href="foo.xhtml">Foo</a></li> <li><a href="bar.xhtml">Bar</a></li> <li><a href="baz.xhtml">Baz</a></li> </ul> </nav> </xsl:template> And now you have a `<nav-menu/>` component that you can add to any page. So to the extent that you're using it to create simple website templates but you're not a "web dev", it works really well for people that don't want to go through all of the hoops that professional programmers deal with. Asking people to figure out react to make a static website is absurd.