<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
<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
<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
<astearns> https://github.com/mathml-refresh/mathml/issues/225
<astearns> https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-692735088
<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
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.)[End of scribe.perl diagnostic output]