Definition of invalid markup for radicals #73
Comments
|
My preference would be either to define msqrt to be valid if they have only one in-flow child (but I don't think that's impossible for backward compatibility) or otherwise keep the current definition for invalid radicals (which means that implementers would have to live with this special handling). |
This is not inconsistent or a problem to be solved, it follows from the general design of mathml. msqrt takes a base and an index so has a schema with a fixed number of children so is like msup and msub mroot abstractly takes a single term so like all such elements allows any number of children that are an "implied mrow" so like mfenced, mpadded, and in particular like menclose We discussed this at some length on the call, it's a shame you were not there but it does basically come back to the general issue of given an element with too many element children do you just fall back and treat the whole thing as an mrow, or do you imply an mrow around all the last (or first) children so treat it as if it had two.
I don't think that would be an improvement or consistent with the design of the rest of mathml, as noted above.
Yes if you consistently wrap the last then the extras land in the index, you could just accept that but
there isn't any reason to treat mroot specially here, it would be more consistent to treat all elements that take a fixed number of children in the same way,.
Which I think is why we originally said that invalid markup with too many children should be simply treated as an mrow, that is still a viable option for mroot, |
|
Maybe it's obvious for you how MathML was designed but it does not seem absurd at all for someone to wonder why an empty msqrt even makes sense or why one radical element can be invalid while the other cannot. So this issue is just about agreeing whether we keep the current invalid definition or decide to change it. I tried to keep the discussion separate from how to implement a fallback for invalid markup, which is much more complex and I don't think the CG is in position to decide anything on this (so I'm actually glad I was not working last week as we had already discussed this much more than necessary IMHO...). Just some quick remarks:
|
|
On Thu, 21 May 2020 at 09:58, Frédéric Wang ***@***.***> wrote:
Maybe it's obvious for you how MathML was designed but it does not seem
absurd at all for someone to wonder why an empty msqrt even makes sense or
why one radical element can be invalid while the other cannot. So this
issue is just about agreeing whether we keep the current invalid definition
or decide to change it.
there are lots of valid constructs that have no obvious mathematical
meaning that may be user error or used for partially written terms in an
editor or whatever.
<msqrt></msqrt> is empty but it's really no different to
<msqrt><mrow></mrow><msqrt> which would still be valid even if you changed
msqrt to take exactly one child.
There was no consensus to change the validity of mroot or msqrt, the
discussion was just about whether you should change the layout behaviour of
an invalid mroot with more than two children.
I don't have strong opinion of how the invalid cases are laid out, but if
we change mroot we should ideally change the other elements with fixed
numbers of children as well, to avoid introducing new inconsistencies as
you comment below.
------------------------------
I tried to keep the discussion separate from how to implement a fallback
for invalid markup, which is much more complex and I don't think the CG is
in position to decide anything on this (so I'm actually glad I was not
working last week as we had already discussed this much more than necessary
IMHO...). Just some quick remarks:
-
"making a per-element choice" is basically inconsistent treatment. And
we'll have inconsistency anyway since mmultiscripts validity is more
complex than child count while tabular elements are never invalid in
MathML3/HTML/CSS.
Yes as I say above, it would be better to treat elements with fixed numbers
of children in the same way.
-
- "implied mrow" is not a concept in MathML Core. There are two
implementation details to try to emulate that behavior: anonymous nodes or
special handling in the layout algorithm (the latter is what is described
in the spec). None addresses the mismatch between DOM tree and layout tree.
"implied mrow" is mostly a documentation device so if you don't like the
term just call it "element with arbitrary number of children that acts as a
container for determining the size of stretch operators" as you say core is
already dealing with containers on various aspects and doesn't need to
introduce a new term but the name is a minor detail and helps when cross
referencing what mathml3 says.
|
|
Just to be clear: this issue is different from #136 ; if we decide to make mroot with a number of children different from 2 valid, or msqrt with a number of children different from 1 invalid then that will affect the error warning, MathML Core markup validators, etc and we must ensure that all the rest of the spec works with that change. For #136, this only affects the visual feedback and we don't care if people get weird results with invalid markup (e.g. inconsistencies with equivalent valid constructions with explicit mrow) as they should really fix their markup instead or it's just a temporary rendering during a DOM change. |
|
At the July 27 meeting, we resolved to close this and agreed to go with the current spec text:
Any other element that requires a fixed number of children should be (and are already) treated similarly. |
|
I'm reopening since the needs-tests label was there, so we need to double check the coverage. |
|
Closing this issue:
|
|
I am discovering this issue quite late, but will leave a comment for posterity that to my intuition an To my taste, "the square root of two" looks even better as The case with 3 or more children is a bit less intuitive. Still, mapping that case also to a |
This has been reported several times by @rwlbuis . This is about how we define invalid markup for radicals.
Note that this issue is different from #136 which is about how invalid markup in general should be treated. As a reminder, the current version of the MathML Core text (and tests and chromium's implementation) for invalid markup is very clear: fallback to mrow layout for invalid markup elements, as they are defined in MathML3. This is the easiest option to address request to keep content visible and is straightforward to implement.
So to come back to the present issue, MathML Core currently follows validity from MathML3, which is a bit inconsistent:
In particular Rob feels an empty root is weird and should be invalid, which is certainly something we can do for this edge case. However, to solve completely the inconsistency, we would need to claim that msqrt must have exactly one element. I believe this is certainly the most elegant solution if we were defining MathML from scratch, but this will seriously break backward compatibility.
The alternative is to allow mroot to have any number of children, using some kind of layout sketched in https://github.com/mathml-refresh/mathml/issues/15#issuecomment-468584557 ; so that all mroot elements actually become valid. However, note that the proposal there is to wrap extra arguments in the last child (i.e. the index) which is inconsistent with msqrt (all elements belong to the base). So instead mroot should be defined to layout all the but the last child in the base ; and the last child as an index. But then there are again open questions for mroot with 0 or 1 child and whether special handling is needed to handle index kerning specially in these cases.
Obviously, this still does not solve the issue since now people would wonder why mroot accepts any number of elements while similar elements like msup don't. Also, as mentioned in #136, this is adding a lot of new inconsistencies between definitions based on layout tree VS definitions based on DOM tree (e.g. CSS rules).
The text was updated successfully, but these errors were encountered: