Closed Bug 1723750 Opened 3 years ago Closed 3 years ago

[wpt-sync] Sync PR 29878 - [mathml] Refine definition of embellished operators

Categories

(Core :: MathML, task, P4)

task

Tracking

()

RESOLVED FIXED
93 Branch
Tracking Status
firefox93 --- fixed

People

(Reporter: mozilla.org, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 29878 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/29878
Details from upstream follow.

b'Fr\xc3\xa9d\xc3\xa9ric Wang <fwang@igalia.com>' wrote:

[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.

[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] https://github.com/w3c/mathml/issues/115
[5] https://w3c.github.io/mathml-core/#layout-of-mrow

Bug: 6606, 1124298
Change-Id: I30214e6fadfe4f7deb35b1ebffbc40dbe5023e95

Reviewed-on: https://chromium-review.googlesource.com/3059456
WPT-Export-Revision: f5718290e8a63edf4d6918f3a3a5176328035383

Component: web-platform-tests → MathML
Product: Testing → Core

CI Results

Ran 0 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 3 tests and 4 subtests

Status Summary

Firefox

OK : 1
PASS: 4
FAIL: 2

Chrome

OK : 1
PASS: 3
FAIL: 3

Safari

OK : 1
PASS: 3
FAIL: 3

Links

GitHub PR Head
GitHub PR Base

Details

New Tests That Don't Pass

/mathml/presentation-markup/operators/embellished-operator-dynamic-002.html
container1: Initially an embellished operator: FAIL (Chrome: FAIL, Safari: FAIL)
container2: Became an embellished operator: FAIL (Chrome: FAIL, Safari: FAIL)

Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ca7db0eb2618
[wpt PR 29878] - [mathml] Refine definition of embellished operators, a=testonly
https://hg.mozilla.org/integration/autoland/rev/e940b705a34c
[wpt PR 29878] - Update wpt metadata, a=testonly
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
You need to log in before you can comment on or make changes to this bug.