Simplify embellished operator? #115

fred-wang · 2019-07-05T15:20:50Z

MathML core definition is here:
https://mathml-refresh.github.io/mathml-core/#embellished-operators

I need to think more about it, but just opening the issue for the record.

When you are on a given element, you know whether it is an embellished
operator by looking only at the element and its descendants.
There is only one potential embellished operator child to check but
that the tree walk is noy necessarily of linear complexity with respect to
the tree
depth (e.g. to know whether a subtree of nested mrow-like mspace elements
is space-like you may have to walk the whole subtree).
To know whether it is outermost embellished operator, you need to check
whether the parent is an embellished operator.
This is making (re)layout potentially difficult.
When you are in an mrow element, you know whether a given child is an
outermost embellished operator (== it is an embellished operator and has no
space-like siblings)
so you know which lspace/rspace values to use for spacing and whether to
fire vertical stretching on it.
When you are in an munder/mover/munderover element you know whether the
script is an outermost embellished operator (== it is an embellished
operator)
whether to fire horizontal stretching on them. The base is never an
outermost embellished operator (if it is an embellished operator then so is
the element) so with the current MathML core definition it will not stretch.

Firefox essentially maintains some data on the layout tree to indicate
embellished operator properties and update only during tree
mutation/construction. For (4) it also tries to restretch munderover, if it
was not stretched by an ancestor.

WebKit always goes down the embellished operator hierarchy but has a less
complete implementation (no space-like elements). It also always stretches
embellished operators (even when not outermost) at each step, which seems to be what the MathML 3 spec suggests.

