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