Re: [csswg-drafts] [css-fonts-4] Managing the scaling of font-size within MathML rendering (#5389)

The CSS Working Group just discussed `Managing the scaling of font-size within MathML rendering`, and agreed to the following:

* `RESOLVED to spec out the a math keyword to font-size which refers to the new math-depth property to get the scaling factor, which acts as a depth counter as described in the issue 2b, and open smaller issues for other things`

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> topic: Managing the scaling of font-size within MathML rendering<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/5389<br>
&lt;fantasai> s/inhertied/inherited 'math-shift'/<br>
&lt;fantasai> s/value/values 'normal' and 'compact'/<br>
&lt;bkardell_> faceless2: fwiw, I think what is there is workable for us, but I don't know how anyone else does it... my question was about how it inherits through elements that aren't math<br>
&lt;fantasai> various options proposed in https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-689965166<br>
&lt;bkardell_> fredw: fantasai has suggested several things at the end, I think they addressed the concerns you had with my initial proposal?<br>
&lt;fantasai> fred explains why one seems better in https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-689989000<br>
&lt;bkardell_> fredw: it seems, imo to resolve all the issues<br>
&lt;bkardell_> faceless2: font-size inherit would probably resolve my worries, that's a good idea<br>
&lt;bkardell_> fredw: the original proposal was to have this counter - it was based on what firefox implements... we tried to modify the proposal to make it simpler, but that just caused more issues.  fantasai suggested these -- b2) seems good to me<br>
&lt;emilio> q+<br>
&lt;bkardell_> fantasai: the problem with the original proposal was "if the font-size is not set explicitly" - which isn't a thing we can do.  The proposal in the interim was things would be internal, but that causes the font-size property to be more complex than it is already which is bad.  I think it makes more sense to keep the counter, and just have the font-size have a seperate keyword that just says "go look at that math-size value"<br>
&lt;bkardell_> fantasai: math-depth: auto adds 1 if the size is cramped and not otherwise...<br>
&lt;fantasai> probably should rename the 'auto' keyword<br>
&lt;bkardell_> fredw: it's not cramped it's math-style - when math-style is compact, the counter is incremented by 1.  This is used to cover fractions<br>
&lt;bkardell_> fredw: if you check the example bkardell_ included at the beginning you can see the difference in them<br>
&lt;bkardell_> NeilS: there is that one weird fraction rule<br>
&lt;astearns> ack emilio<br>
&lt;bkardell_> emilio:  I don't love the proposed solution because it adds a prop on which font-size depends, which is bad because so many things ultimately depends on font-size. I think that adds another pass on style resolution<br>
&lt;bkardell_> astearns: is it a second pass or just another check?<br>
&lt;bkardell_> astearns: it's only extra stuff you have to do if it is non-zero<br>
&lt;bkardell_> emilio: that might be doable... I will have to think about it... but it means that there is a state where you might have a wrong font size... I will have to think about it...<br>
&lt;bkardell_> emilio: it may be true that we can fix up the font size... I need to double check<br>
&lt;bkardell_> astearns: please double check because I agree that could be bad if it is hard<br>
&lt;bkardell_> fantasai: the other solution was worse?<br>
&lt;fantasai> s/was worse/is to keep the counter as part of the font-size property itself/<br>
&lt;bkardell_> emilio:  I will have to go and check what ff does<br>
&lt;fantasai> s/itself/itself, are you thinking that's better??/<br>
&lt;bkardell_> emilio: we fix up the font size after the fact, right?<br>
&lt;bkardell_> fredw: I think the issue in gecko was we were supporting the min font size<br>
&lt;bkardell_> emilio: it might not be such a big issue as I thought it was<br>
&lt;bkardell_> fantasai: it should have no dependency on anything but itself<br>
&lt;bkardell_> emilio: ok, I am not very concerned then<br>
&lt;fantasai> oh, and I guess also dependency on 'math-style'...<br>
&lt;bkardell_> emilio: I will double check it, but I dont think we should block on resolving this actually... I like it better<br>
&lt;bkardell_> proposed: add a math keyword to font-size which refers to the new math-depth property to get the scaling factor, which acts as a depth counter as described in the issue.<br>
&lt;bkardell_> fredw: it is not like this in any browser, but it isn't too hard to align them on this<br>
&lt;bkardell_> astearns:  Let's resolve to get this in a spec and file separate issues on smaller things like 'should we rename the auto value'?<br>
&lt;fredw> this was where min-font-size was removed: https://github.com/w3c/csswg-drafts/issues/3739<br>
&lt;bkardell_> RESOLVED to spec out the a math keyword to font-size which refers to the new math-depth property to get the scaling factor, which acts as a depth counter as described in the issue 2b, and open smaller issues for other things<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-694361834 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 17 September 2020 16:49:48 UTC