XSLT – Native, zero-config build system for the Web • Hacker News Board

Re: XSLT – Native, zero-config build system for the Web

#161

Post by rhdunn » Fri, Jun 27, 2025, 11:57 AM UTC

codeulike wrote: post #136

masklinn wrote: post #72

Earlier quoted context omitted.

That… has nothing to do with xpath? If your document has namespaces, xpath has to reflect that. You can either tank it or explicitly ignore namespaces by foregoing the shorthands and checking `local-name()`.

Ok. Perhaps 'namespace the query' wasnt quite the right way of explaining it. All I'm saying is, whenever I've used xpath, instead of it looking nice like /*bookstore/*book/*title its been some godawful mess like /*[name()='bookstore']/*[name()='book']/*[name()='title'] ... I guess because they couldn't bear to have it just match on tags as they are in the file and it had to be tethered to some namespace stuff that m…

Newer versions of XPath and XSLT allow

    /*:bookstore/*:book/*:title

Re: XSLT – Native, zero-config build system for the Web

#162

Post by DonHopkins » Fri, Jun 27, 2025, 11:57 AM UTC

A trip down memory lane to the Museum of Obsolete Technology (with video demos):

Here's how use XSLT to make Punkemon Pie Menus! [ WARNING: IE 5 required! ;) ]

The "htc" files are ActiveX components written in JScript, aka "Dynamic HTML (DHTML) behaviors":

https://en.wikipedia.org/wiki/HTML_Components

>HTML Components (HTCs) are a legacy technology used to implement components in script as Dynamic HTML (DHTML) "behaviors" in the Microsoft Internet Explorer web browser. Such files typically use an .htc extension and the "text/x-component" MIME type.

JavaScript Pie Menus, using Internet Explorer "HTC" components, xsl, and xml:

https://www.youtube.com/watch?v=R5k4gJK-aWw

>Pie menus for JavaScript on Internet Explorer version 5, configured in XML, rendered with dynamic HTML, by Don Hopkins.

punkemonpiemenus.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

punkemon.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

punkemon.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

punkemonpiemenus.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenu.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

Also an XML Schema driven pie menu editor:

piemenuschemaeditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuschemaeditor.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuschema.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuschemaeditor.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenuxmlschema-1.0.xsd: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

Here's an earlier version that uses ActiveX OLE Control pie menus, xsl, and xml, not as fancy or schema driven:

ActiveX Pie Menus:

https://www.youtube.com/watch?v=nnC8x9x3Xag

>Demo of the free ActiveX Pie Menu Control, developed and demonstrated by Don Hopkins.

ActiveXPieMenuEditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenueditor.xsl: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenueditor.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenueditor.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

piemenumetadata.xml: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

Fasteroids (Asteroids comparing Pie Menus -vs- Linear Menus):

fasteroids.html: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

fasteroids.htc: https://github.com/SimHacker/IE-JScript-HTC-PieMenus/blob/ma...

If that wasn't obsolete enough, here is the "ConnectedTV Skin Editor". It was a set of HTC components, XML, and XML Schemas, and a schema driven wysiwyg skin editor for ConnectedTV: a Palm Pilot app that turned your Palm into a personalized TV guide + smart remote.

Full fresh lineup of national and local broadcast + TiVo + Dish TV guides with customized channel groups, channel and show filtering and favorites, hot sync your custom tv guide with just the shows you watch, weeks worth of schedules you could download and hot sync nightly with the latest guide updates.

Integrated with trainable consumer IR remote controller with custom touch screen user interfaces (with 5-function "finger pie menus" that let you easily tap or stroke up/down/left/right to stack up multiple gesture controls on each button (conveniently opposite and orthogonal for volume up/down, channel next/previous, page next/previous, time forward/back, show next/previous, mute/unmute, favorite/ignore, etc -- finger pies are perfect for the kind of opposite and directionally oriented commands on remote controls, and you need a lot fewer 5-way buttons than single purpose physical buttons on normal remotes, so you could pack a huge amount of functionality into one screen, or have any number of less dense screens, customized for just the devices you have and features you use. Goodbye TiVo Monolith Monster remote controls, since only a few of the buttons were actually useful, and ConnectedTV could put 5x the number of functions per gesture activated finger pie menu button.

The skin editor let you make custom user interfaces by wysiwyg laying out and editing out any number of buttons however you liked and bind tap/left/right/up/down page navigation, tv guide time and channel and category navigation, sending ir commands to change the channel (sends multi digits per tap on station or show so you can forget the numbers), volume, mute, rewind/skip tivo, etc.

Also you could use finger pies easily and reliably on the couch in a dark room with your finger instead of the stylus. Users tended to lose their Palm stylus in the couch cushions (which you sure don't wanna go fishing around for if JD Vance has been visiting) while eating popcorn and doing bong hits and watching tv and patting the dog and listening to music and playing video games in their media cave, so non-stylus finger gesture control was crucial.

Finger pies were was like iPhone swipe gestures, but years earlier, much cheaper (you could get a cheap low end Palm for dirt cheap and dedicate it to the tv). And self revealing (prompt with labels and give feedback (with nice clicky sounds) and train you to use the gestures efficiently) instead of invisible mysterious iPhone gestures you have to discover and figure out without visual affordances. After filtering out all the stuff you never watch and favoriting the ones you do, it was much easier to find just the shows you like and what was on right now.

More on the origin of the term "Finger Pie" for Beatles fans (but I digress ;) :

https://news.ycombinator.com/item?id=16615023

https://donhopkins.medium.com/gesture-space-842e3cdc7102

It was really nice to have the TV guide NOT on the TV screen taking you away from watching the current show, and NOT to have to wait 10 minutes while it slowly scrolled the two visible rows to through 247 channels to finally see the channel you wanted to watch (by that time you'll miss a lot of the show, but be offered lots of useless shit and psychic advice to purchase from an 800 number with your credit card!).

Kids these days don't remember how horrible and annoying those slow scrolling TV guides with ads for tele-psychics and sham wows and exercise machines used to be.

I can objectively say that it was much better than the infamous ad laden TV Guide Scroll:

https://www.youtube.com/watch?v=JkGR29TSueM

Using those slow scrolling non-interactive TV guides with obnoxious ads was so painful that you needed to apply HEAD ON directly to the forehead again and again and again to ease the pain.

https://www.youtube.com/watch?v=Is3icfcbmbs

You could use the skin editor to create your own control panels and buttons for whatever TV, TiVO, DVR, HiFi, Amplifier, CD, DVD, etc players you wanted to use together. And we had some nice color hires skins for the beautiful silver folding Sony Clie.

https://en.wikipedia.org/wiki/Sony_CLI%C3%89_PEG-TG50

It was also nice to be able to curate and capture just the buttons you wanted for the devices that you actually use together, and put them all onto one page, or factor them out into different pages per device. You could ignore the 3 digit channel number and never peck numbers again, just stroke up on your favorite shows to switch the channel automatically.

We ran out of money because it was so expensive to license the nightly feed of TV guide (downloading a huge sql dump every night of the latest schedules as they got updated), and because all of our competitors were just stealing their data by scraping it from TV guide web sites instead of licensing it legally. (We didn't have Uber or OpenAI to look up to for edgy legal business practice inspiration.)

Oh well, it was fun while it lasted, during the days that everybody was carrying a Palm Pilot around beaming their contacts back and forth with IR. What a time that was, right before and after 9/11 2001. I remember somebody pointedly commented that building a Palm app at that time in history was kind of like opening a flower shop at the base of the World Trade Center. ;(

https://github.com/SimHacker/ConnectedTVSkinEditor

https://www.pencomputing.com/palm/Pen44/connectedTV.html

https://uk.pcmag.com/first-looks/29965/turn-your-palm-into-a...

Connected TV User Guide:

Overview: https://donhopkins.com/home/ConnectedTVUserGuide/Guide1-Over...

Setting Up: https://donhopkins.com/home/ConnectedTVUserGuide/Guide2-Sett...

Using: https://donhopkins.com/home/ConnectedTVUserGuide/Guide3-Usin...

Memory: https://donhopkins.com/home/ConnectedTVUserGuide/Guide4-Memo...

Sony: https://donhopkins.com/home/ConnectedTVUserGuide/Guide5-Sony...

Re: XSLT – Native, zero-config build system for the Web

#163

Post by deanebarker » Fri, Jun 27, 2025, 11:59 AM UTC

fergie wrote: post #32

What is this "XSLT works natively in the browser" sourcery? The last time I used XSLT was like 20 years ago- but I used it A LOT, FOR YEARS. In those days you needed a massive wobbly tower of enterprise Java to make it work which sort of detracted from the elegance of XSLT itself. But if XSLT actually works in the browser- has the holy grail of host-anywhere static templating actually been sitting under our noses thi…

> massive wobbly tower of enterprise Java to make it work

??

I was transforming XML with, like, three lines of VBScript in classic ASP.

Re: XSLT – Native, zero-config build system for the Web

#164

Post by mattbis » Fri, Jun 27, 2025, 12:00 PM UTC

Please let this come back since I was highly skilled at it and nobody uses it and I am the sads.. since it was a bit functional and a good challenge and was fun. And I would like to be paid to write teh complicated stylesheets again. Thanks

Re: XSLT – Native, zero-config build system for the Web

#165

Post by em-bee » Fri, Jun 27, 2025, 12:05 PM UTC

bambax wrote: post #132

em-bee wrote: post #46

i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain. my only option to fix this are javascript, xslt or a server side html generator. (and before you ask, static site generators are no better, they just make the generation part manual instead of automatic.) i don't actually care if the site is static. i only care that maintenance is simple. build tools are not simple…

> i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain You can totally do that with PHP? It can find all the pages, generate the menu, transform markdown to html for the current page, all on the fly in one go, and it feels instantaneous. If you experience some level of traffic you can put a CDN in front but usually it's not even necessary.

that's the server side html generator i already mentioned. ok, this one is not large, but it still ties me to a limited set of server platforms that support running php. and if i have to write code i may as well write javascript and get a platform independent solution.

the point is, none of the solutions are completely satisfactory. every approach has its downsides. but most critically, all this complaining about people picking the wrong solution is just bickering that my chosen solution does not align with their preference.

my preferred solution btw is to take a build-less frontend framework, and build my site with that. i did that with aurelia, and recently built a proof of concept with react.

Re: XSLT – Native, zero-config build system for the Web

#166

Post by _heimdall » Fri, Jun 27, 2025, 12:06 PM UTC

pacifika wrote: post #154

susam wrote: post #25

These days I use XSLT to style my feeds. For example: https://susam.net/feed.xml https://susam.net/feed.xsl

This does make me think why is a blog not just an rss feed.

I've built my personal site on XSLT a couple times just to see how far I could push it.

It works surprisingly well, the only issue I ever ran into was a decades old bug in Firefox that doesn't support rendering HTML content directly from the XML document. I.e. If the blog post content is HTML via cdata, I needed a quick script to force Firefox to render that text to innerHTML rather than rendering the raw cdata text.

Re: XSLT – Native, zero-config build system for the Web

#167

Post by colonwqbang » Fri, Jun 27, 2025, 12:07 PM UTC

diggan wrote: post #138

nolok wrote: post #115

Earlier quoted context omitted.

It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter if XSLT or SOAP or even XHTML in a way ... Those were defined as machine language meant for machine talking to machine, and invariably something go south and it's not really made for us to intervene in the middle; it can be done but it's way more work than it s…

> It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included. New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere…

There have been many such cycles, but the XML hysteria of the 00s is the worst I can think of. It lasted a long time and the square peg XML was shoved into so many round holes.

Re: XSLT – Native, zero-config build system for the Web

#168

Post by _heimdall » Fri, Jun 27, 2025, 12:09 PM UTC

fergie wrote: post #32

What is this "XSLT works natively in the browser" sourcery? The last time I used XSLT was like 20 years ago- but I used it A LOT, FOR YEARS. In those days you needed a massive wobbly tower of enterprise Java to make it work which sort of detracted from the elegance of XSLT itself. But if XSLT actually works in the browser- has the holy grail of host-anywhere static templating actually been sitting under our noses thi…

XSLT works, though if I'm not mistaken browsers are all stuck on older versions of the spec. Firefox has a particularly annoying bug that I run into related to `disable-output-escaping` not really working when you need to encode HTML from the document to render as actual DOM (it renders the raw HTML text).

Re: XSLT – Native, zero-config build system for the Web

#169

Post by bambax » Fri, Jun 27, 2025, 12:10 PM UTC

badmintonbaseba wrote: post #81

I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could. 1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards. 2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language,…

> XSLT 1.0 is still dominant

How, where? In 2013 I was still working a lot with XSLT and 1.0 was completely dead everywhere one looked. Saxon was free for XSLT 2 and was excellent.

I used to do transformation of both huge documents, and large number of small documents, with zero performance problems.

Re: XSLT – Native, zero-config build system for the Web

#170

Post by sam_lowry_ » Fri, Jun 27, 2025, 12:11 PM UTC

nithril wrote: post #146

badmintonbaseba wrote: post #81

I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could. 1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards. 2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language,…

XSLT/XPath have evolved since XSLT 1.0. Features are now available like key (index) to greatly speedup the processing. Good XSLT implementation like Saxon definitively helps as well on the perf aspect. When it comes to transform XML to something else, XSLT is quite handy by structuring the logic.

Keys were a thing in XSLT 1.x already.

XSLT 2+ was more about side effects.

I never really grokked later XSLT and XPath standards though.

XSLT 1.0 had a steep learning curve, but it was elegant in a way poetry is elegant because of extra restrictions imposed on it compared to prose. You really had to stretch your mind to do useful stuff with it. Anyone remembers Muenchian grouping? It was gorgeous.

Newer standards lost elegance and kept the ugly syntax.

No wonder they lost mindshare.