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