MathML - CSS Integration

astearns: First item was meta-issue by bkardell_

bkardell_: number of issues brought to F2F last year
... but concern about not having enough context
... spec wasn't clear enough
... so filed an issue to explain the context of the MathML proposal
... and how these CSS proposals fit into that context

astearns: Does anyone have questions about the overall projecthere?

iank_: Might be helpful if we get an update for impl in Chromium

<fredw> hi

fredw: Been working on MathML Core Level 1 specification
... try to extract core concepts of MathML to implement in Chromium
... Several things related to styling
... It was difficult to implement without writing CSS
... e.g. want to modify font, interact with font size
... also I think one argument that ian was making
... How implemented in WebKit / Gecko is internal
... not really exposed to users
... nicer to implement in a way that integrates with CSS, so can use CSS to modify
... work in Chromium for MathML, more or less done with the work plan for this year
... Already implemented most of the CSS proposals in Chromium
... Only thing missing is text-transform, due to some controversy
... and the script-level issue
... need to update in response to feedback

bkardell_: worth saying context of meta-issue is that MathML didn't have very good interop
... lot of things that were underdefined, not explained how they fit into the platform
... answers duplicated with CSS solutions
... so as part of work in Chromium, chrome team has been very good at making sure we have necessary answers

iank_: I've been pretty impressed with how things have been going
... principle of using CSS, ability to drop in a grid into a MathML structure, really great to see

astearns: Remaining issues that are linked from this meta-issue are things that are working in Chromium, just looking to standardize?
... or still bits to work out

fredw: More or less implemented in Chromium, but still have some flexibility to change. But it works
... Some of these things are implemented in Gecko as internal CSS properties
... would just need to actually expose them
... WebKit want to do the same

cramped script style

math-oriented display values

github: https://github.com/w3c/csswg-drafts/issues/5385

bkardell_: 2 ways of integrating math into text
... inline style or block style
... proposal is to add display style
... there was a comment in the issue that it should be "inline math" instad of "inline-math"

astearns: It would be a display-inside value

iank_: I think web devs are quite used to 'inline-foo' pattern
... math is an inside display type, but maybe add as an alias

TabAtkins: I agree
... if we were adding a bunch more at once, could maybe make a clean break
... but just one would feel inconsistent
... so would say add inline-math into the table, easy

dholbert: Other places where 'display: contents' is like none?

faceless2: SVG

TabAtkins: various form elements, replaced elements

astearns: So we want ...?

TabAtkins: Add math to <display-inside>, add inline-math to <display-legacy>

iank_: It's basically zero overhead to add inline-math and convenient to authors

astearns: What happens to 'inline-math' on non-MathML elements?

fredw: Would behave like none

faceless2: I thought behaved like mrow

NeilS: Unrecognized elements in MathML context only

<bkardell_> fantasai: generally speaking we try to avoid having things disappear if you do something slightly wrong

<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

astearns: My expectation was behave like 'flow' on non-MathML element
... either inline or block

iank_: If you have div { display: math; }, will effectively create a block flow internally

fredw: create a block node

iank_: would change box tree slightly

fredw: that's also what we do if don't set display: math on math element

<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)

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

fantasai: Ignoring isn't an option, can make it behave as a different value though

RESOLUTION: Add 'math' as a <display-inside> value.

RESOLUTION: Add 'inline-math' as a <display-legacy> value.

RESOLUTION: 'math' outside of MathML context behaves as 'flow'

emilio: Does it behave as or compute to flow?

TabAtkins: whichever is easiest

emilio: compute to is more likely to be easier
... it's what we do for 'display: contents'

RESOLUTION: 'math' outside of MathML context computes to 'flow'

emilio: What if you have a non-MathML element inside a MathML element?

fredw: An element not in MathML namespace?

emilio: document.createElement('div') and append to math element

iank_: should work

emilio: should work how?

fredw: not defined

emilio: should be defined
... SVG just doesn't create boxes for those elements
... if you have a random div in SVG, doesn't do much. Not a fan of this.

