3 ms·
That approach makes sense for technologies outside of the scope of the HTML5 spec, but for a core element like <math> it seems rather silly to propose external
by jokamoto 13y ago
That approach makes sense for technologies outside of the scope of the HTML5 spec, but for a core element like <math> it seems rather silly to propose external implementation using custom elements (and therefore requiring Javascript availability, which shouldn't be taken for granted).
- vidarh 13y agoThe engine obviously does support javascript, so an alternative is ensure extensions can "plug in" these custom elements and implement them in JS in a separate sandbox regardless of whether JS is enabled or disabled for the page itself. Less code with direct OS access sounds good to me.
- jokamoto 13y agoBut you'd still have to download and install the extension in order to use it (or, as was somewhat glibly proposed in a comment on the bug, Google would need to ship a version of MathJax with Chrome). Anyone without the extension and with JS disabled would still be out of luck. So far as direct OS access, I'm having trouble envisioning a situation in which the layout code for MathML would be any more vulnerable than SVG (or the rest of the layout engine for that matter).