On Wed, Jan 28, 2026, at 12:29, Paul Hoffman wrote: > It's a short document, so I doubt I missed it, but: what is the > motivation for prohibiting what works now? It doesn't work "all that > well", but that's true of at least a quarter of RFCXML.
The motivation has a few angles: * Accessibility. An SVG drawing of math is only accessible to sighted users (conceding that an LLM might be able to transform an image into something accessible, but no need for that). * Consistency. Equations that are rendered through a single coherent process can be more readily processed and rendered consistently. * Minor stuff like styling is more feasible with something like MathML. > Will I really be prohibited from saying "2^128" or "packet size / relay time"? Probably not. As with any of these policies, judgment is a necessary part of the application of policy. I don't know what 2^128 ends up being in the new world, but it already manifests as 2<sup>128</sup> in many instances today. Having that in text without math wrapping is probably better than using math in some cases. > If I can express a necessary equation in a simple SVG figure, will I > really be prohibited from doing so? I would hope that the RPC, once they have better tools, would not allow that document to proceed without first replacing it with whatever form is ultimately adopted. In light of your question and on re-reading the text, I do think that the prohibition might need to be tuned a little to consider the use of Unicode symbols for variables. If I have to refer to a λ parameter in text, having that appear directly is potentially OK, as opposed to having to type $\lambda$ and invoke the inline math handling. That said, the latter has value and might still be easier to handle for those of us without Greek characters on our keyboards (on Windows at least, the emoji picker is how I find Greek letters and the usability sucks). My view is that this sort of thing is best left for style guides and not policy, but maybe this document can say something sensible on that point. > I hope that this document does not reach consensus without saying what > is wrong with the current methods. I assume that this is just a request for discussion here. Which is reasonable. On the other hand, I don't think that there is much value in litigating the extent of the badness of present practice. We did that for SVG, but didn't end up capturing much (if any) of it in the final product of the group. -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
