- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Jun 2019 19:44:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `math-script-level and math-style`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: math-script-level and math-style<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3746<br> <TabAtkins> bkardell_: In doing Chromium impl of mathml, and trying to explain the mathml magic in a way that's part of the platform, there are some funky areas<br> <TabAtkins> bkardell_: So we want to get that funky added to CSS.<br> <AmeliaBR> Explainer link: https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-explainer.html<br> <TabAtkins> bkardell_: One is math-style. As part of layout, takes into consideration whether your math equation is happening inline in text or as a block; aligns baselines differently and tries to minimize vertical size in inline, etc.<br> <TabAtkins> bkardell_: If we have that, this is one more thing that becomes a UA stylesheet rule.<br> <TabAtkins> bkardell_: math-script-level is in my mind a lot like counters. It lets you scale up or down font-size<br> <TabAtkins> emilio: So when you nest an element that's a subscript or superscript, or part of a fraction, the font-size shrinks.<br> <TabAtkins> emilio: But in CSS it affects the computed font-size, which is annoying.<br> <TabAtkins> fantasai: This effects the font-size. Why is it called script-level, and why is separate from font-size?<br> <TabAtkins> bkardell_: This is how I think it's similar to counters, it carries info about nesting.<br> <TabAtkins> AmeliaBR: So elika's question is why not do this with relative font sizes. I think reason is to give browsers some more flexibility...<br> <TabAtkins> fantasai: We can have math-larger and math-smaller...<br> <TabAtkins> fremy: If you have a fraction, 1/2. You can nest, 1/(1/2). But third level of nesting, switch to a side-by-side fraction.<br> <TabAtkins> bkardell_: Even within that context, you can have sub/superscripts too.<br> <TabAtkins> AmeliaBR: There definitely needs to be a new property. Math fonts have a property saying how much you scale down as you go down a script level.<br> <TabAtkins> AmeliaBR: Do you need to be able to absolutely set "3 sizes down from normal", or is it always single steps?<br> <TabAtkins> bkardell_: These map stragiht from MathML attributes. I know the name isn't great, but<br> <myles_> q+<br> <TabAtkins> emilio: Figuring out which nodes need to incrmeent or decrement the script level is pretty tricky<br> <AmeliaBR> `font-size-math-adjust`???<br> <TabAtkins> emilio: It would be good to see if we can decouple the script-level from font-size, because it becomes much easier, add an "auto" value and figure it out doing layout or something<br> <TabAtkins> AmeliaBR: Does nesting level have effects other than font-size?<br> <TabAtkins> myles_: bkardell said yes<br> <una> what about `font-size-math-adjust: <nesting-level>`<br> <TabAtkins> fantasai: So then you'd want to *select* based on that level. So then that info must be in the DOM.<br> <TabAtkins> fantasai: We've had similar cases in the past of things thought to be in CSS that we pushed back and said "no, this needs to be in the DOM".<br> <TabAtkins> fantasai: Like directionality.<br> <myles_> s/bkardell said yes/fremy said yes/<br> <astearns> ack myles_<br> <astearns> q+ myles_<br> <fremy> (yep, for the record I agree with fantasai)<br> <TabAtkins> dbaron: I think one of the reasons for this is that mathml has attributes that specify both the ratio of font-size for each change in script level, and the min font-size at which you stop changing it.<br> <TabAtkins> dbaron: script-size-multiplier and script-min-size<br> <TabAtkins> fantasai: Does this mean we're adding font-min-size back?<br> <TabAtkins> myles_: There have been a half-dozen or so of these proposals. How do these affect existing elements outside of MathML?<br> <TabAtkins> bkardell_: Some people do indeed think that <math> isn't great, and math layout should be a normal part of CSS.<br> <una> `font-size-math-adjust: <max-nesting-level> / <min-font-size>`<br> <TabAtkins> florian: I think we want the building blocks of math in normal CSS. And I've heard the argument that MathML is bad for math; mathjax people will do that.<br> <TabAtkins> florian: So mathjax renders math into HTML or SVG, but they're missing some tools that make it subpar.<br> <TabAtkins> myles_: So what's the criteria here: hsould math layout be dumped in whole-hog?<br> <chris> https://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle.attrs<br> <TabAtkins> bkardell_: We're trying to find the mathml core and eliminate as much as possible.<br> <TabAtkins> bkardell_: So far we've been doing good at that.<br> <TabAtkins> bkardell_: Reusing CSS stuff well.<br> <chris> also https://www.w3.org/TR/MathML3/chapter3.html#presm.scriptlevel<br> <TabAtkins> astearns: I hear this as a request from another group, like the timed text people, to get something that they can't currently do in CSS.<br> <tantek> q?<br> <fantasai> TabAtkins: Is the goal that you can implement math layout with <div>s, or are we still using mathml but ...<br> <TabAtkins> dbaron: There are two different groups in w3c working on diff solutions here<br> <TabAtkins> s/are we still using mathml but .../are we saying that mathml is a special layout form, like SVG, that can have its own specialized CSS without influencing arbitrary text layout/<br> <TabAtkins> myles_: So if this is a generic layout mechanism, you need to be able to put flexbox inside of it<br> <TabAtkins> florian: I don't think we want to be able to take naive markup and get good math out of it.<br> <fantasai> TabAtkins: Are we intending that you can make a fraction, and the nuerator is a flexbox?<br> <iank_> q+<br> <astearns> ack myles_<br> <fantasai> TabAtkins: If so, you can nest flexbox into it. If not, then you can't.<br> <fantasai> TabAtkins: But need to know which way we're going so we can figure out how to interact with it<br> <fantasai> chrisl: ...<br> <fantasai> TabAtkins: We'd make a Math layout spec<br> <TabAtkins> iank_: So basically mathml is already in this state where you can nest CSS layout inside of it<br> <TabAtkins> iank_: And it uses CSS layouts to ahcieve some of its layouts<br> <TabAtkins> iank_: so <mtable> uses css tables<br> <TabAtkins> iank_: The text inside of mathml is just text layout, it can do floats/etc<br> <tantek> q?<br> <TabAtkins> iank_: This was the feedback we gave to the group: you need to define how this interacts with all of CSS.<br> <astearns> ack iank_<br> <tantek> q+<br> <TabAtkins> myles_: ARe you saying that philophically that's how this shoudl be designed, or that it's just a quirk of impl.<br> <TabAtkins> Rossen: So support rich layout that allows math, and interacts nicely with the rest of css.<br> <fremy> q+<br> <astearns> ack tantek<br> <TabAtkins> astearns: A detail is that some requirements, we may not get to. LIke western typography, some details we never get to.<br> <TabAtkins> myles_: So the intention is that we end up with display:math at some point?<br> <TabAtkins> AmeliaBR: display:fraction, perhaps, like display:ruby : some specialized focused layouts as necessary<br> <dauwhe> this is a w3c strategy funnel issue https://github.com/w3c/strategy/issues/43<br> <myles> q+<br> <tantek> q-<br> <astearns> ack fremy<br> <TabAtkins> fremy: So math-level.<br> <TabAtkins> fremy: If you want a layout that's different depending on the math level, that's fine. We could do that.<br> <dauwhe> https://www.w3.org/community/knowledge-domain/<br> <TabAtkins> fremy: But the way I see this is that math-level is changing other properties, in some weird interaction.<br> <astearns> q+<br> <TabAtkins> fremy: So my mental model matches fantasai, this is at the DOM level.<br> <TabAtkins> fremy: And if we go the "you should do math using divs", that doesn't work.<br> <TabAtkins> fremy: My impression from when I worked on this, is that this is complex to put in a CSS property.<br> <florian> q+<br> <TabAtkins> fremy: But if our goal is to allow everything in CSS, I don't see how it's a markup thing.<br> <TabAtkins> fremy: So question is we need mathml markup, or is there a simplified markup that would provide the grouping/level/etc that we could provide the levels on top of.<br> <astearns> ack myles<br> <TabAtkins> myles: So let's say we do wanna go on this path where we induct math layout into CSS.<br> <TabAtkins> myles: When we write CSS specs we have to describe layout exactly.<br> <TabAtkins> myles: Do you envision that this group would make those decisions, or that MathML would do it and deliver them to us and we'd put them into our docs?<br> <TabAtkins> bkardell_: Right now they're trying to get that defined.<br> <TabAtkins> bkardell_: Huge criticism right now is that it's super underdefined.<br> <TabAtkins> iank_: As part of our launch process we require interop-capable specification.<br> <tantek> FYI: https://caniuse.com/mathml<br> <TabAtkins> iank_: And the two impls currently aren't remotely interoperable, especially layout.<br> <TabAtkins> iank_: I spent two or three hours one day and created a list of issues where Firefox and WebKit differ.<br> <florian> q?<br> <TabAtkins> fantasai: If mathml is going to define a layout model closer to css, they should def interact with us more than what's happening currently.<br> <TabAtkins> fantasai: So we can make sure it's compatible with css layout and all the interactions with othe rproeprties.<br> <tantek> Is there an opportunity for CSS/MathML joint meeting at TPAC?<br> <TabAtkins> fantasai: Just because of where the expertise lies.<br> <AmeliaBR> q+<br> <Rossen_> q?<br> <TabAtkins> astearns: I would really like to see more stuff in the explainer. Righ tnow it looks like a reiteration fo the proposal. It has some markup examples without intended renderings, etc.<br> <Rossen_> ack astearns<br> <TabAtkins> fantasai: SAme, I don't really understand what it's trying to do currently. So I can't even comment on whether they're doing it right or not.<br> <TabAtkins> fantasai: So somebody came up with a solution to a problem, but I don't udnerstand the problem, or why this is the best solution to that problem.<br> <TabAtkins> fantasai: Would love to advise them, but can't right now.<br> <astearns> ack florian<br> <TabAtkins> florian: Back to fremy's point, for those trying to solve math with css, i don't think the goal is markup that resembles mathml and uses display:fraction, display:sqrt, etc. I think it was to start from a mathml-ish markup that is processed into a pile of divs, then rendering fractions with a vertical flexbox, etc. Only a few lacking aspects would need to be added.<br> <TabAtkins> fremy: I don't disagree, that's also an option. But if that's the goal then you don't need the math-script-level property.<br> <TabAtkins> myles: Agree. We already have SVG then.<br> <astearns> ack AmeliaBR<br> <TabAtkins> TabAtkins: SVG doesn't quite solve it - we still need a few small things, like baseline control, stretchy characters. Talked about this at last TPAC. But it's pretty minimal.<br> <TabAtkins> AmeliaBR: So wrapping up, we have some requests from Brian's team at Igalia about how we want communication to happen, better explainers. larger comprehensive use-cases, rather than one proposal at a time.<br> <TabAtkins> AmeliaBR: Would be useful if this group gave feedback about how we'd like to be communicated with.<br> <TabAtkins> AmeliaBR: And then there's further concern about where things should live, CSS vs DOM, etc.<br> <astearns> ack dbaron<br> <AmeliaBR> s/requests from/requests for/<br> <TabAtkins> dbaron: elika was asking about the problem to be solved. There is a political disagreement about the problem.<br> <TabAtkins> dbaron: In that, there is the question of whether mathml is the way forward.<br> <TabAtkins> dbaron: A few years ago when it was in Firefox only and we thought we might remove it, everyone thought MathML wasn't the right way to do it; do it in CSS instead, etc.<br> <TabAtkins> dbaron: And add to CSS to improve mathjax output.<br> <TabAtkins> dbaron: Now we're somewhat surprisingly getting to a world where mathml is supported across browser engines.<br> <TabAtkins> dbaron: So question is whether mathml is, like html, something that needs CSS to reflect on things in it.<br> <TabAtkins> dbaron: ARe we concerned with MathML backcompat such that CSS needs to care about its legacy mechanisms.<br> <TabAtkins> dbaron: Or do we have substantial flexibility to change things as necessary.<br> <TabAtkins> dbaron: So three possibilities:<br> <TabAtkins> dbaron: 1. MathML is in browser engines, CSS has to be compatible with that.<br> <TabAtkins> dbaron: 2. MathML is in browser engines, but we might make substantial changes in the process and can adjust it to CSS better.<br> <TabAtkins> dbaron: 3. MathML isn't the right path forward, and math should be taking this up the path.<br> <TabAtkins> dbaron: Path to making this decision right now is very uncoordinated and not based on principles, but rather on lots of small decisions where people might not be aware of the larger path they're supporting.<br> <TabAtkins> dbaron: Possible we should be discussing this more epxlicitly.<br> <TabAtkins> dbaron: I think before we decide waht we're trying to solve, we might want to have that discussion.<br> <TabAtkins> bkardell_: Before I went to Igalia, I spent a lot of time thinking about this.<br> <TabAtkins> bkardell_: My own thought were between 2 and 3.<br> <TabAtkins> bkardell_: HTML isn't very perfect semantically either, it's focused on text.<br> <TabAtkins> bkardell_: So it has no starting point. It's not like SVG, where we all agree what SVG is.<br> <TabAtkins> bkardell_: Thirty years the community has been working on something, lots of back and forth.<br> <TabAtkins> bkardell_: When we got to HTML5 and mathml was codified into the parser, now it's in a special weird place.<br> <TabAtkins> bkardell_: If there's something I'd personally advocate, it's that we need to find a starting point or we can't have this convo.<br> <TabAtkins> bkardell_: So back with corp hat on, the core-math group is trying to find the minimal bits that hold things together.<br> <TabAtkins> bkardell_: I don't want to personally be like "mathml is the best thing ever", I dunno. I want to be malleable here.<br> <TabAtkins> <br dur=20min><br> <TabAtkins> myles_: Minutes of the Math session during last year's tpac: https://lists.w3.org/Archives/Public/www-style/2018Nov/0008.html<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3746#issuecomment-498815063 using your GitHub account
Received on Tuesday, 4 June 2019 19:44:40 UTC