Re: Deprecation of browser XSLT - SVNIndexXSLT
Thomas Åkesson <[email protected]>
| Newsgroups | gmane.comp.version-control.subversion.devel |
|---|---|
| Message-ID | <[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] <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? > 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. > >> >> 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). 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. Thanks, Thomas Å.