Hello everybody,
On 2026-06-09 06:03, Brian E Carpenter wrote:
On 09-Jun-26 02:41, Russ Housley wrote:
On Jun 3, 2026, at 3:04 AM, Eliot Lear <[email protected]> wrote:
�_ Do we need to be clearer on what "incidental use" is?
I don't think so. There is judgment involved here, but whether math
is considered incidental to the purpose of a figure should become
clear with time. RPC policies might evolve to handle that better
than this policy can.
Imagine a flowchart as a figure. Is "x > y" at a decision point in
the flowchart a incidental use of math? Based on the rest of the
sentence I think not. It requires that "any math content is only
illustrative".
Maybe we need a weasel word or two, because we are never going to
resolve this precisely in a policy document.
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.
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 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°", the letters just happen to be
in the Unicode repertoire. If an author wants to use LaTeX or MathML for
these cases, we shouldn't block that, but we shouldn't force it, either.
If the RPC wants all these cases in e.g. MathML in the published RFCs,
we shouldn't block this, but we shouldn't force authors to produce such
simple formulæ with a notation they may have to learn.
Where I would start to see workarounds is using Unicode superscripts and
subscripts, and other tricks for more complex formulæ. In other words,
let's use Math-specific notation (LaTeX, MathML,...) for those cases
where until now it hurt to do Math, and where we can expand the range of
usable Math in RFCs (i.e. where up to now an author might just have
given up).
As for "ASCII art or SVG renderings of math must not be used in any
format except for the Text publication format, as noted.", there's a
fundamental problem in this sentence, because I don't see how one would
use SVG in a Text publication. For complex formulæ, ASCII art, or more
correctly Unicode art, is the only option we have.
As for "Incidental use of math in figures can still use textual or SVG
alternatives, provided that any math content is only illustrative.",
there are various issues. For one, figures in general are an
accessibility problem, which is usually solved with a textual
alternative. This textual alternative may be the actual textual part of
the RFC (in which case the markup that is supposed to give the textual
alternative to the figure should say as much), or it may be separate
text. If that text contains the relevant formula in a reasonable way, it
should be possible to declare the formula in the actual figure as
"incidental". If that's part of the common understanding of
"incidental", then I'm okay with this.
Also, it's rather easy in SVG to create complex formulæ in a single
<text> element, e.g. by using attributes on <tspan> elements to make
text look like superscripts and subscripts. That's most probably not
what we want, because a screen reader couldn't infer that some of the
text is a subscript or a superscript. But simple straight text such as
"x > y" should still be okay here.
While I'm at it, I'd also suggest that we remove the word "crude" from
the sentence "In HTML, native support can then be used in place of such
crude alternatives; see Section 3 for more on this.". While I have
fought for Unicode (and therefore in some sense against ASCII) for a
long time, I don't think I ever have called ASCII "crude".
And hopefully the last comment in this mail: The draft has an item
saying "The chosen implementation should allow representation of both
the meaning and the formatting of the mathematical content.". MathML
would indeed allow both. For the "x > y" example (just using that
because it's simple enough, not because I think MathML needs to be used
here), presentation markup would be something like:
<mrow>
<mi>x</mi>
<mo>></mo>
<mi>b</mi>
</mrow>
whereas content markup would be something like:
<reln>
<gt/>
<ci>x</ci>
<ci>y</ci>
</reln>
I think Martin Thomson in an earlier mail asked about whether MathML
would be able to represent any semantics. I think it's easy to say that
that's not possible, because it's always possible that some
Mathematician comes up with a new theory that isn't covered by MathML.
But a quick look at e.g.
https://www.w3.org/TR/MathML3/chapter4.html#contm.opel should convince
the reader that a very wide range of Math is indeed covered.
Regards, Martin.
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