In any case, all of this is potentially forcing a lot of relayout, especially
when performing operator stretching, which is already complex to properly plug in
layout steps (#111)

Can we simplify things?

Removing munder/mover/munderover from the list of embellished operators could
simplify horizontal stretching.

NSoiffer · 2019-07-05T19:49:39Z

Although it is theoretically possible to construct some deep nestings for embellished operators that cause multiple layouts [at least that's my memory], in practice almost all the time you'll layout the stretchy character once at it's default size and then once more when you determine what it's size should be either in the containing mrow or munder/mover/munderover. The only exception would be mtable where layout is more complicated. In practice, there shouldn't be much relayout needed.

Can you provide a non-contrived case where you are seeing a lot of extra layout?

fred-wang · 2019-07-07T08:53:15Z

I'll go back to this when I fixed #111

fred-wang · 2019-08-06T18:07:28Z

After #111 is fixed, the size constraints simplify how to deal with embellished
operators and the layout is not so bad. So the update is:

(1) is still an issue.

(2) is no longer an issue, the "outermost embellished operator" definition has
been removed (see details in 3 and 4).

(3) was not an issue, as explained the "outermost embellished operator"
definition was actually not needed in that case. What we have now:
- https://mathml-refresh.github.io/mathml-core/#layout-of-mrow
checks whether the mrow is an embellished operator to calculate "add-space"
(i.e. element is an "outermost embellished operator")
- https://mathml-refresh.github.io/mathml-core/#dfn-algorithm-for-stretching-operators-along-the-block-axis
stops early when a stretch size constraint was passed by ancestors
(i.e. element is not an "outermost embellished operator")

(4) is no longer an issue
https://mathml-refresh.github.io/mathml-core/#algorithm-for-stretching-operators-along-the-inline
the base is laid out differently depending on whether there is a
stretch size constraint (i.e. whether element is not an
"outermost embellished operator").

Embellished stretchy operators can still be laid out twice, I moved this issue
to #124.

Regarding (1), it is still a bit annoying that we might theoricaly have to
browse a whole subtree (or maintain a cache like Gecko does) even if such
subtrees are rarely large in practice. If a small change happens somewhere in
the descendants of an element, then that may require relayout of its parent if
the element goes from/to being to not being an embellished operator.

We need more dynamic tests to see if things behave correctly (issue #57).
So even if that's not terrible in practice, it's still more work for implementers
to address what are likely only edge cases.

fred-wang · 2020-05-09T14:12:46Z

It does not seem there is an interest to reduce the complexity of embellished operators so I removed the label. Let's see what happens when we try to upstream the embellished operator support...

In [1], basic logic was added to prepare support for embellished operators [2]. For example in a LaTeX expression like $u +_V v$, which may be represented in MathML as <math> <mi>u</mi> <msub><mo>+</mo><mi>V</mi></msub> <mi>v</mi> </math> the spacing around the operators should be put around the whole embellished operator "+ subscript V". Similar behavior is expected for other operator properties. In [1], only <mo> elements were considered embellished operators. This CL extends it to the full definition from MathML Core but considering only <mtext> and <mspace> as space-like for now [3]. Together, these two CLs add special handling of properties lspace, rspace and movablelimits with embellished operators. Supporting other operator properties (e.g. stretchy) and refining the definition of space-like will happen in follow-up CLs. MathML Core's definition is based on MathML 3 and is still relatively complex. Determining whether an element is an embellished operator and retrieving the property of the core operator has bad worst-case complexity but it should be fine in practice [4]. An alternative would be to cache these properties somewhere in our trees for fast access but it does not seem worth adding that extra complexity for existing use cases. Finally, now that mrow-like elements can be embellished operators, this CL refines the row layout algorithm so that spacing is added around operator children only if the element being laid out is the <math> root or is not itself an embellished operator [5]. This basically addresses the use case of expressions like <math> <mi>u</mi> <mrow><mo>+</mo></mrow> <mi>v</mi> </math> where the operator spacing should be added during the layout of the <math> element, not during the one of the <mrow> element. [1] https://chromium-review.googlesource.com/c/chromium/src/+/3059616 [2] https://w3c.github.io/mathml-core/#embellished-operators [3] https://w3c.github.io/mathml-core/#dfn-space-like [4] w3c/mathml#115 [5] https://w3c.github.io/mathml-core/#layout-of-mrow Bug: 6606, 1124298 Change-Id: I30214e6fadfe4f7deb35b1ebffbc40dbe5023e95

In [1], basic logic was added to prepare support for embellished operators [2]. For example in a LaTeX expression like $u +_V v$, which may be represented in MathML as <math> <mi>u</mi> <msub><mo>+</mo><mi>V</mi></msub> <mi>v</mi> </math> the spacing around the operators should be put around the whole embellished operator "+ subscript V". Similar behavior is expected for other operator properties. In [1], only <mo> elements were considered embellished operators. This CL extends it to the full definition from MathML Core but considering only <mtext> and <mspace> as space-like for now [3]. Together, these two CLs add special handling of properties lspace, rspace and movablelimits with embellished operators. Supporting other operator properties (e.g. stretchy) and refining the definition of space-like will happen in follow-up CLs. MathML Core's definition is based on MathML 3 and is still relatively complex. Determining whether an element is an embellished operator and retrieving the property of the core operator has bad worst-case complexity but it should be fine in practice [4]. An alternative would be to cache these properties somewhere in our trees for fast access but it does not seem worth adding that extra complexity for existing use cases. Finally, now that mrow-like elements can be embellished operators, this CL refines the row layout algorithm so that spacing is added around operator children only if the element being laid out is the <math> root or is not itself an embellished operator [5]. This basically addresses the use case of expressions like <math> <mi>u</mi> <mrow><mo>+</mo></mrow> <mi>v</mi> </math> where the operator spacing should be added during the layout of the <math> element, not during the one of the <mrow> element. This CL improves pass rate for existing WPT tests checking embellished operator support. Testing is essentially based on lspace/rspace spacing around embellished operators, as calculated by DetermineOperatorSpacing. mo-movablelimits-and-embellished-operator.html is added to verify the case of IsUnderOverLaidOutAsSubSup. This covers the combination of the change here and in [1]. [1] https://chromium-review.googlesource.com/c/chromium/src/+/3059616 [2] https://w3c.github.io/mathml-core/#embellished-operators [3] https://w3c.github.io/mathml-core/#dfn-space-like [4] w3c/mathml#115 [5] https://w3c.github.io/mathml-core/#layout-of-mrow Bug: 6606, 1124298 Change-Id: I30214e6fadfe4f7deb35b1ebffbc40dbe5023e95

In [1], basic logic was added to prepare support for embellished operators [2]. For example in a LaTeX expression like $u +_V v$, which may be represented in MathML as <math> <mi>u</mi> <msub><mo>+</mo><mi>V</mi></msub> <mi>v</mi> </math> the spacing around the operators should be put around the whole embellished operator "+ subscript V". Similar behavior is expected for other operator properties. In [1], only <mo> elements were considered embellished operators. This CL extends it to the full definition from MathML Core but considering only <mtext> and <mspace> as space-like for now [3]. Together, these two CLs add special handling of properties lspace, rspace and movablelimits with embellished operators. Supporting other operator properties (e.g. stretchy) and refining the definition of space-like will happen in follow-up CLs. MathML Core's definition is based on MathML 3 and is still relatively complex. Determining whether an element is an embellished operator and retrieving the property of the core operator has bad worst-case complexity but it should be fine in practice [4]. An alternative would be to cache these properties somewhere in our trees for fast access but it does not seem worth adding that extra complexity for existing use cases. Finally, now that mrow-like elements can be embellished operators, this CL refines the row layout algorithm so that spacing is added around operator children only if the element being laid out is the <math> root or is not itself an embellished operator [5]. This basically addresses the use case of expressions like <math> <mi>u</mi> <mrow><mo>+</mo></mrow> <mi>v</mi> </math> where the operator spacing should be added during the layout of the <math> element, not during the one of the <mrow> element. This CL improves pass rate for existing WPT tests checking embellished operator support. Testing is essentially based on lspace/rspace spacing around embellished operators, as calculated by DetermineOperatorSpacing. mo-movablelimits-and-embellished-operator.html is added to verify the case of IsUnderOverLaidOutAsSubSup. This covers the combination of the change here and in [1]. [1] https://chromium-review.googlesource.com/c/chromium/src/+/3059616 [2] https://w3c.github.io/mathml-core/#embellished-operators [3] https://w3c.github.io/mathml-core/#dfn-space-like [4] w3c/mathml#115 [5] https://w3c.github.io/mathml-core/#layout-of-mrow Bug: 6606, 1124298 Change-Id: I30214e6fadfe4f7deb35b1ebffbc40dbe5023e95 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3059456 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#915472}

…d operators, a=testonly Automatic update from web-platform-tests [mathml] Refine definition of embellished operators In [1], basic logic was added to prepare support for embellished operators [2]. For example in a LaTeX expression like $u +_V v$, which may be represented in MathML as <math> <mi>u</mi> <msub><mo>+</mo><mi>V</mi></msub> <mi>v</mi> </math> the spacing around the operators should be put around the whole embellished operator "+ subscript V". Similar behavior is expected for other operator properties. In [1], only <mo> elements were considered embellished operators. This CL extends it to the full definition from MathML Core but considering only <mtext> and <mspace> as space-like for now [3]. Together, these two CLs add special handling of properties lspace, rspace and movablelimits with embellished operators. Supporting other operator properties (e.g. stretchy) and refining the definition of space-like will happen in follow-up CLs. MathML Core's definition is based on MathML 3 and is still relatively complex. Determining whether an element is an embellished operator and retrieving the property of the core operator has bad worst-case complexity but it should be fine in practice [4]. An alternative would be to cache these properties somewhere in our trees for fast access but it does not seem worth adding that extra complexity for existing use cases. Finally, now that mrow-like elements can be embellished operators, this CL refines the row layout algorithm so that spacing is added around operator children only if the element being laid out is the <math> root or is not itself an embellished operator [5]. This basically addresses the use case of expressions like <math> <mi>u</mi> <mrow><mo>+</mo></mrow> <mi>v</mi> </math> where the operator spacing should be added during the layout of the <math> element, not during the one of the <mrow> element. This CL improves pass rate for existing WPT tests checking embellished operator support. Testing is essentially based on lspace/rspace spacing around embellished operators, as calculated by DetermineOperatorSpacing. mo-movablelimits-and-embellished-operator.html is added to verify the case of IsUnderOverLaidOutAsSubSup. This covers the combination of the change here and in [1]. [1] https://chromium-review.googlesource.com/c/chromium/src/+/3059616 [2] https://w3c.github.io/mathml-core/#embellished-operators [3] https://w3c.github.io/mathml-core/#dfn-space-like [4] w3c/mathml#115 [5] https://w3c.github.io/mathml-core/#layout-of-mrow Bug: 6606, 1124298 Change-Id: I30214e6fadfe4f7deb35b1ebffbc40dbe5023e95 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3059456 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#915472} -- wpt-commits: b26a84e991c88ed62030f9bc247cb10c65c77440 wpt-pr: 29878

In [1], basic logic was added to prepare support for embellished operators [2]. For example in a LaTeX expression like $u +_V v$, which may be represented in MathML as <math> <mi>u</mi> <msub><mo>+</mo><mi>V</mi></msub> <mi>v</mi> </math> the spacing around the operators should be put around the whole embellished operator "+ subscript V". Similar behavior is expected for other operator properties. In [1], only <mo> elements were considered embellished operators. This CL extends it to the full definition from MathML Core but considering only <mtext> and <mspace> as space-like for now [3]. Together, these two CLs add special handling of properties lspace, rspace and movablelimits with embellished operators. Supporting other operator properties (e.g. stretchy) and refining the definition of space-like will happen in follow-up CLs. MathML Core's definition is based on MathML 3 and is still relatively complex. Determining whether an element is an embellished operator and retrieving the property of the core operator has bad worst-case complexity but it should be fine in practice [4]. An alternative would be to cache these properties somewhere in our trees for fast access but it does not seem worth adding that extra complexity for existing use cases. Finally, now that mrow-like elements can be embellished operators, this CL refines the row layout algorithm so that spacing is added around operator children only if the element being laid out is the <math> root or is not itself an embellished operator [5]. This basically addresses the use case of expressions like <math> <mi>u</mi> <mrow><mo>+</mo></mrow> <mi>v</mi> </math> where the operator spacing should be added during the layout of the <math> element, not during the one of the <mrow> element. This CL improves pass rate for existing WPT tests checking embellished operator support. Testing is essentially based on lspace/rspace spacing around embellished operators, as calculated by DetermineOperatorSpacing. mo-movablelimits-and-embellished-operator.html is added to verify the case of IsUnderOverLaidOutAsSubSup. This covers the combination of the change here and in [1]. [1] https://chromium-review.googlesource.com/c/chromium/src/+/3059616 [2] https://w3c.github.io/mathml-core/#embellished-operators [3] https://w3c.github.io/mathml-core/#dfn-space-like [4] w3c/mathml#115 [5] https://w3c.github.io/mathml-core/#layout-of-mrow Bug: 6606, 1124298 Change-Id: I30214e6fadfe4f7deb35b1ebffbc40dbe5023e95 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3059456 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/main@{#915472} NOKEYCHECK=True GitOrigin-RevId: f7df6b5ef650e99c87c55fbd9651c2d501b9b587

fred-wang added MathML Core Issues affecting the MathML Core specification MathML 4 Issues affecting the MathML 4 specification need resolution Issues needing resolution at MathML Refresh CG meeting labels Sep 16, 2019

fred-wang closed this as completed in w3c/mathml-core@de02d14 May 9, 2020

fred-wang removed the need resolution Issues needing resolution at MathML Refresh CG meeting label May 9, 2020

chromium-wpt-export-bot mentioned this issue Aug 3, 2021

[mathml] Refine definition of embellished operators web-platform-tests/wpt#29878

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplify embellished operator? #115

Simplify embellished operator? #115

fred-wang commented Jul 5, 2019

NSoiffer commented Jul 5, 2019

fred-wang commented Jul 7, 2019

fred-wang commented Aug 6, 2019

fred-wang commented May 9, 2020

Simplify embellished operator? #115

Simplify embellished operator? #115

Comments

fred-wang commented Jul 5, 2019

NSoiffer commented Jul 5, 2019

fred-wang commented Jul 7, 2019

fred-wang commented Aug 6, 2019

fred-wang commented May 9, 2020