Browser XSLT deprecation

[takesson]

The XSLT engine is being deprecated from mainstream browsers. Chrome is leading the pack but Firefox, Edge and perhaps Safari will follow.

https://developer.chrome.com/docs/web-platform/deprecating-xslt#timeline_for_chrome

Is this list of impacted endpoints correct?

• Subversion index
• Rweb log
• Rweb list (also used via ajax)

I have tested the JS / WASM polyfill, works but some small degradation (some delay). Should be acceptable for log and list if it is straight forward to get the extra script tag into the response from PHP.

The svn index would require a filter to insert the script tag. It works with this LUA filter:
simonsoft/subversion-webui#3

Consider using the same environment variable in PHP:

SetEnv XSLT_POLYFILL_URL /static/xslt-polyfill.min.js

[takesson]

The LUA filter can handle Rweb log and list as well but it's a messy Apache config that I would like to avoid.

[solsson]

I think the list of endpoints is correct. Is there any svn XML consumer? I'm not aware of one in Rweb but I'd have to check. Helps a lot if we can move rendering server-side.

[takesson]

I am not aware of any XML consumer. Long term, we are moving towards history backed by SolR.

Are you considering executing the XSLT in PHP?

I am fine with the JS polyfill for Rweb log and list because a little lag can be acceptable there. For Subversion index I am likely doing a LUA + Webawesome replacement.

[solsson]

Long time ago I tested some apache xslt mod but they seem unmaintained. However "Generating HTML from some other type of response" in https://httpd.apache.org/docs/current/mod/mod_ext_filter.html#examples looks interesting (with saxon or xsltproc CLI) if we can match only the svn/rweb responses so it doesn't apply to all xml responses.

[solsson]

It could be that LUA is faster though, due to no subprocess or stdio overhead.

[takesson]

I have tested with external filter but felt that it is a last resort since generally considered best for experimentation. Also needs some thought regarding security.

See my thread on svn dev for a working example.

[takesson]

Is it difficult to get the JS polyfill script tag into the XML because the XML is entirely generated by svn cli?

[solsson]

Is it difficult to get the JS polyfill script tag into the XML because the XML is entirely generated by svn cli?

If I remember correctly there's no way to tweach the mod_dav_svn response beyond SVNIndexXSLT. Maybe you'd need to use a response (body) filter? Unless SVNIndexXSLT allows script injection 🙂

[takesson]

Is it difficult to get the JS polyfill script tag into the XML because the XML is entirely generated by svn cli?

If I remember correctly there's no way to tweach the mod_dav_svn response beyond SVNIndexXSLT. Maybe you'd need to use a response (body) filter? Unless SVNIndexXSLT allows script injection 🙂

Right, that's exactly what this LUA filter does (a side business of that repo):
simonsoft/subversion-webui#3

Take a look at the wa-page template in the primary business of that repo. The LUA module + htmx + Web Awesome proved extremely productive. You need to install on a server to see it in action.