On 22. 7. 2026 16:10, Daniel Sahlberg 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?
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).
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 would rather rip out that XSLT support we have now and instead try to
integrate with mod_include so that users can install that on top of
mod_dav_svn to get nicer directory listings.
-- Brane
