Define if width/height/inline-size/block-size are supported.

[bfgeek]

A simple test case:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6693

Safari appears to support height at least on the element, however firefox appears not to?

From an implementation POV it may be easier just to support all width/height/etc on all elements, however this gets into how to define the internal MathML algorithms.

On the element this needs tests for various values of width/height, and within various formatting contexts, e.g. flex (does it respect flex-basis properly), grid, etc.

[bfgeek]

Oh this is more fun as it appears to selectively apply to certain elements, e.g.
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6706

[fred-wang]

I think we are now ready to handle this, so I'll put this on the agenda of the nxt MathML CG meeting.

Currently, each MathML box layout its content without linebreaking. The content box is defined to be the one of generated by the content:
https://mathml-refresh.github.io/mathml-core/#layout-algorithms

If width/height/inline-size/block-size are useful, a simple interpretation for now would be to set the content box to the specified size and let the content overflow.

[rwlbuis]

Supporting width/height properties in MathML could potentially make things simpler in the implementation since a lot of layout/rendering code expects width/height info.

I am not sure on all the details though. As usual CSS property vs presentation attribute has to be defined, i.e. which one wins ultimately. For mspace, width property could override the width attribute, but how do ascent/descent attribute and height property interact? We'll probably have to look per element how much sense it makes.

[fred-wang]

I am not sure on all the details though. As usual CSS property vs presentation attribute has to be defined, i.e. which one wins ultimately. For mspace, width property could override the width attribute, but how do ascent/descent attribute and height property interact? We'll probably have to look per element how much sense it makes.

With my generic proposal for MathML, <mspace width="100px" height="50px" depth="50px" style="width: 50px; height: 200px;"> would still create a 100px square (MathML content) but the content box would have size 50px X 200px so the mspace will have visible overflow on the inline axis and be aligned along the line-over edge (or follows any consistent block alignment rule).

[rwlbuis]

For mspace, width property could override the width attribute, but how do ascent/descent attribute and height property interact?

Oops, I meant height/depth here instead of ascent/descent.

[fred-wang]

To be clear, we have a general layout algorithm described here:

https://mathml-refresh.github.io/mathml-core/#layout-algorithms

So we have:

• The box obtained when content is laid out, described in other individual sections. Let's call it the "math box" for convenience.
• The CSS content box which is currently defined to be the same as the "math box".
• The CSS padding/border/margin boxes which are described in this section from the CSS content box.

My generic proposal is to interpret width/height as follows for most MathML elements:
(1) Percent width/height are interpreted relative to the "math box" dimensions.
(2) The content box takes the width/height specified by CSS (A).
(3) The inline-start edge of the "math box" is aligned with the inline-start edge of the content box. The line-over edge of the "math box" is aligned with the line-over edge of the content box. (B)
(4) If the specified width (respectively height) is smaller than the one of the "max box" then the "math box" will overflow (C).

(A) Assuming we ignore box-sizing for now. Small adjustment will be needed if we support the border-box value.
(B) Assuming we ignore alignment properties for now.
(C) Assuming we ignore overflow for now. For other other values than "overflow", we might need to introduce anonymous block container or something.

As Neil noted, for the <math> root it makes sense to keep the CSS interpretation of width/height for display: block and inline.

We might also want to consider width/height for the actual layout of the "math box". For example an mrow might take into account the width to perform some line breaking, an mfrac can pass the width constraint to the numerator/denominator or an mspace/mpadded element can have special interpretation according to its attribute. But indeed this special cases would need more analysis than my general proposal, so maybe that should be defined later.

Finally, there is the option of just ignoring width/height on MathML elements.

[fred-wang]

Consensus during mathml core meeting: Ignore width/height on all new layout as they are no clear use case and that simplifies implementation. It still makes sense for mtable or math elements.

[fred-wang]

The spec now says that it is ignored for elements with "display: math"

[rwlbuis]

Ian would like to reconsider this:
https://chromium-review.googlesource.com/c/chromium/src/+/1913250/8/third_party/blink/renderer/core/layout/ng/mathml/ng_math_row_layout_algorithm.cc#14

Test:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7503

[rwlbuis]

After playing a bit with above live-dom-viewer link, I have these findings:

