v147 · HTML · Migration Guide

Migration Guide

Practical steps for moving off inline XSLT → SVG rendering: detect affected XML, test the JavaScript bridge, and compare the durable SVG parsing replacement.

Most sites are not affected. The v147 change targets XML files served as application/xml or text/xml that include an <?xml-stylesheet type="text/xsl"?> processing instruction whose stylesheet produces an SVG document. Programmatic XML parsing and direct SVG delivery remain available migration paths.

migration lab

Choose a source pair or edit the XML and XSLT directly. The analyzer checks the exact processing-instruction pattern, the XSLT runner uses XSLTProcessor, and the replacement path builds SVG with DOMParser.parseFromString(markup, "image/svg+xml").

XML document

XSLT stylesheet

xml-stylesheet → SVG Not run

Analyze a sample to see whether it matches the removed v147 path.

XSLTProcessor Not run

Runs the stylesheet through the JavaScript API when available.

DOMParser image/svg+xml Not run

Parses the generated SVG replacement and reports parser errors.

createElementNS Not run

Checks the SVG namespace fallback used by framework renderers.

analysis

Select Analyze affected pattern to inspect the processing instruction and stylesheet output.

rendered result

Run one of the migration paths to render or diagnose the output.

migration option 1: serve SVG directly

Convert XML → SVG at build time

Run your transform offline and commit the output as .svg files. Serve them with Content-Type: image/svg+xml, which avoids client-side XSLT entirely.

# Build step: Saxon XSLT processor
java -jar saxon.jar -s:data.xml -xsl:transform.xsl -o:output.svg

# Or libxslt
xsltproc transform.xsl data.xml > output.svg

migration option 2: JavaScript transform bridge

Use XSLTProcessor while it remains available

XSLTProcessor can still demonstrate the same transform in the lab above. Treat it as a compatibility bridge for this v147 SVG path; direct SVG generation, server-side rendering, or a maintained library are better long-term migration targets.

const processor = new XSLTProcessor();
processor.importStylesheet(xslDoc);
const resultDoc = processor.transformToDocument(xmlDoc);
const svg = document.importNode(resultDoc.documentElement, true);
target.replaceChildren(svg);

migration option 3: generate SVG with DOMParser

Parse the SVG document explicitly

The lab's durable path reads the XML data, creates SVG markup, parses it with DOMParser.parseFromString(svg, "image/svg+xml"), and inserts only a valid SVG namespace result.

const svgDoc = new DOMParser().parseFromString(svgSource, "image/svg+xml");
const parserError = svgDoc.querySelector("parsererror");
if (parserError) throw new Error(parserError.textContent);
target.replaceChildren(document.importNode(svgDoc.documentElement, true));

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