search

w3c / mathml-core

MathML Core draft
https://w3c.github.io/mathml-core
36 stars 14 forks source link

Define what inline percentages resolve against. #76

Open bfgeek opened 5 years ago

bfgeek commented 5 years ago

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

Safari appears to resolve against zero. Firefox appears to resolve against its (parents?) width?

This needs to be defined, and tests with various combinations of elements, and various writing modes (depending what is decided).

fred-wang commented 5 years ago

See https://github.com/mathml-refresh/mathml/issues/50#issuecomment-508737052

fred-wang commented 5 years ago

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.

bfgeek commented 5 years ago

You still need to define this for nested elements which do abide by width/height. (See test-case).

NSoiffer commented 5 years ago

Update: although my answer below touches on this issue, I think it is more relevant for w3c/mathml#50 since token elements are mostly (currently) defined as block level elements in the spec.

For leaf content, it seems that the answer lies in whether we decide leaves are inline or inline-block. If inline, then this question is trivially resolved (it's 0). Currently the core spec says that mtext (and hence many leaf elements) for layout are block box. Assuming this stays, then it seems like the width needs to be relative to a parent context that can set the width: either math or mtable. In the latter case, if it lies in a column of fixed with, then that's the context.

The issue of whether elements are block or inline has come up a number of times. My memory is that in most (all?) cases, having most elements be inline simplifies interactions with CSS. Although @fred-wang is probably not happy with opening up something he probably feels has to be the way the spec says it is, we probably should have an issue to at least get the rationale down so everyone can understand it and agree upon it.

fred-wang commented 5 years ago

You still need to define this for nested elements which do abide by width/height. (See test-case).

Proposal: resolve percent against 0 in this case.

rwlbuis commented 5 years ago

I am not sure that the original example is valid, according to the spec div is not allowed in span. I did my experiments with: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7193

fred-wang commented 5 years ago

Consensus from 2019/09/12 is essentially: use the size provided by a block container without display: math