• I was not able to create a scrollbar due to overflow in FF or Safari implementations.
• Implementations seem to behave differently to width/height on outer , FF needs a position:absolute before it uses width/height values, whereas in Safari the width is the same, but height is always used (independent of position:absolute).
• for FF does not seem to ignore width/height, whereas Safari again only considers height.

[bfgeek]

The situation is somewhat more complex than above, e.g. consider this example:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7530

Here both implementations respect the width&height properties, if the outer display is flex.
And both implementations here will trigger scroll:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7531

(this also occurs when the outer div has display: grid etc.)
There are other subtle interactions to consider, e.g. what the flex-basis is when stretching, etc.

It is probably an order of magnitude more work to ignore the width/height properties correctly, than to consistently apply them.
Ian

[rwlbuis]

In the 7530 and 7531 examples mi stops being a MathML element AFAIK, so it may as well have been a div or something. To me it may be more interesting to know what the MathML behavior has been up until now. Hopefully we can discuss this issue tonight during the Core MathML meeting.

I guess what you are saying is that if we want to make MathML behave like grid and flexbox, we will see similar behavior on 7530 and 7531, and hence scrollbars?

Are you in favor of width/height support on MathML containers only, or just every MathML element?

[bfgeek]

Just every MathML element would be more straight forward.

It also looks like due to implementations relying on the table impls, width/height are also respected on etc, currently.

[rwlbuis]

If we support width/height, min/max-width and min/max-height logically follow from that?

I have been reading up on MathML3, and it seems it has a concept of max-width/width for <math< element, just through a non standard attribute rather than properties. I guess we already agreed to drop most of those old attributes though.

[bfgeek]

If we support width/height, min/max-width and min/max-height logically follow from that?

Yeah that's right.

If we also get the attr() function in css we can map these directly to these properties. E.g.
mspace {
width: attr(width);
height: attr(height);
}

[rwlbuis]

If we support width/height, min/max-width and min/max-height logically follow from that?

Yeah that's right.

Good to know :)

If we also get the attr() function in css we can map these directly to these properties. E.g.
mspace {
width: attr(width);
height: attr(height);
}

mspace is a bit different regarding the height:
https://mathml-refresh.github.io/mathml-core/#space-mspace

It does have width/height attributes but adds a depth attribute for the descent, so this adds to the block height.I think MathML people will keep expecting the height+depth combo, so I don't think we can change the spec. I do wonder though, could we use CSS calc?

[bfgeek]

Yeah I believe that:

mspace {
  height: calc(attr(height) + attr(depth));
}

should work?

[rwlbuis]

Yeah I believe that:

mspace {
  height: calc(attr(height) + attr(depth));
}

should work?

Quite likely, I can experiment with that. Only remaining special thing about mspace left would then be baseline alignment. I guess we could do some tricks for that too or create a special layout algorithm (as we do right now in our internal branch).

This is just one MathML element, we probably still need to discuss suitability of w/h for the others, I'll try to put it on the agenda for Monday's Core meeting.

[NSoiffer]

It's on the agenda for the 16 Dec meeting.

[rwlbuis]

@bfgeek we will likely go with width/height. I was wondering if you have an opinion on Fred's proposal?:
https://github.com/mathml-refresh/mathml/issues/45#issuecomment-511718819

[rwlbuis]

If we also get the attr() function in css we can map these directly to these properties. E.g.
mspace {
width: attr(width);
height: attr(height);
}

Just learned that this is not supported in Chromium atm:
https://bugs.chromium.org/p/chromium/issues/detail?id=246571

I guess that is what you hinted at with "If we also get the attr() function in css" ?

[fred-wang]

#184 is now ready for review.

@rwlbuis Since you are the one who originally implemented mspace/mpadded in Chrome, can you please the text? Thanks!

Just got approval from rob and no opposition for 2 weeks, so I guess I'll merge this PR and update WPT tests accordingly.

[fred-wang]

This is merged. I'll close this issue when tests are updated.

[fred-wang]

We have minimal test coverage after these PR, so closing:

web-platform-tests/wpt#38361
web-platform-tests/wpt#38443
web-platform-tests/wpt#38466