<astearns> https://github.com/w3c/csswg-drafts/issues/5513

<NeilS> Brian: this is a one liner, it is shipping in all the browsers

<NeilS> All: agreed to do.

I will send a PR

RESOLUTION: accept a PR to add CSSOM for MathML

cramped script style

<astearns> github: https://github.com/w3c/csswg-drafts/issues/5388

NeilS: cramped style is a thing specific to math typsetting - it reduces the vertical size in a few situations
... it's about the positioning and the superscript in a few situations, it's been part of systems like LaTeX and typesettings
... if you look at the example in the issue, you can see the 2 is 'cramped' down - it's been standard in math typesetting to do this for as long as typesetting has existed, basically

astearns: You're applying it to the entire expression whether or not it has -- just incase it does?

NeilS: It's sort of automatically set for math, and the reason to expose it to authors is really just if the general rules don't fit somehow - so they could override it

fredw: they are just UA stylesheet rules that define things for Math typography, and people could still use this kind of thing similarly if they needed

iank_: I think this kind of makes sense -- to respond to amelia's issue - ... (missed it), but I think this makes sense to me

astearns: you mentioned the default stylesheet would have the thing defined...

iank_: does anyone have opinions on the naming

fredw: the name has always been 'cramped' which comes from tech, but it seems most people in css don't know that so the suggestion from fantasai was this
... we originally called it "math-superscript-shift" but fantasai suggested this was too long...

<iank_> "to respond to amelia's issue" -> vertical-align doesn't immediately work as it isn't inherited, this would be set in the UA stylesheet e.g. `msqrt { math-script: cramped; }` which would then apply to the sub-tree.

astearns: and you could turn it into a shorthand if we expanded it....

<dholbert> my mic isn't working, but I have a question about inheritance

<dholbert> what if we had x/y inside of the sqrt() operation here?

<dholbert> and y had an exponent

<dholbert> does it apply to the "y"?

<dholbert> (seems a bit odd as the sqrt bar isn't close to the y)

<dholbert> yeah

fredw: the normal css inheritcance will apply so it would also have a compact style

astearns: does TeX do this as well

fredw: yes, because that is what it copies from

<dholbert> just strange that sqrt(...) changes the rendering of arbitrary stuff inside the sqrt operation

<dholbert> (in the screenshot, it looks like we're aiming to dodge the bar of the sqrt)

astearns: we have the cramped style to lay out the line better, so part of that is making the radical get closer to the exponent to make things more compact and kind of line up. Doing the same thing as an exponent in a denominator doesn't seem to have as much of an effect

<fredw> https://mathml-refresh.github.io/mathml-core/#the-math-shift

<dholbert> (I don't object; I just want to be sure we don't accidentally specify something that doesn't match the intent)

<dholbert> cool! ok thanks

NeilS: You can criticize TeX, there are shortcommings... But there are just a couple of places where it shifts to this cramped situation, layout rules want to shrink the vertical height when they can - so this is how TeX has always done it and it's just how people expect it now

RESOLVED we add an inherited 'math-shift' property with two values 'normal' and 'compact' and the default of normal

Managing the scaling of font-size within MathML rendering

<astearns> github: https://github.com/w3c/csswg-drafts/issues/5389

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

<fantasai> various options proposed in https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-689965166

fredw: fantasai has suggested several things at the end, I think they addressed the concerns you had with my initial proposal?

<fantasai> fred explains why one seems better in https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-689989000

fredw: it seems, imo to resolve all the issues

faceless2: font-size inherit would probably resolve my worries, that's a good idea

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

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"
... math-depth: auto adds 1 if the size is cramped and not otherwise...

<fantasai> probably should rename the 'auto' keyword

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
... if you check the example bkardell_ included at the beginning you can see the difference in them

NeilS: there is that one weird fraction rule

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

astearns: is it a second pass or just another check?
... it's only extra stuff you have to do if it is non-zero

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...
... it may be true that we can fix up the font size... I need to double check

astearns: please double check because I agree that could be bad if it is hard

fantasai: the other solution is to keep the counter as part of the font-size property itself, are you thinking that's better???

emilio: I will have to go and check what ff does
... we fix up the font size after the fact, right?

fredw: I think the issue in gecko was we were supporting the min font size

emilio: it might not be such a big issue as I thought it was

fantasai: it should have no dependency on anything but itself

emilio: ok, I am not very concerned then

<fantasai> oh, and I guess also dependency on 'math-style'...

emilio: I will double check it, but I dont think we should block on resolving this actually... I like it better

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.

fredw: it is not like this in any browser, but it isn't too hard to align them on this

astearns: Let's resolve to get this in a spec and file separate issues on smaller things like 'should we rename the auto value'?

<fredw> this was where min-font-size was removed: https://github.com/w3c/csswg-drafts/issues/3739

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

agenda wrangling

<astearns> https://github.com/mathml-refresh/mathml/issues/225

<astearns> https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-692735088

math/inline-math redux

<astearns> github: https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-692735088

<fantasai> +1 to mats's suggestion

fredw: (asking for clarity)

<oriol> +1 to mats

fantasai: so the default would be that math is inline, and you could say block

fredw: I think this is related to iank_ suggestions about adding support for the legacy syntax
... I guess part of the rationale was also that the 2 value syntax isn't supported by all browsers yet

<iank_> I think generally it makes sense for inline-math just for the purposes of that's what web developers are used to expect. :)

fantasai: I think really it was just about consistency -- he was saying, or tab was saying - there is value for authors in maintaining the consistency since it is a minor add

faceless2: It would mean you couldn't get it implemented/tested until you had 2 value support in all of the browsers

fantasai: you could 1 off implement it just for this, but I dont think that would be a good idea. I don't think the parsing problems are diffiult, it's just that there hasn't been a strong motivation for anyone to do it

fredw: I am curious how you would get block math without supporting this?

astearns: you couldn't

<NeilS> bkarell: we would like to keep the legacy keyword, right?

<NeilS> fantasai: block-math?

bkardell_: right: ... nevermind that doesn't make sense

<NeilS> fanstasi: if you ask the chrome team, they probably will tell you that the two keyword version just hasn't been a priority

cbiesinger: I am not concerned about it

fredw: I think the parsing is probably easy but then we have to store the value internally and serialize it

emilio: it's super easy, I know the chrome code for this - it's very easy

fredw: ok so I guess it should be easy

oriol: I agree it should be easy

astearns: I think I am hearing consensus to follow the ruby model and use 2 values only/defaults to inline

fredw: what does the serialization look like?

fantasai: you serialize to the shortest form, so it will serialize as display: math or display: block math

RESOLUTION: to ammend our previous resolution to follow the ruby model and use 2 values only/defaults to inline, as is suggested in the issue

end

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/inhertied/inherited 'math-shift'/
Succeeded: s/value/values 'normal' and 'compact'/
Succeeded: s/was worse/is to keep the counter as part of the font-size property itself/
Succeeded: s/itself/itself, are you thinking that's better??/
Succeeded: s/chrishtr/cbiesinger/
Succeeded: s/<something>/I agree it should be easy/
Default Present: NeilS, bkardell_, dholbert, faceless, oriol, fredw, cbiesinger, rego, iank_, emilio
Present: NeilS bkardell_ dholbert faceless oriol fredw cbiesinger rego iank_ emilio faceless2
No ScribeNick specified.  Guessing ScribeNick: bkardell_
Inferring Scribes: bkardell_

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)