NeilS: I thought MathML spec said it would be treated as an mrow?

fredw: non-MathML element, so not in the MathML namespace

NeilS: I thought we'd treat as unknown element, whether in mathml namespace or not

iank_: I don't think you specifically want that
... the way that MathML core is currently specified, we can accept arbitrary elements inside MathML subtree
... all the integration points, because more closely tied to CSS, should just work
... if you have a div inside a mathML mrow or something like that, that should lay out as block

fantasai: Should lay out as block inside, whatever MathML wants to do inside

astearns: Seems need to do something around this, but let's get to other issues in the agenda

<faceless2> In SVG, unknown elements collapse to a <g> normally, or a <tspan> if they're inside a <text>

fantasai: Might make sense if you set div { display: math; } then behave same as unknown mathml namespace element with that, treat as mrow

<TabAtkins> Yup, and <mrow> is the mathml equivalent to a <g> basically

emilio: A bit skeptical that that works
... if you put a float inside mathml?

iank_: Like flex/grid, it blockifies.
... doesn't float

emilio: but you need to define these cases.
... how does abspos behave, what's the containing block
... etc.

fredw: tried to write this up in the spec

astearns: Let's raise issue on spec and come back to it some other day

emilio: I don't think these are obscure cases.

text-transform values for MathML

github: https://github.com/w3c/csswg-drafts/issues/5386

bkardell_: MathML created and exists with lots of tools/systems that don't have full access to Unicode
... So legacy documents and even things written before that available
... so number of case where the markup itself contains the information that you need in order to understand that this character that we want to render isn't the literal text value of the element
... text-transforms were the solutions that we used
... because that's what needs to happen
... didn't see any reason to make that specifically hidden or unavailable to users
... I know fantasai and Florian had raised some concerns last time
... we've talked a bunch since then
... fantasai has updated the meta-advice in css-text-3 to provide some nuance
... the meaning *is* in the document
... I don't know if ppl still object to these or what

fredw: 2 separate cases
... case of math-auto, which is automatic italic
... and this is the most important one
... Not adding any semantics
... default var rendered as italic
... the other was strings for tools/documents not using Unicode
... we are using text-transform to do the transformation even if MathML says to preserve the semantic
... maybe a bit controversial
... Florian was saying it's OK as long as we have the mathvariant attribute in the markup
... if ppl really don't like, can only add math-auto one
... might break some back compat, might need a polyfill, but...

NeilS: could be done internally and not break anything
... My concern is a11y, will changed character be in the a11y tree

bkardell_: had several ppl who implement screenreaders saying that the transform value is exposed on existing ones, and that was a sticking point because we don't always want that
... certainly we can go either way here
... either it will be, or it won't be, exposed to screenreaders

NeilS: As long as exposed to screenreaders, then no a11y issue

<faceless2> +1 to Neils comment

bkardell_: There's a specific example in the issue itself
... to non-Math ppl like myself, not intuitive

emilio: Proposal of math-auto
... is it like user-select, like auto behaves as inherit or something?
... it's not clear to me
... seems like pseudo-code that Rob posted would be computed value time which is a bit odd

fredw: basically transformation, whether italic or not [...]
... it doesn't compute to italic

iank_: would it be fair to say that you'd apply to ...

fredw: only to mi element
... mi { text-transform: math-auto }
... Takes effect when only one letter
... don't think it can be computed

iank_: the specific variant is based on the attribute on the mi element?

bkardell_: in the example or in general?
... mi is special, because it has this idea of a single-letter identifier
... those are treated stylistically a certain way
... but that's only stylistic, no meaning
... but math-variant is where you provide additional semantics missing from your lack of character support

iank_: so if you have mathvariant specified, it turns off that auto text-transform behavior?

faceless2: mathvariant is acting as a preshint
... but math-auto, if no other math-transform is set
... it would be italicized if it was one letter

iank_: so also have all the other math transform values

fredw: can override the default behavior

