From [1]:
> Place the mmultiscripts base and <mprescripts> boxes at inline offsets
inline-offset and with their alphabetic baselines aligned with the
alphabetic baseline.
Also tweak subsup-6.html to compute bounding box of the <mprescripts>
element at the time a test is run. Otherwise reflow due to resize of the
`<div id="log">` element can make the test fail.
[1] https://w3c.github.io/mathml-core/#base-with-prescripts-and-postscripts
Differential Revision: https://phabricator.services.mozilla.com/D222614
This patch implements support for the width/height properties on
MathML elements [1]. The general algorithm from the spec is as
follows:
(1) The outcome of the math layout is a "math content box".
(2) The content box sets its size from computed width/height values. If
auto, it's the one of the "math content box". This patch ignores
percentage values for now [2] [3].
(3) math content box is shifted so that its inline-start and top edges
aligns with the ones of the content box. There are exceptions
elements like mfrac and munder/mover/munderover which instead
horizontally center the math content box within the content box.
For baseline adjustment, we follow what Chromium does, see [4].
(4) Padding+border are added around the content box. Note that we
ignore the box-sizing property for now [5].
The patch essentially tweaks the various MathML layout algorithms to
perform steps (3) and (4) before the calls to
GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics.
[1] https://w3c.github.io/mathml-core/#layout-algorithms
[2] https://github.com/w3c/mathml-core/issues/76
[3] https://github.com/w3c/mathml-core/issues/77
[4] https://github.com/w3c/mathml-core/issues/259
[5] https://github.com/w3c/mathml-core/issues/257
Below is more information about test coverage:
- width-height-001: Verify that width, height, inline-size and block-size
properties sets the size of the content box. This test used to verify
they are ignored, this patch fixes the `<meta name="assert">` tag.
It also adds a test for the case the specified size is smaller than the
content (we force non empty descendants to make sure this content is
large enough) and to verify the width is used for the preferred width.
- width-height-002, width-height-003: These are reftests visually checking
offsets of the math content box within a larger content box (specified
by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot,
in LTR/RTL modes. In particular they allow to verify some painted
elements like fraction bar and radical symbols.
- width-height-004: This test more directly checks that the math content
box is horizontally centered within a larger content box for munder,
mover, munderover and mfrac. This patch extends the test to cover the
case when the math content box is wider (i.e. overflowing outside the
content box) and removes unnecessary specified height.
- width-height-005: New test for other layout algorithm that don't
center the math content box, checking inline-start edges of children
when a width is specified. We check both LTR/RTL modes and
wider/narrower content boxes.
- width-height-006: Same but checking the top edges for larger/smaller
height and verifying that baseline is perserved.
Differential Revision: https://phabricator.services.mozilla.com/D221436
Currently, we have
```
aDesiredSize.Height() = aDesiredSize.BlockStartAscent() +
sizeDen.Height() + denMargin.bottom - sizeDen.BlockStartAscent() +
denShift;
```
Then a call to `InflateReflowAndBoundingMetrics` respectively increments
`aDesiredSize.BlockStartAscent()` and `aDesiredSize.Height()` by
`borderPadding.top` and `borderPadding.top + borderPadding.bottom`.
Finally, we set
```
dy = aDesiredSize.Height() - sizeDen.Height() - denMargin.bottom -
borderPadding.bottom;
```
which is equivalent to
```
aDesiredSize.BlockStartAscent() + denShift - sizeDen.BlockStartAscent()
```
Differential Revision: https://phabricator.services.mozilla.com/D222456
This class is currently only used to override InheritAutomaticData() and
IsMrowLike(). This patch moves that directly in nsMathMLrootFrame.
Probably we should have the same behavior when ShouldUseRowFallback()
returns true, but this patch does not try and change anything.
Differential Revision: https://phabricator.services.mozilla.com/D222258
Currently, nsMathMLContainerFrame::AttributeChanged always force a
reflow. This patch removes that behavior tweaks the following derived
classes:
- menclose: Don't mark intrinsic size of descendants dirty, since the
notation is added around the children, only affecting the element's
metrics.
- mfrac: Don't mark intrinsic size dirty for the linethickness
attribute, since it only affects vertical metrics.
- mo: Rebuild 'automatic' data and relayout the entire embellished
operator hierarchy for all operator properties. I haven't checked the
details of the MathML 'automatic' data, so it may be a bit too
aggressive. But at least a reflow is necessary.
- mspace/mpadded: Only mark intrinsic size dirty for the element and
ancestors, and only for attributes affecting vertical metrics. Also
remove `InvalidateFrame()` call since we don't have any display item.
- mtable: Don't force reflow or data rebuild when displaystyle changes.
This was probably needed before displaystyle was re-implemented as
an attribute mapped to the math-style CSS property.
There is at least one dynamic test for each of the MathML
attributes affecting layout and they don't regress after this patch:
https://bugzilla.mozilla.org/show_bug.cgi?id=1918308#c0
Differential Revision: https://phabricator.services.mozilla.com/D221925
This method is now only used at one place (more precisely, inside the
nsMathMLContainerFrame::GetIntrinsicISizeMetrics() method) and only
calls the Place() method with the IntrinsicSize + MeasureOnly flags.
This patch removes it and instead ensure we call Place() directly from
GetIntrinsicISizeMetrics(). There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221630
This patch reimplements layout of the mroot element by overridding the
Place() method, which is used by nsMathMLContainerFrame for the
implementation of Reflow and MeasureForWidth. These two latter methods
then don't need to be overridden anymore in nsMathMLmrootFrame.
Differential Revision: https://phabricator.services.mozilla.com/D221629
The only reasons why we override MeasureForWidth and Reflow in
nsMathMLmspaceFrame is to make sure attribute parsing is performed.
This patch just uses the implementation of nsMathMLContainerFrame
instead, by moving attribute processing into a new
nsMathMLmspaceFrame::Place method instead, adding proper caching &
invalidation to make it optimal.
Differential Revision: https://phabricator.services.mozilla.com/D221623
The only reasons why we override MeasureForWidth and Reflow in
nsMathMLmpaddedFrame is to make sure attribute parsing is performed.
This patch just uses the implementation of nsMathMLContainerFrame
instead, by lazily parsing the attributes in nsMathMLmpaddedFrame::Place
and adding proper caching & invalidation to make it optimal.
Differential Revision: https://phabricator.services.mozilla.com/D221613
nsMathMLmpaddedFrame parses each of its width, height, depth, lspace and
voffset attribute into three members: a nsCSSValue and int32_t values
representing enumerated values for optional signs and pseudo-units. This
commit rewrites them as a struct containing a nsCSSValue and two uint8_t
enum classes. One value for the sign that was used to indicate that
the attribute is absent or invalid is moved into a separate mIsValid
boolean. There are no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221612
This patch tweaks implementation of AttributeChanged() in MathML layout
classes to be more consistent:
1. Only handle MathML-specific attributes in the default namespace.
2. Return immediately for class attributes, or forward the call to
the parent class (or grandparent class).
Currently, nsMathMLContainerFrame::AttributeChanged() always forces a
reflow but this change does not cause new calls to it, except for the
edge case of accent/accentunder attributes in the non-default namespace
(nsMathMLmunderoverFrame). Not doing more for
nsMathMLmencloseFrame/nsMathMLmfracFrame breaks some tests, but we can
probably do a weaker invalidation. See bug 1918308 for a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D221921
These are private methods so that are called by the overridden methods
Place() (without flags) and by MeasureForWidth() (with IntrinsicSize +
MeasureOnly flags). But the former can just be implemented directly and
then the latter does not need to override what nsMathMLContainerFrame
does already. There are no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221611
This method is now only used at one place (more precisely, inside the
nsMathMLContainerFrame::GetIntrinsicISizeMetrics() method) and only
calls the Place() method with the IntrinsicSize + MeasureOnly flags.
This patch removes it and instead ensure we call Place() directly from
GetIntrinsicISizeMetrics(). There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221630
This patch reimplements layout of the mroot element by overridding the
Place() method, which is used by nsMathMLContainerFrame for the
implementation of Reflow and MeasureForWidth. These two latter methods
then don't need to be overridden anymore in nsMathMLmrootFrame.
Differential Revision: https://phabricator.services.mozilla.com/D221629
The only reasons why we override MeasureForWidth and Reflow in
nsMathMLmspaceFrame is to make sure attribute parsing is performed.
This patch just uses the implementation of nsMathMLContainerFrame
instead, by moving attribute processing into a new
nsMathMLmspaceFrame::Place method instead, adding proper caching &
invalidation to make it optimal.
Differential Revision: https://phabricator.services.mozilla.com/D221623
The only reasons why we override MeasureForWidth and Reflow in
nsMathMLmpaddedFrame is to make sure attribute parsing is performed.
This patch just uses the implementation of nsMathMLContainerFrame
instead, by lazily parsing the attributes in nsMathMLmpaddedFrame::Place
and adding proper caching & invalidation to make it optimal.
Differential Revision: https://phabricator.services.mozilla.com/D221613
nsMathMLmpaddedFrame parses each of its width, height, depth, lspace and
voffset attribute into three members: a nsCSSValue and int32_t values
representing enumerated values for optional signs and pseudo-units. This
commit rewrites them as a struct containing a nsCSSValue and two uint8_t
enum classes. One value for the sign that was used to indicate that
the attribute is absent or invalid is moved into a separate mIsValid
boolean. There are no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221612
This patch tweaks implementation of AttributeChanged() in MathML layout
classes to be more consistent:
1. Only handle MathML-specific attributes in the default namespace.
2. Return immediately for class attributes, or forward the call to
the parent class (or grandparent class).
Currently, nsMathMLContainerFrame::AttributeChanged() always forces a
reflow but this change does not cause new calls to it, except for the
edge case of accent/accentunder attributes in the non-default namespace
(nsMathMLmunderoverFrame). Not doing more for
nsMathMLmencloseFrame/nsMathMLmfracFrame breaks some tests, but we can
probably do a weaker invalidation. See bug 1918308 for a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D221921
These are private methods so that are called by the overridden methods
Place() (without flags) and by MeasureForWidth() (with IntrinsicSize +
MeasureOnly flags). But the former can just be implemented directly and
then the latter does not need to override what nsMathMLContainerFrame
does already. There are no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221611
After bug 1890531, mathml.centered_operator is disabled and
U+002D HYPHEN-MINUS in <mo> no longer renders as U+2212 MINUS SIGN.
This patches restore this behavior as the change was unintentional, even
though this is not specified in MathML Core.
Differential Revision: https://phabricator.services.mozilla.com/D219085
After bug 1890531, mathml.centered_operator is disabled and
U+002D HYPHEN-MINUS in <mo> no longer renders as U+2212 MINUS SIGN.
This patches restore this behavior as the change was unintentional, even
though this is not specified in MathML Core.
Differential Revision: https://phabricator.services.mozilla.com/D219085
After bug 1890531, mathml.centered_operator is disabled and
U+002D HYPHEN-MINUS in <mo> no longer renders as U+2212 MINUS SIGN.
This patches restore this behavior as the change was unintentional, even
though this is not specified in MathML Core.
Differential Revision: https://phabricator.services.mozilla.com/D219085
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This commit ensures MathML boolean attributes (namely displaystyle,
mo@stretchy, mo@symmetric, mo@largeop, mo@movablelimits,
munder@accentunder, mover@accent, munderover@accent,
munderover@accentunder) are ASCII case-insensitive [1]. For
displaystyle that was handled in [2]. For mover/munder/munderover
attributes, this is covered by a test case from scriptlevel-001.html
checking both case-insensitivity and dynamic changes at the same time ;
the latter still seems broken, so these checks are moved into separate
test cases. For mo attributes, a new WPT test is added. Note that
mo@accent, mo@fence, mo@separator are not part of MathML Core (with the
two last without visual effect), we make them case-insensitive for
consistency but don't bother adding tests for them.
[1] https://w3c.github.io/mathml-core/#dfn-boolean used here:
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1574087
Differential Revision: https://phabricator.services.mozilla.com/D218944
After bug 1890531, mathml.centered_operator is disabled and
U+002D HYPHEN-MINUS in <mo> no longer renders as U+2212 MINUS SIGN.
This patches restore this behavior as the change was unintentional, even
though this is not specified in MathML Core.
Differential Revision: https://phabricator.services.mozilla.com/D219085
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This is the first patch of the series that actually take
border/padding/margin into account for MathML layout. One subtility is
that Gecko distinguishes the ink nsBoundingMetrics box and the
ReflowOutput box for accurate positioning of math components contrary
to the current version of MathML Core [1].
For MathML Core and the WPT tests, it is assumed that border/padding are
used to inflate the content box [2] [3] and it does not really matter
whether we inflate the ink bounding box, or simply adjust its offsets
inside the normal bounding box. We choose the former and introduce a
helper function InflateReflowAndBoundingMetrics for that purpose, which
will be reused in follow-up patches. After inflating these boxes, the
offsets of children and painted items must also be adjusted by the
left/top border+padding.
Regarding margins, MathML Core says that we should use "margin boxes"
and WPT tests simply check that the layout of MathML constructions
containing mspace elements with margins is not changed if we move
these margins inside the mspace's width/height/depth attributes. To
pass these tests, we similarly need to inflate both the ink and
non-ink bounding boxes by the margin.
However, the margins can be negative possibly leading to negative
dimensions of "margin boxes". To make the code more generic, we
simplify adjust all usages of the children's nsBoundingMetrics and
ReflowOutput to include these margins. When calling FinishReflowChild
at the end, the offsets of children must be adjusted by these margins.
This patch also reimplements the extra one-pixel padding around a
fraction using rules from MathML Core's UA stylesheet at
https://w3c.github.io/mathml-core/#user-agent-stylesheet
[1] https://github.com/w3c/mathml-core/issues/78
[2] 27c8d234ee/mathml/relations/css-styling/padding-border-margin/border-002.html (L25)
[4] 27c8d234ee/mathml/relations/css-styling/padding-border-margin/padding-002.html (L26)
[3] 27c8d234ee/mathml/relations/css-styling/padding-border-margin/margin-003.html (L50)
Differential Revision: https://phabricator.services.mozilla.com/D216670
MathML classes has a few Place*() methods used for layout and intrinsic
size calculation. These methods have a parameter "aPlaceOrigin"
indicating whether the children and other painted objects should have
their final positions set, or if the method is only called for measuring.
This parameter is typically set to false when doing intrinsic size
calculation or when performing some non-final measurement for operator
stretching.
For intrinsic size calculation, it is generally enough to perform
placement with aPlaceOrigin=false and ignoring the vertical metrics.
Some Place*() methods also have a parameter "aWidthOnly" for special
handling. For example, msqrt stretches a radical symbol vertically to
match the height of the content but when doing intrinsic size
calculation this is approximated to nsMathMLChar::GetMaxWidth() instead.
When we implement border/padding/margin we should also be able to
choose between using IntrinsicISizeOffsets() or GetUsed*() methods.
Finally, some Place*() methods initially call a place routing of a
parent class before further tweaking the layout. For example, msqrt
uses mrow layout on children and adds some radical symbol on top of
them. When we implement border/padding, we should make sure we don't
add the border/padding before the final result.
In order to handle all these placement behaviors, a new EnumSet is
introduced. This commit does not change behavior. Handling of padding,
border and margin will be handled in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D216669
This is the first patch of the series that actually take
border/padding/margin into account for MathML layout. One subtility is
that Gecko distinguishes the ink nsBoundingMetrics box and the
ReflowOutput box for accurate positioning of math components contrary
to the current version of MathML Core [1].
For MathML Core and the WPT tests, it is assumed that border/padding are
used to inflate the content box [2] [3] and it does not really matter
whether we inflate the ink bounding box, or simply adjust its offsets
inside the normal bounding box. We choose the former and introduce a
helper function InflateReflowAndBoundingMetrics for that purpose, which
will be reused in follow-up patches. After inflating these boxes, the
offsets of children and painted items must also be adjusted by the
left/top border+padding.
Regarding margins, MathML Core says that we should use "margin boxes"
and WPT tests simply check that the layout of MathML constructions
containing mspace elements with margins is not changed if we move
these margins inside the mspace's width/height/depth attributes. To
pass these tests, we similarly need to inflate both the ink and
non-ink bounding boxes by the margin.
However, the margins can be negative possibly leading to negative
dimensions of "margin boxes". To make the code more generic, we
simplify adjust all usages of the children's nsBoundingMetrics and
ReflowOutput to include these margins. When calling FinishReflowChild
at the end, the offsets of children must be adjusted by these margins.
This patch also reimplements the extra one-pixel padding around a
fraction using rules from MathML Core's UA stylesheet at
https://w3c.github.io/mathml-core/#user-agent-stylesheet
[1] https://github.com/w3c/mathml-core/issues/78
[2] 27c8d234ee/mathml/relations/css-styling/padding-border-margin/border-002.html (L25)
[4] 27c8d234ee/mathml/relations/css-styling/padding-border-margin/padding-002.html (L26)
[3] 27c8d234ee/mathml/relations/css-styling/padding-border-margin/margin-003.html (L50)
Differential Revision: https://phabricator.services.mozilla.com/D216670
MathML classes has a few Place*() methods used for layout and intrinsic
size calculation. These methods have a parameter "aPlaceOrigin"
indicating whether the children and other painted objects should have
their final positions set, or if the method is only called for measuring.
This parameter is typically set to false when doing intrinsic size
calculation or when performing some non-final measurement for operator
stretching.
For intrinsic size calculation, it is generally enough to perform
placement with aPlaceOrigin=false and ignoring the vertical metrics.
Some Place*() methods also have a parameter "aWidthOnly" for special
handling. For example, msqrt stretches a radical symbol vertically to
match the height of the content but when doing intrinsic size
calculation this is approximated to nsMathMLChar::GetMaxWidth() instead.
When we implement border/padding/margin we should also be able to
choose between using IntrinsicISizeOffsets() or GetUsed*() methods.
Finally, some Place*() methods initially call a place routing of a
parent class before further tweaking the layout. For example, msqrt
uses mrow layout on children and adds some radical symbol on top of
them. When we implement border/padding, we should make sure we don't
add the border/padding before the final result.
In order to handle all these placement behaviors, a new EnumSet is
introduced. This commit does not change behavior. Handling of padding,
border and margin will be handled in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D216669
