Handling of out-of-flow elements

[fred-wang]

cc @mrego

I'm not sure there is a concrete use case to e.g. absolutely position a numerator of a fraction. I think Gecko supports it but WebKit does not.

See https://bugs.webkit.org/show_bug.cgi?id=178865

Original report: https://gitlab.com/mathml/MathMLinHTML5/issues/9

[fred-wang]

cc @bfgeek

[fred-wang]

I agree on the suggestion in w3c/mathml#48 (comment)
If one wants to position an out-of-flow element, it's easier to describe its coordinates with respect to the parent.

[fred-wang]

From w3c/mathml#48:

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

Safari & Firefox differ.

Here there are a few sub-questions:

Can MathML elements becomes out-of-flow?
Can MathML elements be containing-blocks for out-of-flow elements?
What this the static-position for OOF elements?

(2) Has some complexities, e.g. if they aren't allowed to be containing-blocks for OOFs, you also need to define that things that implicitly define containing-blocks, e.g. filter() aren't allowed on MathML elements.

My personal preference (subject to change) would probably be to allow OOFs on any element, and allow for any element to be a containing-block.

But this depends on other decisions.

The static-position probably wants to follow flex/grid.

This needs tests with various elements, and various combinations of containing blocks.
In addition there needs to be tests with fixed, etc.e

[tabatkins]

Static position can't meaningfully follow flex/grid, as they have flex/grid-specific definitions that don't generalize to other layouts.

If at all possible, defining staticpos as the start-start corner of the containing block would be ideal, as it just makes life so much simpler.

[NSoiffer]

At the 5/8/19 meeting, we decided to treat out of flow elements as if they aren't part of layout/don't exist for rendering. The error repair mechanism in w3c/mathml#15 will kick in. Hence, if someone uses position:absolute (or display:none or ...) for the first child of an mfrac, then the fraction will render as if it only has one child (i.e., the denominator). Hence, the denominator will appear in the numerator position and the denominator will be error-corrected into an empty mrow.

Note: if someone want to prevent the denominator from shifting up, then they can add an mrow around the out of flow numerator and so there will still be two children to the fraction.

The meeting did not discuss the containing block part of the issue.

[tabatkins]

The behavior you're describing is 👍, exactly what you'd expect from a rendering model.

[fred-wang]

Proposal:

1. All MathML elements can be containing blocks.

2. The OOF children are placed relative to the start-start corner of the containing block (which is just the parent per 1.)? So "3" will be shifted away by (10,15) from the top/left corner of the mfrac:

    <mfrac>
      <mn>1</mn>
      <mn>2</mn>
      <mn style="position: absolute; left: 10px; top: 15px;">3</mn>
    </mfrac>
   

I'm not exactly sure what is the definition of "static-position" and I was not really able to find any in https://drafts.csswg.org/css-position-3/ ; MathML Core already defines position of children for "position: static" children (for example 1 and 2 are positioned with relatively complex rules) but I guess no one proposes to change that here.

@rwlbuis has done some work as per https://github.com/mathml-refresh/mathml/issues/16#issuecomment-518364768 but I'm not sure what he did regarding block container & child positions.

[fred-wang]

In addition to absolutely positioned boxes, out-of-flow boxes also include floated boxes:

https://drafts.csswg.org/css2/visuren.html#positioning-scheme

I propose that for the layout of a math box, the float/clear properties on its children are ignored, similarly to what is done for grid/flexbox. So concretely,

  <math>
    <mfrac>
       <mn style="float: left">1</mn>
       <mn style="clear: left">2</mn>
    </mfrac>
  </math>

is laid out the same as

  <math>
    <mfrac>
       <mn>1</mn>
       <mn>2</mn>
    </mfrac>
  </math>

[NSoiffer]

A few responses:

1. I think only math and mtable should be considered block level elements in MathML. This is consistent with earlier decisions regarding setting width/height, and also probably consistent with how borders are treated.

2. Treating float by ignoring it seems counter to the decision in definition of children? mathml#133 where children are defined to be "in-flow child boxes". Since float is out-of-flow, it wouldn't be a child and would be ignored.

Comments:
When an element is floated relative the block, that affects layout in various ways. E.g., the block width is reduced (AFAIK) and potentially the height is changed. I suspect this complicates the MathML layout so a bonus of restricting what is a block element is that layout is simplified.

clear is not on of the listed out-of-flow properties, so we could ignore it except for maybe block level elements (math/mtable in my argument) as I believe clear affects layout when float is used (which would be relative to the block).

[fred-wang]

2. Treating `float` by ignoring it seems counter to the decision in w3c/mathml#133 where children are defined to be "in-flow child boxes". Since `float` is out-of-flow, it wouldn't be a child and would be ignored.

The idea is to ignore the CSS float property so that a child with a specified float left/right is effectively not floated and so the only out-of-flow children are the absolutely positioned ones.

[fred-wang]

During Thursday's meeting (2019/09/12) the consensus was:

• Ignore float/clear (the spec says that now).
• All MathML elements are containing block.
• The position is relative to the start-start corner of the containing block.

[chrishtr]

• All MathML elements are containing block.

Containing block for all descendants, correct?

[NSoiffer]

This needs tests for positioning so it can be closed.

In addition, the spec likely needs to say more -- it says very little about out-of-flow elements. It currently has "Floats: float and clear are treated as none on all MathML elements." which seems wrong.