iank_: so it's for this leaf to do this slight magical behavior

NeilS: I think math-auto is really presentation
... Others are there for legacy issue, and not presentation, should actually map to a different character
... that's why may not be appropriate for CSS

<bkardell_> fantasai: I guess I have 1 question and 1 concern...

<bkardell_> fantasai: does the auto italic thing be a text transform really, or does it really just want font styling?

<bkardell_> fredw: the way math fonts are designed, you do

<bkardell_> fantasai: the other ones you do want to be a semantic effect. I am a little uncomfortable with this.

<bkardell_> fantasai: whatever screen readers do it's intention was clear and I don't love changing that

astearns: if this is only way to get semantics for legacy stuff, do we really want to expose it to CSS so that it can be used on new things?

bkardell_: MathML Core 1 is a pretty minimal subset, there are lots of things that use more elements than we're including
... and the intent is for mathml to have a healthy future with additional levels
... so will be unknown elements
... so weird to say you don't have access to the magic to make other elements work like L1

iank_: broadly agree with that
... also from what we've heard from screenreader developers
... this sort of text-transform is only presentation
... that ship sailed a long time ago

bkardell_: it's not that they couldn't be that
... the new one has to be

iank_: text-transform: uppercase is definitely exposed to screenreaders

NeilS: Another case we haven't resolved yet
... is hyphen-minus
... vs minus
... They're defined to be equivalents
... it should map hyphen-minus to U+2122 MINUS
... Could imagine that text-transform would be the way to do this as well

<bkardell_> fantasai: you could go either way with that one

faceless2: You'd also struggle to do that with text-transform
... apply to whole document, then declaration for e.g. fraktur would override and disable

bkardell_: I suggest we either resolve or move on

fredw: maybe just resolve on math-auto, and unsure for rest

astearns: I think I heard you say that math-auto is the only one you have implemented so far?

bkardell_: upstream chromium

fredw: we have the others implemented in a separate branch

astearns: so let's resolve on math-auto
... any objections to adding math-auto to text-transform?

emilio: Not quite objection, but want to clarify how it behaves exactly

astearns: resolve to add, then work on details

RESOLUTION: Add math-auto to text-transform

astearns: still seems like there's concerns around the rest of math-values

faceless2: The only concerns are wrt exposing to screenreaders?

astearns: there seem to be a lot of them, also, that's my concern

fantasai: I don't like adding things that are supposed to alter semantics to CSS.

astearns: let's hold off on these for now

fantasai: ...

iank_: would it be possible to add a new HTML-level attribute with mathvariant and then, if you set `text-transform` to auto that'll read the attribute and apply it?
... Semantics would still be in the document, just whether you apply it would be in CSS

NeilS: I don't think it makes sense to add something new
... this is all for legacy support

bkardell_: maybe talk about that, maybe at HTML layer we can do something

NeilS: I have to drop off for another MathML meeting

math style

github: https://github.com/w3c/csswg-drafts/issues/5387

NeilS: 2 ways of displaying math, one tries to minimize height to fit in lines better
... one is taller one
... shifts positions / sizing rules, etc.
... Designed so you don't have as much gap in lines if you have math in it
... rules defined in TeXBook

astearns: the switch is true or false for displaystyle?
... I like normal and compact much better

iank_: Makes sense, but seems to also be able to affect the font size?
... that will need to be carefully defined

NeilS: That effect is through the scriptlevel feature

fantasai: Affects the font size, indirectly through another property

iank_: Happy to add, pending scriptlevel discussion

astearns: ok, any concerns to add?
... would it go into display module?

iank_: Goes into MathML Core

RESOLUTION: Add math-style: normal | compact

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/copute/compute/
Default Present: dholbert, fantasai, faceless, bkardell_, emilio, NeilS
Present: dholbert fantasai faceless bkardell_ emilio NeilS faceless2
No ScribeNick specified.  Guessing ScribeNick: fantasai
Inferring Scribes: fantasai

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: 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.)