Re: Deprecation of browser XSLT - SVNIndexXSLT
Branko Čibej <[email protected]>
| Newsgroups | gmane.comp.version-control.subversion.devel |
|---|---|
| Organization | The Apache Software Foundation |
| Message-ID | <[email protected]> |
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