You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The HTML -in-Canvas APIs make use of an attribute, drawable, on elements in the canvas subtree to indicate those elements need special treatment to support drawing them into a canvas. The HTML whatwg/html#11588 currently puts that attribute on HTMLElement but to support all content we would like to put it on HTMLOrSVGOrMathMLElement.
This issue is seeking MathML-core approval to add the drawable attribute to HTMLOrSVGOrMathMLElement.
I think assuming there's no problems with rendering inner MathML or SVG components in that context (can't think why there would be) this is a good idea. We want to keep the platform as coherent as possible and something only working for HTML would seem rather arbitrary.
Allowing MathML to be drawn in canvas sounds great to create 2D or 3D schemas like https://fred-wang.github.io/TeXZilla/examples/toImageWebGL.html without having to wrap the content into an SVG image and the limitation implied by this trick. It also seems that if HTML-in-canvas gains popularity, we should definitely allow SVG/MathML for platform consistency as Luke commented.
The only bad thing I'm aware of is the risk of information leakage with :visited style and MathML links described in appendix F but that's something that exists for HTML/SVG too so I expect similar mitigations will apply (e.g. canvas tainting or not matching the :visited selector).
The readback-allowed-rendering mode used for HTML-in-Canvas, and hopefully for SVG in canvas, removes visited link styling from all elements. At some point I went through the MathML spec to find all the possible privacy leaks and didn't find any not already discussed in the PR, though we are still pending extensive testing.
Activity
schenney-chromium commentedon Sep 17, 2026
@foolip @fred-wang @lukewarlow
lukewarlow commentedon Sep 17, 2026
I think assuming there's no problems with rendering inner MathML or SVG components in that context (can't think why there would be) this is a good idea. We want to keep the platform as coherent as possible and something only working for HTML would seem rather arbitrary.
fred-wang commentedon Sep 18, 2026
Allowing MathML to be drawn in canvas sounds great to create 2D or 3D schemas like https://fred-wang.github.io/TeXZilla/examples/toImageWebGL.html without having to wrap the content into an SVG image and the limitation implied by this trick. It also seems that if HTML-in-canvas gains popularity, we should definitely allow SVG/MathML for platform consistency as Luke commented.
The only bad thing I'm aware of is the risk of information leakage with
:visitedstyle and MathML links described in appendix F but that's something that exists for HTML/SVG too so I expect similar mitigations will apply (e.g. canvas tainting or not matching the:visitedselector).schenney-chromium commentedon Sep 18, 2026
The readback-allowed-rendering mode used for HTML-in-Canvas, and hopefully for SVG in canvas, removes visited link styling from all elements. At some point I went through the MathML spec to find all the possible privacy leaks and didn't find any not already discussed in the PR, though we are still pending extensive testing.
davidcarlisle commentedon Sep 28, 2026
Meeting on 2026-09-28 appoved adding this