16:16:07 <RRSAgent> RRSAgent has joined #css
16:16:07 <RRSAgent> logging to https://www.w3.org/2020/09/17-css-irc
16:16:09 <Zakim> RRSAgent, make logs Public
16:16:10 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:17:13 <NeilS> NeilS has joined #css
16:17:37 <astearns> https://github.com/w3c/csswg-drafts/issues/5513
16:18:48 <NeilS> Brian: this is a one liner, it is shipping in all the browsers
16:19:13 <NeilS> All: agreed to do.
16:19:15 <bkardell_> I will send a PR
16:19:26 <NeilS> present+
16:19:29 <bkardell_> present+
16:19:31 <dholbert> present+
16:19:40 <faceless2> present+
16:19:41 <oriol> present+
16:19:43 <fredw> present+
16:19:56 <cbiesinger> present+
16:20:03 <rego> present+
16:20:32 <bkardell_> RESOLVED: accept a PR to add CSSOM for MathML
16:20:35 <iank_> present+
16:20:56 <astearns> topic: cramped script style
16:21:03 <astearns> github: https://github.com/w3c/csswg-drafts/issues/5388
16:21:41 <bkardell_> NeilS: cramped style is a thing specific to math typsetting - it reduces the vertical size in a few situations
16:21:41 <emilio> present+
16:22:10 <bkardell_> NeilS: it's about the positioning and the superscript in a few situations, it's been part of systems like LaTeX  and typesettings
16:22:56 <bkardell_> NeilS: 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
16:23:23 <bkardell_> astearns: You're applying it to the entire expression whether or not it has -- just incase it does?
16:23:58 <bkardell_> 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
16:24:44 <bkardell_> 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
16:25:22 <bkardell_> iank_: I think this kind of makes sense -- to respond to amelia's issue - ... (missed it), but I think this makes sense to me
16:25:50 <bkardell_> astearns: you mentioned the default stylesheet would have the thing defined...
16:26:35 <bkardell_> iank_:  does anyone have opinions on the naming
16:27:08 <bkardell_> 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
16:27:34 <bkardell_> fredw: we originally called it "math-superscript-shift" but fantasai  suggested this was too long...
16:27:40 <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.
16:27:50 <bkardell_> astearns: and you could turn it into a shorthand if we expanded it....
16:27:50 <dholbert> my mic isn't working, but I have a question about inheritance
16:28:05 <dholbert> what if we had x/y inside of the sqrt() operation here?
16:28:09 <dholbert> and y had an exponent
16:28:14 <dholbert> does it apply to the "y"?
16:28:24 <dholbert> (seems a bit odd as the sqrt bar isn't close to the y)
16:28:54 <dholbert> yeah
16:28:57 <bkardell_> fredw: the normal css inheritcance will apply so it would also have a compact style
16:29:04 <bkardell_> astearns: does TeX do this as well
16:29:17 <bkardell_> fredw: yes, because that is what it copies from
16:29:22 <dholbert> just strange that sqrt(...) changes the rendering of arbitrary stuff inside the sqrt operation
16:29:39 <dholbert> (in the screenshot, it looks like we're aiming to dodge the bar of the sqrt)
16:30:00 <bkardell_> 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
16:30:36 <fredw> https://mathml-refresh.github.io/mathml-core/#the-math-shift
16:30:55 <dholbert> (I don't object; I just want to be sure we don't accidentally specify something that doesn't match the intent)
16:30:57 <dholbert> cool! ok thanks
16:31:08 <bkardell_> 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
16:32:14 <bkardell_> RESOLVED we add an inhertied property with two value and the default of normal
16:32:17 <astearns> topic: Managing the scaling of font-size within MathML rendering
16:32:23 <astearns> github: https://github.com/w3c/csswg-drafts/issues/5389
16:32:29 <fantasai> s/inhertied/inherited 'math-shift'/
16:32:45 <fantasai> s/value/values 'normal' and 'compact'/
16:34:37 <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
16:34:42 <dholbert> dholbert has joined #css
16:34:57 <fantasai> various options proposed in https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-689965166
16:35:09 <bkardell_> fredw: fantasai has suggested several things at the end, I think they addressed the concerns you had with my initial proposal?
16:35:12 <fantasai> fred explains why one seems better in https://github.com/w3c/csswg-drafts/issues/5389#issuecomment-689989000
16:35:20 <bkardell_> fredw: it seems, imo to resolve all the issues
16:35:51 <bkardell_> faceless2: font-size inherit would probably resolve my worries, that's a good idea
16:36:39 <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
16:38:14 <emilio> q+
16:38:15 <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"
16:38:46 <bkardell_> fantasai: math-depth: auto adds 1 if the size is cramped and not otherwise...
16:39:22 <fantasai> probably should rename the 'auto' keyword
16:39:24 <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
16:39:56 <bkardell_> fredw: if you check the example bkardell_ included at the beginning you can see the difference in them
16:40:07 <bkardell_> NeilS: there is that one weird fraction rule
16:40:09 <astearns> ack emilio
16:40:54 <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
16:41:02 <bkardell_> astearns: is it a second pass or just another check?
16:41:19 <bkardell_> astearns: it's only extra stuff you have to do if it is non-zero
16:41:56 <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...
16:42:11 <bkardell_> emilio: it may be true that we can fix up the font size... I need to double check
16:42:28 <bkardell_> astearns: please double check because I agree that could be bad if it is hard
16:42:40 <bkardell_> fantasai: the other solution was worse?
16:42:57 <fantasai> s/was worse/is to keep the counter as part of the font-size property itself/
16:42:58 <bkardell_> emilio:  I will have to go and check what ff does
16:43:15 <fantasai> s/itself/itself, are you thinking that's better??/
16:43:18 <bkardell_> emilio: we fix up the font size after the fact, right?
16:43:36 <bkardell_> fredw: I think the issue in gecko was we were supporting the min font size
16:43:51 <bkardell_> emilio: it might not be such a big issue as I thought it was
16:44:01 <bkardell_> fantasai: it should have no dependency on anything but itself
16:44:11 <bkardell_> emilio: ok, I am not very concerned then
16:44:35 <fantasai> oh, and I guess also dependency on 'math-style'...
16:45:20 <bkardell_> emilio: I will double check it, but I dont think we should block on resolving this actually... I like it better
16:46:21 <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.
16:47:13 <bkardell_> fredw: it is not like this in any browser, but it isn't too hard to align them on this
16:47:50 <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'?
16:48:08 <fredw> this was where min-font-size was removed: https://github.com/w3c/csswg-drafts/issues/3739
16:48:50 <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
16:49:01 <dauwhe> dauwhe has joined #css
16:49:44 <astearns> topic: agenda wrangling
16:49:46 <astearns> https://github.com/mathml-refresh/mathml/issues/225
16:49:57 <astearns> https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-692735088
16:51:38 <astearns> topic: math/inline-math redux
16:51:48 <astearns> github: https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-692735088
16:52:35 <fantasai> +1 to mats's suggestion
16:53:40 <bkardell_> fredw: (asking for clarity)
16:54:13 <oriol> +1 to mats
16:54:25 <bkardell_> fantasai: so the default would be that math is inline, and you could say block
16:55:11 <bkardell_> fredw: I think this is related to iank_ suggestions about adding support for the legacy syntax
16:55:48 <bkardell_> fredw: I guess part of the rationale was also that the 2 value syntax isn't supported by all browsers yet
16:56:16 <iank_> I think generally it makes sense for inline-math just for the purposes of that's what web developers are used to expect. :)
16:56:26 <bkardell_> 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
16:56:47 <bkardell_> faceless2:  It would mean you couldn't get it implemented/tested until you had 2 value support in all of the browsers
16:57:26 <bkardell_> 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
16:57:47 <bkardell_> fredw: I am curious how you would get block math without supporting this?
16:57:54 <bkardell_> astearns: you couldn't
16:58:29 <NeilS> bkarell: we would like to keep the legacy keyword, right?
16:59:03 <NeilS> fantasai: block-math?
16:59:30 <bkardell_> bkardell_: right: ... nevermind that doesn't make sense
16:59:37 <NeilS> fanstasi: if you ask the chrome team, they probably will tell you that the two keyword version just hasn't been a priority
16:59:41 <bkardell_> chrishtr: I am not concerned about it
16:59:56 <fantasai> s/chrishtr/cbiesinger/
17:00:05 <bkardell_> fredw: I think the parsing is probably easy but then we have to store the value internally and serialize it
17:00:21 <bkardell_> emilio: it's super easy, I know the chrome code for this - it's very easy
17:00:37 <bkardell_> fredw: ok so I guess it should be easy
17:00:48 <bkardell_> oriol: <something>
17:01:29 <bkardell_> astearns: I think I am hearing consensus to follow the ruby model and use 2 values only/defaults to inline
17:01:36 <oriol> s/<something>/I agree it should be easy/
17:01:38 <bkardell_> fredw: what does the serialization look like?
17:02:00 <bkardell_> fantasai: you serialize to the shortest form, so it will serialize as display: math or display: block math
17:02:37 <bkardell_> RESOLVED: to ammend our previous resolution to follow the ruby model and use 2 values only/defaults to inline, as is suggested in the issue
17:03:47 <astearns> topic: end
17:03:56 <astearns> zakim, end meeting
17:03:56 <Zakim> As of this point the attendees have been NeilS, bkardell_, dholbert, faceless, oriol, fredw, cbiesinger, rego, iank_, emilio
17:03:58 <Zakim> RRSAgent, please draft minutes
17:03:58 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/17-css-minutes.html Zakim
17:04:01 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:04:06 <Zakim> Zakim has left #css
17:04:56 <dauwhe> dauwhe has joined #css
17:08:41 <gsnedders> has anyone filed a bug for HTML to define what a "segment break" is within the HTML document language?
17:14:24 <fantasai> gsnedders: I don't think so
17:15:46 <gsnedders> has anyone in general taken responsibility for making sure things that are defined at the document language get defined for web-exposed document languages?
17:23:09 <gsnedders> it would be nice to have a policy to file bugs when making a change that requires work in other web platform specs!
17:27:56 <fantasai> gsnedders: css-text-3 treats all U+A as segment breaks regardless
17:28:01 <fantasai> gsnedders: and that's what DOM outputs anyone
17:28:04 <fantasai> anyway
17:28:14 <fantasai> gsnedders: so nothing needs to be done
17:28:48 <fantasai> Like in theory I could have gone with "only consider things defined as segment breaks"
17:28:55 <fantasai> might have been slightly preferable
17:28:57 <gsnedders> it;s soit's somewhat surprising that it isn't a superset of https://infra.spec.whatwg.org/#ascii-whitespace?
17:28:58 <fantasai> but there needed to be a default
17:29:17 <fantasai> whitespace generally is not a segment break
17:29:23 <fantasai> only "line breaks" are
17:29:33 <fantasai> the things that are used to separate lines in the source code
17:29:44 <fantasai> at this point, we mostly use LF . Historically people used other things
17:30:23 <fantasai> I could have done "LF unless the document defines a different segment break, in which case use that"
17:30:27 <fantasai> but then that wouldn't work for CSS generated content
17:30:29 <fantasai> so
17:30:43 <fantasai> that's where we are
17:31:05 <fantasai> I suppose we could change the spec to say "segment break unless the document defines a different segment break, in which case use that, but CSS generated content uses LF"
17:31:16 <fantasai> Doesn't really matter in practice...
17:31:59 <fantasai> given that the parsing algorithm turns things in to LF in HTML and XML ?
17:32:50 <fantasai> yeah, XML also normalizes line breaks
17:33:27 <fantasai> So I guess my conclusion is, I could replace
17:33:32 <fantasai> For CSS processing, each document language–defined segment break and each line feed (U+000A) in the text is treated as a segment break
17:33:59 <fantasai> with each document language-defined segment break--or line feed (U+000A) if one isn't defined--in the text ...
17:34:19 <fantasai> and that would have no real effect, but might be nice for languages that don't use U+A as a segment break
17:34:56 <fantasai> but neither HTML nor XML needs to say anything about it because LF is already handled as expected
17:35:02 <fantasai> and they turn everything into LF already
17:35:58 <fantasai> Oh, and I suppose I'd have to add "for the purpose of CSS generated content, segment breaks are U+A or somesuch
17:54:18 <gsnedders> fantasai: if you add things to the DOM directly you can get things that aren't LF
18:11:54 <fantasai> gsnedders: Yeah, and they're not segment breaks, because DOM doesn't define them to be such
18:12:06 <fantasai> gsnedders: I don't see a problem.
19:05:48 <dauwhe> dauwhe has joined #css
19:21:41 <dauwhe> dauwhe has joined #css
21:22:33 <dauwhe> dauwhe has joined #css
21:38:27 <dauwhe> dauwhe has joined #css
23:30:10 <dholbert> dholbert has joined #css
23:39:20 <dauwhe> dauwhe has joined #css
23:52:32 <dauwhe> dauwhe has joined #css
23:59:46 <duga> duga has joined #css