On Jun 9, 2026, at 11:59, Martin J. Dürst <[email protected]> wrote: > I agree with the fact that we cannot resolve this precisely in a policy > document. However, I think that the boundary the document is trying to set > forces too much to be "Math" when simple text would do the job without any > problems.
I have the same impression. >> Is "x > y" illustrative in plain text? From a quick test, a screen reader is >> very likely to read it as "x y". Are we going to require MathML for such a >> case? > > If a screen reader reads "x > y" as "x y" rather than as "x greater than y" > (or at least something that not just drops the ">", such as "x greater-than > sign y"), then I think this is the screen reader's fault, not the author's. The document may fail to distinguish “mark as Math/formal expression/code” from “use MathML”. Marking up math/code in running text is currently not very well supported. > The document says "That guidance should include updates to style guides to > provide advice on how to decide when math forms are to be preferred over > ASCII or Unicode workarounds that have been historically used in the series.". > > It would be my reading that "x > y" is NOT an ASCII workaround, it's just > using ASCII because the formula is within the ASCII repertoire. The same > might be said for "α + β + γ = 180°”, Well, that is not ASCII… The point is not about ASCII, but plain text. (Plain text as opposed to the 2D text (“ASCII art”) tricks we have been playing (see Figure 1 of https://www.rfc-editor.org/rfc/rfc9100.txt for an example), which indeed should no longer be used once we have workable math in RFCXML.) > Where I would start to see workarounds is using Unicode superscripts and > subscripts, and other tricks for more complex formulæ. <sub>/</sup> are not tricks, they are markup. They mix well with plain text. (I don’t think using "2<sup>64</sup>" is “math”, and neither is “B<sup>ε</sup> tree”.) … skipping more useful comments from Martin… Grüße, Carsten -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
