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... Cheers, Daniel
