-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define what block percentages resolve against. #77
Comments
My preferred mode would be to follow the new grid/flex/layout-api behaviour of not passing parents percent resolution size down to children. However this also depends on what is decided for the width/height issue. |
I'll put this on the agenda of the next MathML CG meeting. I think it does not make much sense for math layout to resolve percent size for children as relative to the parent size (unless maybe int table cells?). That complicates things and is likely to be even worse with stretchy operators. I see two interpretations possible: Since mspace content is empty, (2) would also work for mspace. |
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. |
You still need to define this for nested elements which do abide by width/height. (See test-case). |
Proposal: resolve percent against 0. |
This was discussed (argued :-) in the 9/9/19 MathML core meeting. In that meeting, @fred-wang argued for '0' and @NSoiffer argued for the containing block (which could be mtable or math) The argument for '0' is simplicity of implementation. The argument for the containing block is consistency with HTML. @rwlbuis was going to look into how hard it really would be to look up and use the containing block's render width/height. |
Consensus from 2019/09/12 is essentially: use the size provided by a block container without display: math |
Still needs spec change (spec still has issue link note) |
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6703
Safari appears to follow the quirks mode behaviour of walking up ancestor chain.
Firefox appears to resolve against zero.
This needs to be defined, with tests, and various writing modes etc.
The text was updated successfully, but these errors were encountered: