W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2020

Re: [csswg-drafts] [css-display] math/inline-math (#5385)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 10 Sep 2020 16:32:03 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-690462275-1599755522-sysbot+gh@w3.org>
The CSS Working Group just discussed `math-oriented display values`, and agreed to the following:

* `RESOLVED: Add 'math' as a <display-inside> value.`
* `RESOLVED: Add 'inline-math' as a <display-legacy> value.`
* `RESOLVED: 'math' outside of MathML context behaves as 'flow'`
* `RESOLVED: 'math' outside of MathML context computes to 'flow'`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: math-oriented display values<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/5385<br>
&lt;fantasai> bkardell_: 2 ways of integrating math into text<br>
&lt;fantasai> bkardell_: inline style or block style<br>
&lt;fantasai> bkardell_: proposal is to add display style<br>
&lt;fantasai> bkardell_: there was a comment in the issue that it should be "inline math" instad of "inline-math"<br>
&lt;fantasai> astearns: It would be a display-inside value<br>
&lt;fantasai> iank_: I think web devs are quite used to 'inline-foo' pattern<br>
&lt;fantasai> iank_: math is an inside display type, but maybe add as an alias<br>
&lt;fantasai> TabAtkins: I agree<br>
&lt;fantasai> TabAtkins: if we were adding a bunch more at once, could maybe make a clean break<br>
&lt;fantasai> TabAtkins: but just one would feel inconsistent<br>
&lt;fantasai> TabAtkins: so would say add inline-math into the table, easy<br>
&lt;fantasai> dholbert: Other places where 'display: contents' is like none?<br>
&lt;fantasai> faceless2: SVG<br>
&lt;fantasai> TabAtkins: various form elements, replaced elements<br>
&lt;fantasai> astearns: So we want ...?<br>
&lt;fantasai> TabAtkins: Add math to &lt;display-inside>, add inline-math to &lt;display-legacy><br>
&lt;fantasai> iank_: It's basically zero overhead to add inline-math and convenient to authors<br>
&lt;fantasai> astearns: What happens to 'inline-math' on non-MathML elements?<br>
&lt;fantasai> fredw: Would behave like none<br>
&lt;fantasai> faceless2: I thought behaved like mrow<br>
&lt;fantasai> NeilS: Unrecognized elements in MathML context only<br>
&lt;bkardell_> fantasai:  generally speaking we try to avoid having things disappear if you do something slightly wrong<br>
&lt;bkardell_> fantasai: I don't think it should behave as display none on unrecognized elements.  The fact that display contents does that is really only because we couldnt' think of another way, but that isn't a good pattern<br>
&lt;fantasai> astearns: My expectation was behave like 'flow' on non-MathML element<br>
&lt;fantasai> astearns: either inline or block<br>
&lt;fantasai> iank_: If you have div { display: math; }, will effectively create a block flow internally<br>
&lt;fantasai> fredw: create a block node<br>
&lt;fantasai> iank_: would change box tree slightly<br>
&lt;fantasai> fredw: that's also what we do if don't set display: math on math element<br>
&lt;dholbert> for comparison / reference, data:text/html,&lt;input type="radio" style="display:flex"> still renders as a radio button (we don't force it to display:none)<br>
&lt;fantasai> bkardell_: Unknown element will by default do what you're asking for, but what happens if you set 'display: math' explicitly on it, do something it can't do<br>
&lt;fantasai> fantasai: Ignoring isn't an option, can make it behave as a different value though<br>
&lt;fantasai> RESOLVED: Add 'math' as a &lt;display-inside> value.<br>
&lt;fantasai> RESOLVED: Add 'inline-math' as a &lt;display-legacy> value.<br>
&lt;fantasai> RESOLVED: 'math' outside of MathML context behaves as 'flow'<br>
&lt;fantasai> emilio: Does it behave as or compute to flow?<br>
&lt;fantasai> TabAtkins: whichever is easiest<br>
&lt;fantasai> emilio: compute to is more likely to be easier<br>
&lt;fantasai> emilio: it's what we do for 'display: contents'<br>
&lt;fantasai> RESOLVED: 'math' outside of MathML context computes to 'flow'<br>
&lt;fantasai> emilio: What if you have a non-MathML element inside a MathML element?<br>
&lt;fantasai> fredw: An element not in MathML namespace?<br>
&lt;fantasai> emilio: document.createElement('div') and append to math element<br>
&lt;fantasai> iank_: should work<br>
&lt;fantasai> emilio: should work how?<br>
&lt;fantasai> fredw: not defined<br>
&lt;fantasai> emilio: should be defined<br>
&lt;fantasai> emilio: SVG just doesn't create boxes for those elements<br>
&lt;fantasai> emilio: if you have a random div in SVG, doesn't do much. Not a fan of this.<br>
&lt;fantasai> NeilS: I thought MathML spec said it would be treated as an mrow?<br>
&lt;fantasai> fredw: non-MathML element, so not in the MathML namespace<br>
&lt;fantasai> NeilS: I thought we'd treat as unknown element, whether in mathml namespace or not<br>
&lt;fantasai> iank_: I don't think you specifically want that<br>
&lt;fantasai> iank_: the way that MathML core is currently specified, we can accept arbitrary elements inside MathML subtree<br>
&lt;fantasai> iank_: all the integration points, because more closely tied to CSS, should just work<br>
&lt;fantasai> iank_: if you have a div inside a mathML mrow or something like that, that should lay out as block<br>
&lt;fantasai> fantasai: Should lay out as block inside, whatever MathML wants to do inside<br>
&lt;fantasai> astearns: Seems need to do something around this, but let's get to other issues in the agenda<br>
&lt;faceless2> In SVG, unknown elements collapse to a &lt;g> normally, or a &lt;tspan> if they're inside a &lt;text><br>
&lt;fantasai> fantasai: Might make sense if you set div { display: math; } then behave same as unknown mathml namespace element with that, treat as mrow<br>
&lt;TabAtkins> Yup, and &lt;mrow> is the mathml equivalent to a &lt;g> basically<br>
&lt;fantasai> emilio: A bit skeptical that that works<br>
&lt;fantasai> emilio: if you put a float inside mathml?<br>
&lt;fantasai> iank_: Like flex/grid, it blockifies.<br>
&lt;fantasai> iank_: doesn't float<br>
&lt;fantasai> emilio: but you need to define these cases.<br>
&lt;fantasai> emilio: how does abspos behave, what's the containing block<br>
&lt;fantasai> emilio: etc.<br>
&lt;fantasai> fredw: tried to write this up in the spec<br>
&lt;fantasai> astearns: Let's raise issue on spec and come back to it some other day<br>
&lt;fantasai> emilio: I don't think these are obscure cases.<br>

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 September 2020 16:32:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:16 UTC