Re: Deprecation of browser XSLT - SVNIndexXSLT

On 23. 7. 2026 00:47, Thomas Åkesson wrote:
>
>> On 20 Jul 2026, at 14:19, Branko Čibej <[email protected]> wrote:
>>
>> On 20. 7. 2026 14:01, Timofei Zhakov wrote:
>>> On Tue, Jul 14, 2026 at 2:52 PM C. Michael Pilato 
>>> <[email protected]> wrote:
>>>
>>>     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?
>>>
>>>
>>>     This is unfortunate, but hopefully the situation isn't quite as
>>>     bad as you might think.
>>>
>>>     IIRC, the XSLT variant of the mod_dav_svn directory listing
>>>     feature is entirely optional.  When a GET request arrives aimed
>>>     at a versioned directory, if SVNIndexXSLT is set, an XML
>>>     response referencing the template is generated; but otherwise,
>>>     an HTML response is still generated.  So this deprecation might
>>>     force admins to turn off the SVNIndexXSLT "flavor", resulting in
>>>     some ... undecorated directory listings.  But at least I expect
>>>     the listings will still "work" (for the most basic of
>>>     definitions of "work").
>>>
>>>     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?
>>>
>>>
>>> Just to throw it in: I think a built-in reasonably usable web 
>>> interface would probably be the most wanted feature that we can do 
>>> in today's reality of Subversion.
>>
>>
>> I think it would not, it's bad idea and horrible waste of time. Just 
>> thinking of the authn/authz/security aspect of such a web interface 
>> makes me shudder. Subversion hosting services exist, with much better 
>> user interfaces than we could ever hack up given the resources we 
>> have. If you're thinking of some kind of server-side-generated 
>> interactive web UI written in C ... yeah, just no. People who want 
>> something lightweight can use ViewVC or maybe Trac.
>>
>> The XSLT support happened at a time when there were few alternatives, 
>> and some of us (i.e., me) thought it would be a nifty idea. I'm still 
>> embarrassed by it. Just thinking of the wasted lines of code for 
>> something probably no-one uses, ouch.
>
> I hope I can lighten up your view of this extension point.
>
> We, Simonsoft, have during the last 18 years successfully relied on 
> this mechanism to serve our UI from the true subversion URL. Given 
> that it has worked reliably for more than 2 decades with very little 
> maintenance… not too bad.
>
> I do agree that producing a great web UI is not a priority for the 
> core Subversion project. But providing compelling extension points is 
> important to enable others, open-source or commercial. We are very 
> grateful for the XSLT extension point but it's time to find a new 
> approach.


That does ease my mind, thanks. I wasn't aware the transformations were 
used.

-- Brane