> 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] > <mailto:[email protected]>>: >> >>> On 19 Jul 2026, at 22:51, Daniel Sahlberg <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Den tis 14 juli 2026 kl 14:52 skrev C. Michael Pilato <[email protected] >>> <mailto:[email protected]>>: >>>> On Tue, Jul 14, 2026 at 5:14 AM Thomas Åkesson <[email protected] >>>> <mailto:[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. >> >> 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. Thanks, Thomas Å.
