TextFormatter uses XSLTProcessor, which might get deprecated/removed from browsers

[mfreed7]

Hello, I'm reaching out to point out that TextFormatter, specifically right here:

• https://github.com/s9e/TextFormatter/blob/master/src/render.js#L7

uses XSLTProcessor. There's a discussion happening about whether to deprecate that API from browsers. So I wanted to point that out, and perhaps suggest including a polyfill or other workaround, so that in case it does get removed from browsers, no TextFormatter functionality is lost.

I found this library via several sites that appear to use it, and appear to be broken if XSLTProcessor is removed:

• https://nothing.community/
• https://tvheadend.org/
• https://telekomunikace.cz/
• https://reflot.es/

There are a few options for JS-based XSLTProcessor implementations

• Saxonica
• A WASM polyfill I wrote
• Likely others

Happy to answer questions if needed.

[JoshyPHP]

Hi,

Thanks for the heads-up. I'm going to kick the can down the road on this one but I'll look into using a polyfill whenever major browsers start dropping support.

[mfreed7]

Thanks for the heads-up. I'm going to kick the can down the road on this one but I'll look into using a polyfill whenever major browsers start dropping support.

Ok, thanks! There is time. But Chrome now plans to turn off support in v155, around Nov 2026. And much earlier than that in pre-stable (e.g. Beta) channels. Anyway, I appreciate the comment, and let me know if I can answer any questions about the polyfill when the time comes.

[GreXXL]

@JoshyPHP hope you're doing fine! I just wanted to check in with you on this issues as the time this will become more troublesome is approaching quickly. Do you have this on your agenda to be addressed in the near future?

[tobyzerner]

Hi @JoshyPHP, I'm also interested in planning ahead for a solution to this. Unfortunately it looks like the inclusion of @mfreed7's polyfill will bloat the JS size to 500kB+ gzipped (https://bundlejs.com/?q=xslt-polyfill). Is that just a tradeoff that we'll have to accept, or is there an alternative approach that can be taken?

[imorland]

@JoshyPHP we are getting reports from users using the new Chrome beta that this is now removed in the channel too.

Yes we could add the polyfill to Flarum core, but I'm hesitant due to the additional size of it. Have you had any thoughts on your side for a solution yet? Seems like the day is coming fairly soon now where we'll need a solution to this

[JoshyPHP]

There are many ways to replace the client-side XSLT renderer, each with varying tradeoffs. In no particular order :

1. Take the PHP source of the native PHP renderer and send it through a transpiler to generate native JS. In most cases (as long as the templates do not require complex XPath) the renderer only requires basic code.
2. Create a helper that translates the XSLT templates to another templating engine such as Handlebars.
3. Create a RendererGenerator that generates native JavaScript.

Most solutions will involve modifying s9e\TextFormatter\Configurator\JavaScript because there's a strong assumption that XSLT templates can be handled directly by the renderer. In theory, you can always extend the class to monkeypatch the parts that don't fit.

The path to using a native JavaScript renderer would be to create a RendererGenerator modeled after the PHP renderer generator. A lot of the PHP renderer generator is overengineered accessories; A minimalist implementation would only really need a JavaScript flavour of the PHP serializer which converts an intermediate representation of the XSL template into PHP code. The XSL->IR step is handled by TemplateParser and you can get some idea of how it works based on its test data. You'd need to essentially copy/paste the serializer and replace the output of every serialize*() function. You'll only need to have a JavaScript version of XPathConvertor. Most XPath queries (e.g. @url) are easily translated to native code. Complex XPath queries require an XPath engine. You'd need to ignore those at least in the beginning. They are rare enough that you could create a special case where known untranslatable XPath queries are converted to hardcoded native JS created by hand. For a JS renderer generator, you could extend every class in the Convertors directory to override their return value to produce JS rather than PHP. Some of them already fortuitously produce valid JavaScript such as the Comparisons one, due to the common programming syntax around comparison operators.

Feel free to tag me in any relevant discussions. I miss a lot of notifications these days but I'll try to give them a glance at the very least.

[GreXXL]

@JoshyPHP are you going to address this in s9e before we run into issues by Chrome removing the feature which seems very imminent?

I think it's not ideal if every system using s9e patches this themselves.

Help would be very much appreciated on this especially since we could still at least have this propels addressed in Flarum 2 at least.

If it's a time / prioritization issue maybe the Flarum Foundation could help pushing this as a priority? Thanks for your hard work!

[JoshyPHP]

@JoshyPHP are you going to address this in s9e before we run into issues by Chrome removing the feature which seems very imminent?

Almost certainly not in the near future (<= 3 months) and likely not this year. What type/level of resources would you be able to commit to this task? I agree with you that patching it entirely on your side wouldn't be good for the long term maintenance; If we can collaborate to implement a proper solution in the library that's what I'd prefer.

I don't know at the moment what's the best conceptual design for a XSLT-less renderer, even if I mentioned a few leads above. An important factor is how much of XSLT we really need to support. That's something you can help with by providing data from real world usage.

Let me know if you want to move this discussion somewhere else.