Define how margin-collapsing should behave

[bfgeek]

Today the current implementations work differently when it comes to margin collapsing.

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

In the above example Firefox appears the formatting context behaves like a block formatting context in that it abides by block-like margin collapsing rules.

I'm not sure what Safari is doing. E.g. another example:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6688

[bfgeek]

My preference here would be to drop any margin collapsing rules in implementations, and instead force completely new formatting contexts on each element.

This needs a lot of tests (with various combinations of elements, positive/negative margins, various levels of nesting) to ensure compatibility.

[fred-wang]

The core spec does not mention any margin collapsing rules currently (although maybe they are implicit in mtable and mtext layout). I'm not sure that would be useful for math.

[fred-wang]

Another test case to compare against CSS, so people can understand:
https://people.igalia.com/fwang/mathml-layout-ng/mathml-margin-collapsing.html

We have:

• a parent (green) with 30px margin-top and 60px margin-bottom
• a child (blue) with 30px margin-top and 60px margin-bottom

Should MathML behave like:

• block: the parent & child's top margins (respectively bottom margins) are collapsed into a single 30px space (respectively 60px space).

• or inline block: we have margin-top (respectively margin-bottom) from the child (green) and parent (white) summing up to a 60px space (respectively 120px space).
  ?

• Currently Gecko behaves like block and performs margin collapsing.

• Baseline alignment seems broken in WebKit when the children have non-zero margin. However, from the added space it seems it does applies margin collapsing rules.

• Igalia's chromium build currently ignores margin values (cf Ensure good integration of MathML with the accessibility tree #9), so it's difficult to say anything about margin collapsing for now. But my guess is that by default the block behavior will apply, because we rely on block flow layout classes for most MathML elements.

As I said, margin collapsing probably does not make any sense for math layout. However, if we don't really care about it and if that facilitates the implementations to follow block's behavior maybe we actually want that.

Adding this to the mathml core meeting agenda.

[NSoiffer]

The <math> element has a display property which can be either block or inline. Shouldn't the behavior depend upon whether MathML this property is set to a specific value (assuming MathML will support margins)? Or maybe it should be harmonized/be declared the same as CSS's display property that allows many more options such as none and inline-block (most don't make much sense for MathML such as 'table', 'list-item', etc).

I don't see the case for inline-block. Is it when the MathML is inside of an inline-block context and display is not set?

Note: if display is not set, the spec is currently silent on what should happen, so that should probably be fixed. Based on the user agent stylesheet, it looks like inline was chosen as the default.

[fred-wang]

Regarding new displays, there is a separate discussion #56 ; currently the actual display value is browser-specific. If the user specifies other values, the idea in #56 would be to fallback to CSS rather than MathML layout.

For the <math> which has "display: block" or "display: inline" we should probably follow CSS for margin collapsing. I want to introduce an anonymous mrow child, so the math root can still layout its child as an mrow.

Anyway, for this issue the only thing to discuss is whether margin-collapsing make any sense for math-specific layout or not.

[bfgeek]

I'd err on the side of leaving margin collapsing out. As it has a lot of weird side affects for the new algorithms/display-types, and is very difficult to get right. E.g. do margins for these new types collapse through if they are empty?
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7062

If you define for these new types that they establish new formatting contexts or their particular type, and their children also establish new formatting context or their particular type, you only need to define how margins interact within that display type.

[fred-wang]

Consensus during mathml core meeting: Ignore margin-collapsing for all new layout as they are no clear use case and that simplifies implementation.

[fred-wang]

There is one test for margin-collapsing: https://w3c-test.org/mathml/relations/css-styling/padding-border-margin/margin-002.html ; maybe we can add more.

[NSoiffer]

Since you only are testing that nothing should happen, so one test is fine.