Den tors 23 juli 2026 kl 01:28 skrev Thomas Åkesson <[email protected]>:
> > On 22 Jul 2026, at 16:10, Daniel Sahlberg <[email protected]> > wrote: > > Den mån 20 juli 2026 kl 00:40 skrev Thomas Åkesson <[email protected]>: > >> >> On 19 Jul 2026, at 22:51, Daniel Sahlberg <[email protected]> >> wrote: >> >> Den tis 14 juli 2026 kl 14:52 skrev C. Michael Pilato < >> [email protected]>: >> >>> On Tue, Jul 14, 2026 at 5:14 AM Thomas Åkesson <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> I was unable to find any discussion on this deprecation of XSLT in the >>>> browsers. >>>> >>>> https://developer.chrome.com/docs/web-platform/deprecating-xslt >>>> >>>> I suspect this deprecation will break the Subversion web ui (folder >>>> listing and Collection of Repositories) and the customization point for >>>> these UIs (SVNIndexXSLT). >>>> >>>> We use this XSLT extensively so I am interested if anyone has >>>> experimented with server-side transformation? >>>> >>> >> httpd supports output filters ( >> https://httpd.apache.org/docs/current/en/developer/output-filters.html) >> and the documentation mentions XSLT transformations as one use case. I >> would probably investigate this a bit. >> >> >> Where did you find XSLT mentioned? >> > > Oh, there were several pages I looked at and I only linked one. Sorry... Last > part of this section: > https://httpd.apache.org/docs/current/en/filter.html#intro > > >> >> mod_transform (https://github.com/OutOfOrder/mod_transform) claims to do >> this but the code was last updated 15 years ago so I have no idea how much >> bitrot it has accumulated (I didn't try it). >> >> >> I have looked at that module but it seems unmaintained and I want to >> avoid using modules that don't ship with a typical httpd build. >> >> I was successful with mod_ext_filter, see separate mail in the thread. >> Likely works as a stop gap but I need to evaluate the performance. >> >> I assume, without any tests at all, that a module that is executed within > the httpd process will be significantly more performant than spawning an > external process. > > Have you thought about asking on the httpd lists? > > > Thanks, will consider it after some more testing. > > > >> >>> >>> It does cause me to wonder though... Would a SVNIndexCSS feature be >>> interesting -- where we generate that HTML with quite a bit more structure >>> (divs, ids, etc.) and allow folks to point to a CSS file that at least >>> pretties it up? >>> >> >> Interesting idea. If we also provide a way of injecting some custom HTML >> first (or last) in the response, it should be possible to use javascript to >> manipulate the DOM enough to transform the basic directory listing into >> whatever form desired by the server admin. I would suggest we do as little >> as possible on our side (an id on the outer <ul> and some classes on the >> <li>s). >> >> >> Yes, something along those lines, preferably including the ability to use >> htmx instead of direct DOM manipulation from Javascript (supporting either >> inclination). >> > > Which means, as I understand it, depending on another javascript framework > which we don't know if it exists or how much it has changed in 5 years. I > would prefer if we leave that outside of the scope for Subversion (for > reasons, see Brane's e-mail else-thread). > > > Yes, absolutely. I am not suggesting that the Subversion project should > include htmx or any other frontend project. Just looking for an extension > point to replace XSLT which can serve a reasonably wide array of > approaches. I have grave concerns about the whole JS ecosystem primarily > regarding the churn in dependencies which require too much maintenance > effort. > We agree :-) > > >> The following would provide flexibility: >> - class/id on list, class on list items preserving whether item is >> dir/file/repository >> - snippet added in <head> (in order to include scripts, css, etc) >> - snippet before list. >> - snippet after list >> - wrap list in div (would allow a flex layout without JS DOM >> manipulation, easy to insert a sibling to the list using HTMX) >> >> With "snippet" I mean a static piece of html defined in a file (or >> possibly Apache conf if deemed practical). Possibly some very simple >> variable substitutions, handling title, revision, svn-version. >> > > We are sort of re-implementing mod_include if we go this route. Don't know > if we can re-use something from there do do this? I'm inclined to do a > minimum viable solution at first to avoid implementing a full-blown CMS in > C... > > > I have considered mod_include and it could be a viable alternative > (although its age is showing). Not sure how mod_dav_svn would hand over to > mod_include in a clean way, beyond my knowledge of httpd internals. > > What are your thoughts on mod_lua? I am currently experimenting with > mod_lua as output filter using a streaming XML parser. Seems like LUA could > provide a flexibility similar to XSLT while executing efficiently in httpd. > Just from skimming through the docs it looks promising. If you can make it work, I'd really love to put that into the FAQ (and probably as a news item as well). Cheers, Daniel
