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•1 year ago
|
||
| Assignee | ||
Comment 2•1 year 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•1 year ago
|
||
| Assignee | ||
Comment 4•1 year 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•1 year 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•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 9•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/47fb7922be7f
https://hg.mozilla.org/mozilla-central/rev/dc8483828112
Description
•