Support CSS width/height properties on MathML elements
Categories
(Core :: MathML, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox133 | --- | fixed |
People
(Reporter: fredw, Assigned: fredw)
References
(Blocks 1 open bug)
Details
Attachments
(5 files)
The generic thing is described here: https://w3c.github.io/mathml-core/#layout-algorithms
By default, the box metrics, offsets, baselines, italic correction and top accent attachment of the content box are set to the one calculated for the math content box. However if a different size is specified for the content box (via width, height or related properties), that size is used instead and the inline-start and block-start edges of the math content box are aligned with the ones of the content box, unless otherwise specified in a specific layout algorithm.
Some elements like mfrac specifies a different placement:
The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position.
I'm not sure if the current text of MathML Core defines resolution of percentages, there seem to https://github.com/w3c/mathml-core/issues/76 and https://github.com/w3c/mathml-core/issues/77 about that with the consensus to use the size of a block container. But maybe we can just treat them as auto for now (maybe what chrome does too?).
Some tests are available here:
The spec does not mention box-sizing
and always say width/height applies to the content box. I opened https://github.com/w3c/mathml-core/issues/257
Assignee | ||
Comment 1•7 months ago
|
||
Assignee | ||
Comment 2•7 months ago
|
||
It seems we should just be able to get the values from StylePosition. With the attached patch and testcase I get something like this:
mfrac=0x750611046c70, measureonly=1
width: auto
height: auto
mfrac=0x750611046c70, measureonly=0
width: auto
height: auto
mfrac=0x750611047180, measureonly=0
width: 9000
height: 6000
mfrac=0x750611047690, measureonly=0
width: 1,000000
height: 0,500000
Assignee | ||
Comment 3•6 months ago
|
||
Assignee | ||
Comment 4•6 months ago
|
||
(In reply to Frédéric Wang (:fredw) from comment #0)
Some tests are available here:
The latest version of the patch pass all these tests, but I believe test coverage is not sufficient.
Assignee | ||
Comment 5•6 months ago
|
||
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()
Assignee | ||
Comment 6•6 months ago
|
||
Updated•6 months ago
|
Updated•6 months ago
|
Comment 9•6 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/47fb7922be7f
https://hg.mozilla.org/mozilla-central/rev/dc8483828112
Description
•