How is inline stretch size constraint determined? #270
Comments
|
It's set in this algorithm. If you click the bold text, you see it's called from munder, mover and munderover. To make things work with embellished operators, the "inline stretch size constraint" can be passed recursively to the child containing the core operator. The part about mtd from MathML3 is currently not supported in MathML Core. In general mtable support is very limited in level 1 (issue #125). As a rough sketch, we would probably need to change the table algo to first do a layout without inline stretch size constraint, and then a second layout passing a maximum of inline size of the content in the same column. Similarly for stretching in the block direction. Obviously, there are probably a lot of details and egde cases to think about... Issue #138 is about exposing this to polyfills relying on the CSS layout API. |
|
Ah, thanks for the clarification. So, that algorithm is part of the description of munder, which is helpful once you've realized that horizontal stretch is only happening there :> Perhaps it would be good to link there from the But perhaps I should be surprised there either, since I suppose that never has worked. But should it? |
|
What do you mean for mpadded? The example you mentioned shouldn't stretch by itself. If you are saying that, as an embellished operator, it should stretch when placed in an munderover-like construct, then the answer is yes. However, I just checked and that does not work in Chromium: Probably, https://w3c.github.io/mathml-core/#layout-of-mpadded should say that the anonymous mrow box is laid out using the same inline/block stretch constraint and Chromium does not do that. |
|
I just editted the previous example to wrap with |
How is the
inline stretch size constraint(ie. the target width for a horizontally stretchy operator) determined? At https://w3c.github.io/mathml-core/#dfn-inline-stretch-size-constraint, we say "During box layout, optional inline stretch size constraint and block stretch size constraint parameters may be used on embellished operators.". However, I can not find where it says how this parameter is determined, or if (& how) we can affect it. (There is an open issue #64 that suggestsminsize/maxsizemight be applicable, but resolution has been deferred).In experiments, I can only see horizontal stretch happening within
mover(& friends), but not inmpaddedormtable, for example.The target application is commutative diagrams, which will appear within an
mtable. It would be acceptable to specify an explicit length for the arrows, if they could stretch at all; but it seems perverse to wrap arrows with an extramoverand empty (but wide!) script just to get the arrow length.The text was updated successfully, but these errors were encountered: