W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

Re: [csswg-drafts] [css-inline] vertically align to nth-child (#1339)

From: Frédéric Wang via GitHub <sysbot+gh@w3.org>
Date: Sat, 13 Jun 2020 06:19:35 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-643577492-1592029173-sysbot+gh@w3.org>
I was asked to comment on this issue but I feel I'm lacking the full context of this request. I can understand alignment against a specific child might be useful for some math constructions but the case of fraction (and more generally for all primitives math constructions with rules defined in the TeXBook / OpenType MATH [1]) the example is not really convincing to be honest...

Concretely, the codepen uses 3 spans for the numerator, horizontal bar and denominator, without space between them (other than the default one around the text inside the 1st and 3nd span) and the goal is to vertically align the middle of the 2nd one with the math axis of the container. I don't see this baseline anymore in [2], but equivalently it is AxisHeight [1] above the (first) alphabetic baseline of the container. It would definitely possible to define such an automatic alignment but more is missing in order to properly perform the full math layout of a fraction [1]:

* One needs access to font parameters (I believe this is handled in a separate CSS proposal by the Houdini people) e.g. to decide the rule thickness of the bar or AxisHeight from the (first) alphabetic baseline of the container.
* One has to know the math-style to decide between e.g. fraction*Shift* and fraction*DisplayStyleShift* (this is handled by #3746 but was put on hold ; hopefully we will be able to reopen the discussion on this soon)
* One has to know the ink extent of the text in the numerator/denominator text to do the proper layout.
* The minimal gaps between the ink extent of the numerator/denominator and fraction bar is calculated from the fraction*GapMin parameters.
* The minimal shifts between the middle of the fraction bar and the (first) alphabetic baselines of the numerator/denominator is calculated from the fraction*Shift* parameters.

So if you consider for example a numerator with a large block size below its (first) alphabetic baseline, the distance from the fraction bar is essentially given by fractionNumerator*GapMin. But if the numerator is changed to have very small block size below its (first) alphabetic baseline, that distance must now be increased to honor the minimal fractionNumerator*ShiftUp constraint. So even if the fraction bar alignment is done automatically, one still needs to recalculate the whole gaps/shifts between the numerator/denominator and fraction bar ; while avoiding this recursive calculation was apparently the problem to address.

Obviously, fraction is one the simplest math layout and the situation will be even trickier for more complex constructions. So the conclusion of this long explanation is that this proposal alone will probably not be useful if the goal is to have math layout with quality comparable to TeX / OpenType. It can be fine for very specific cases that use CSS layout with simplified math layout like the ones show in codepen though.

In any case, I personally believe it is more interesting to consider JavaScript layout based on the CSS Layout API in order to perform this kind of advanced layout required for math layout. For example, this single vertical alignment property will probably be irrelevant if the CSS Layout API becomes widely available and is extended to allow authors to specify alphabetic baselines [3]. Last time I tried, this feature was not working yet in Blink but I'm sure @bfgeek can give more details on the status and plan here.

[1] https://docs.microsoft.com/en-us/typography/opentype/spec/math
[2] https://drafts.csswg.org/css-writing-modes-3/
[3] https://drafts.css-houdini.org/css-layout-api/#interaction-alignment


-- 
GitHub Notification of comment by fred-wang
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1339#issuecomment-643577492 using your GitHub account
Received on Saturday, 13 June 2020 06:19:37 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:27 UTC