Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

511–520 of 559 posts

Re: "Remove mentions of XSLT from the html spec"

#511

Earlier quoted context omitted.

Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

Sadly, I just built a web site with HTMX and am using the client-side-templates extension for client-side XSLT. >very, very few websites Doesn't include all the corporate web sites that they are probably blocked from getting such telemetry for. These are the users that are pushing back.

Does that library use the browser's xslt?

I'm curious as to the scope of the problem, if html spec drops xslt, what the solutions would be; I've never really used xslt (once maybe, 20 years ago). In addition to just pre-rendering your webpage server-side, I assume another possible solution is some javascript library that does the transformations, if it needed to be client-side?

Found a js-only library, so someone has done this before: https://www.npmjs.com/package/xslt-processor

Re: "Remove mentions of XSLT from the html spec"

#512
post #499

Earlier quoted context omitted.

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

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: selected / home | selected /about.xhtml about | 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 quo…

You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be:

  
    Foo Page
    Bar Page
    Baz Page
  

  
    
      
        
          
        
      
    
  

  
    
    
      
        
          
        
        
          
        
      
    
 

One nice thing about XSLT is that if you start with a passthrough 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 ``. In XSLT 2.0+ you could also check against `base-uri(/)` instead of needing to pass in the current page with ` 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:

  

  
    Foo Page
    Bar Page
    Baz Page
  

  
    
      
        
      
    
  

  
    
      
      
        
      
    
  

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:

  
    
      
        Foo
        Bar
        Baz
      
    
   
And now you have a `` 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.

Re: "Remove mentions of XSLT from the html spec"

#513
post #410

Earlier quoted context omitted.

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

instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395

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.

Re: "Remove mentions of XSLT from the html spec"

#514
post #450

Oh hey, that thing happened that one could easily see was going to happen [0]. The writing was on the wall for XSL as soon as the browsers tore out FTP support: their desire to minimize attack surface trumps any tendency to leave well enough alone. I wonder what the next step of removing less-popular features will be. Probably the SMIL attributes in favor of CSS for SVG animations, they've been grumbling about those…

> their desire to minimize attack surface trumps any tendency to leave well enough alone. It's that why Chrome unilaterally releases 1000+ web APIs a year, many of them quite complex, and spanning a huge range of things to go wrong (including access to USB, serial devices etc.)? To reduce the attack surface?

Well, their desire to stay trendy trumps their desire to minimize attack surface, I'd have to imagine. Alas, XML is roughly the polar opposite of trendy, mostly seen as belonging in the trash heap of the 90s alongside SOAP, CORBA, DCOM, Java applets, etc.

Re: "Remove mentions of XSLT from the html spec"

#515
post #476

Earlier quoted context omitted.

> Sure, but this requires [...] maintaining it indefinitely. Does it, though? Browsers already have existing XSLT stacks, which have somehow gotten by practically unmodified for the last 20 years. The basic XSLT 1.0 functionality never changes, and the links between the XSLT code and the rest of the codebase rarely change, so I find it hard to believe that slapping it into a sandbox would suddenly turn it into a pers…

Wasn't this whole discussion sparked by a fairly significant bug in the libxslt implementation? There's also a comment from a Chrome developer somewhere in this thread talking about regularly trying to fix things in libxslt, and how difficult that was because of how the library is structured. So it is currently a persistent time sync, and rewriting it so that it can sit inside the browser sandbox will probably add a…

The current problem is that bugs in libxslt can have big security implications, so putting it or an equivalent XSLT 1.0 processor in a safe sandbox would make active maintenance far less urgent, since the worst-case scenario would just be presentation issues.

As for immediate work, some in this thread have proposed compiling libxslt to WASM and using that, which sounds perfectly viable to me, if inefficient. WASM toolchains have progressed far enough that very few changes are needed to a C/C++ codebase to get it to compile and run properly, so all that's left is to set up the entry points.

(And if there really were no one-for-one replacement short of a massive labor effort, then current XSLT users would be left with no simple alternative at all, which would make this decision all the worse.)

Re: "Remove mentions of XSLT from the html spec"

#516
post #499

Earlier quoted context omitted.

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: selected / home | selected /about.xhtml about | 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 quo…

You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be: Foo Page Bar Page Baz Page One nice thing about XSLT is that if you start with a passthrough 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 tem…

wow, thank you. your first example is actually what i have been trying to do but i could not get it to work. i did search for examples or explanations for hours (spread over a week or so). i found the documentation of each of the parts and directives used, but i just could not figure out how to pull it together.

your last example is what i started out with, including the pass through template. you may remember this message from almost two months ago: https://news.ycombinator.com/item?id=44398626

one comment for the xslt 3 example: href="" doesn't disable the link. it's just turns into a link to self (which it would be anyways if the value was present). the href attribute needs to be gone completely to disable the link.

Re: "Remove mentions of XSLT from the html spec"

#517
post #410

Earlier quoted context omitted.

instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395

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.

i didn't test it, but the stackoverflow answers suggested otherwise. are they wrong?

Re: "Remove mentions of XSLT from the html spec"

#518
post #485

Earlier quoted context omitted.

> Of course. And yet none of the people from Google even seem to be aware of I don't see any reason to assume that. I don't think anyone from google is claiming the literal number of sites is 0, just that it is insignificant. I am very sure the people at google are aware of the rss feed usage. Don't confuse people disagreeing with you with people not understanding you.

> I am very sure the people at google are aware of the rss feed usage. No. No they aren't. As you can see in the discussion: https://github.com/whatwg/html/issues/11523 where the engineer who proposed this literally updates his "analysis" as people point out use cases he missed. Quote: --- start quote --- albertobeta: there is a real-world and modern use case from the podcasting industry, where I work. Collectively,…

I stand by my previous comment.

You're angry you didn't get your way, but the googler's decision seems logical, i think most software developers maintaining a large software platform would have made a similar decision given the evidence presented (as evidenced by other web browsers making the same one).

The only difference here between most software is that google operates somewhat in the open. In the corporate world there would be some customer service rep to shield devs from the special interest group's tantrum.

Re: "Remove mentions of XSLT from the html spec"

#519
post #516

Earlier quoted context omitted.

You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be: Foo Page Bar Page Baz Page One nice thing about XSLT is that if you start with a passthrough 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 tem…

wow, thank you. your first example is actually what i have been trying to do but i could not get it to work. i did search for examples or explanations for hours (spread over a week or so). i found the documentation of each of the parts and directives used, but i just could not figure out how to pull it together. your last example is what i started out with, including the pass through template. you may remember this m…

Yeah, unfortunately the one criticism of XSLT that you can't really deny is that there's no information out there about how to use it, so beyond the tiny amount of documentation on MDN, you kind of have to just figure out your own patterns. It feels a little unfair though that it basically comes down to "this doesn't have a mega-corporation marketing it". That and the devtools for it are utterly broken/left in the early 00s for similar reasons. You could imagine something could exist like the Godbolt compiler explorer for template expansion showing the input document on the left and output on the right with color highlighting for how things expanded, but instead we get devtools that barely work at all.

You're right on the href; maybe there's not a slick/more "HTML beginner friendly" way to get rid of the stuff even in 3.0. I have no experience with 3.0 though since it doesn't work.

I get a little fired up about the XSLT stuff because I remember being introduced to HTML in an intersession school class when I was like... 6? XSLT wasn't around at that time, but I think I maybe learned about it when I was ~12-13, and it made sense to me then. The design of all of the old stuff was all very normal-human approachable and made it very easy to bite a little bit more off at a time to make your own personal web pages. "Use React and JSON APIs" or "use SSR" seems to just be giving up on the idea that non-programmers should be able to participate in the web too. Should we do away with top level HTML/CSS while we're at it and just use DOM APIs?

There were lots of things in the XML ecosystem I didn't understand at the time (what in the world was the point of XSDs and what was a schema and how do you use them to make web pages? I later came to appreciate those as well after having to work as a programmer with APIs that didn't have schema files), but the template expansion thing to make new tags was easy to latch onto.

Re: "Remove mentions of XSLT from the html spec"

#520
post #516

Earlier quoted context omitted.

You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be: Foo Page Bar Page Baz Page One nice thing about XSLT is that if you start with a passthrough 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 tem…

wow, thank you. your first example is actually what i have been trying to do but i could not get it to work. i did search for examples or explanations for hours (spread over a week or so). i found the documentation of each of the parts and directives used, but i just could not figure out how to pull it together. your last example is what i started out with, including the pass through template. you may remember this m…

unfortunately i hit another snag: https://stackoverflow.com/questions/3884927/how-to-use-xsl-v...

nodes you output don't have type "node-set" - instead, they're what is called a "result tree fragment". You can store that to a variable, and you can use that variable to insert the fragment into output (or another variable) later on, but you cannot use XPath to query over it.

the xsl documentation https://www.w3.org/TR/xslt-10/#variables says:

Variables introduce an additional data-type into the expression language. This additional data type is called result tree fragment. A variable may be bound to a result tree fragment instead of one of the four basic XPath data-types (string, number, boolean, node-set). A result tree fragment represents a fragment of the result tree. A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. An operation is permitted on a result tree fragment only if that operation would be permitted on a string (the operation on the string may involve first converting the string to a number or boolean). In particular, it is not permitted to use the /, //, and [] operators on result tree fragments.

so using apply-templates on a variable doesn't work. this is actually where i got stuck before. i just was not sure because i could not verify that everything else was correct.

i wonder if it is possible to load the menu from a second document: https://www.w3.org/TR/xslt-10/#document

edit: it is!

    
now i just need to finetune this because somehow the $current param fails now.
Post reply on HN