W3C home > Mailing lists > Public > www-style@w3.org > September 2020

[CSSWG] Minutes Math Telecon 2020-09-10 [css-display] [css-text] [math]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 11 Sep 2020 08:33:05 -0400
Message-ID: <CADhPm3v0Sd8+8xbWzx8_PzG7C+mmiJfddhRG8Hfp+sNra=qOCQ@mail.gmail.com>
To: www-style@w3.org
Cc: public-mathml4@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Meta: MathML - CSS Integration

  - Issue #5384 (MathML Core related CSS) provides a meta summary of
      what the team is trying to achieve with the MathML specification.
  - Much of this work has been done in Chromium and is ready to be
      reviewed and altered based on author feedback. Both Gecko and
      WebKit have some done as well behind flags.

CSS Display

  - RESOLVED: Add 'math' as a <display-inside> value. (Issue #5385:
  - RESOLVED: Add 'inline-math' as a <display-legacy> value. (Issue
  - RESOLVED: 'math' outside of MathML context behaves as 'flow'
              (Issue #5385)
  - RESOLVED: 'math' outside of MathML context computes to 'flow'
              (Issue #5385)
  - A separate issue will be filed to discuss how to handle a
      non-MathML element inside a MathML element.

CSS Text

  - RESOLVED: Add 'math-auto' to text-transform (Issue #5386:
              text-transform values for MathML)
  - There wasn't agreement on the other text-transform values based on
      some concerns about both the quantity of new values and how they
      will interact with screenreaders. Discussion will continue on


  - RESOLVED: Add math-style: normal | compact (Issue #5387: math
              style (minimizing logical height of an equation))


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0004.html

  Tab Atkins
  Mike Bremford
  Emilio Cobos Álvarez
  Elika Etemad
  Daniel Holbert
  Brian Kardell
  Ian Kilpatrick
  Neil Soiffer
  Alan Stearns
  Frédéric Wang

Scribe: fantasai
Scribe's Scribe: bkardell

MathML/CSS Meeting
= = = = = = = = = =

Meta: MathML - CSS Integration
  github: https://github.com/w3c/csswg-drafts/issues/5384

  astearns: First item was meta-issue by bkardell
  bkardell: Number of issues brought to F2F last year
  bkardell: but concern about not having enough context
  bkardell: Spec wasn't clear enough
  bkardell: so filed an issue to explain the context of the MathML
  bkardell: and how these CSS proposals fit into that context

  astearns: Does anyone have questions about the overall project there?
  iank: Might be helpful if we get an update for impl in Chromium

  fredw: Been working on MathML Core Level 1 specification
  fredw: to try to extract core concepts of MathML to implement in
  fredw: Several things related to styling
  fredw: It was difficult to implement without writing CSS
  fredw: e.g. want to modify font, interact with font size
  fredw: also I think one argument that iank was making
  fredw: How implemented in WebKit / Gecko is internal
  fredw: not really exposed to users
  fredw: Nicer to implement in a way that integrates with CSS, so can
         use CSS to modify
  fredw: Work in Chromium for MathML, more or less done with the work
         plan for this year
  fredw: Already implemented most of the CSS proposals in Chromium
  fredw: Only thing missing is text-transform, due to some controversy
  fredw: and the script-level issue
  fredw: Need to update in response to feedback
  bkardell: Worth saying context of meta-issue is that MathML didn't
            have very good interop
  bkardell: A lot of things that were under-defined, not explained how
            they fit into the platform
  bkardell: answers duplicated with CSS solutions
  bkardell: 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
  iank: 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
  astearns: or still bits to work out?
  fredw: More or less implemented in Chromium, but still have some
         flexibility to change. But it works
  fredw: Some of these things are implemented in Gecko as internal CSS
  fredw: would just need to actually expose them
  fredw: WebKit want to do the same

CSS Display

math-oriented display values
  github: https://github.com/w3c/csswg-drafts/issues/5385

  bkardell: 2 ways of integrating math into text:
  bkardell: inline style or block style
  bkardell: Proposal is to add display style

  bkardell: There was a comment in the issue that it should be "inline
            math" instead of "inline-math"
  astearns: It would be a display-inside value
  iank: I think web devs are quite used to 'inline-foo' pattern
  iank: Math is an inside display type, but maybe add as an alias
  TabAtkins: I agree
  TabAtkins: If we were adding a bunch more at once, could maybe make
             a clean break
  TabAtkins: but just one would feel inconsistent
  TabAtkins: 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
  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
  fantasai: Generally speaking we try to avoid having things disappear
            if you do something slightly wrong
  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 couldn't think of another
            way, but that isn't a good pattern
  astearns: My expectation was behave like 'flow' on non-MathML element
  astearns: 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
  <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

  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'

  emilio: Does it behave as or compute to flow?
  TabAtkins: Whichever is easiest
  emilio: Compute to flow is more likely to be easier
  emilio: It's what we do for 'display: contents'

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

  emilio: What if you have a non-MathML element inside a MathML
  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
  emilio: SVG just doesn't create boxes for those elements
  emilio: 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
  iank: The way that MathML core is currently specified, we can accept
        arbitrary elements inside MathML subtree
  iank: All the integration points, because more closely tied to CSS,
        should just work
  iank: 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>
  <TabAtkins> Yup, and <mrow> is the MathML equivalent to a <g>
  fantasai: Might make sense if you set div { display: math; } then
            behave same as unknown MathML namespace element with that,
            treat as mrow
  emilio: A bit skeptical that that works
  emilio: if you put a float inside MathML?
  iank: Like flex/grid, it blockifies.
  iank: Doesn't float
  emilio: But you need to define these cases.
  emilio: How does abspos behave, what's the containing block
  emilio: etc.
  fredw: Tried to write this up in the spec
  astearns: Let's raise issue on spec and come back to it some other
  emilio: I don't think these are obscure cases.

CSS Text

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
  bkardell: So legacy documents and even things written before that
  bkardell: 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
  bkardell: text-transforms were the solutions that we used
  bkardell: because that's what needs to happen
  bkardell: Didn't see any reason to make that specifically hidden or
            unavailable to users
  bkardell: I know fantasai and Florian had raised some concerns last
  bkardell: we've talked a bunch since then
  bkardell: fantasai has updated the meta-advice in css-text-3 to
            provide some nuance
  bkardell: The meaning *is* in the document
  bkardell: I don't know if people still object to these or what

  fredw: 2 separate cases
  fredw: Case of math-auto, which is automatic italic
  fredw: and this is the most important one
  fredw: Not adding any semantics
  fredw: default var rendered as italic
  fredw: The other was strings for tools/documents not using Unicode
  fredw: We are using text-transform to do the transformation even if
         MathML says to preserve the semantic
  fredw: maybe a bit controversial
  fredw: Florian was saying it's OK as long as we have the mathvariant
         attribute in the markup
  fredw: If people really don't like, can only add math-auto one
  fredw: Might break some back compat, might need a polyfill, but...
  NeilS: Could be done internally and not break anything
  NeilS: My concern is a11y, will changed character be in the a11y tree
  bkardell: Had several people 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
  bkardell: Certainly we can go either way here
  bkardell: 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
  bkardell: to non-Math people like myself, not intuitive
  emilio: Proposal of math-auto
  emilio: is it is like user-select, like auto behaves as inherit or
  emilio: It's not clear to me
  emilio: Seems like pseudo-code that Rob posted would be computed
          value time which is a bit odd
  fredw: Basically transformation, whether italic or not [...]
  fredw: it doesn't compute to italic
  iank: Would it be fair to say that you'd apply to ...
  fredw: Only to mi element
  fredw: mi { text-transform: math-auto }
  fredw: Takes effect when only one letter
  fredw: Don't think it can be computed
  iank: The specific variant is based on the attribute on the mi
  bkardell: In the example or in general?
  bkardell: mi is special, because it has this idea of a single-letter
  bkardell: Those are treated stylistically a certain way
  bkardell: but that's only stylistic, no meaning
  bkardell: 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
  faceless2: but math-auto, if no other math-transform is set
  faceless2: 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
  NeilS: Others are there for legacy issue, and not presentation,
         should actually map to a different character
  NeilS: That's why may not be appropriate for CSS

  fantasai: I guess I have 1 question and 1 concern...
  fantasai: Does the auto italic thing be a text transform really, or
            does it really just want font styling?
  fredw: The way math fonts are designed, you do
  fantasai: The other ones you do want to be a semantic effect. I am a
            little uncomfortable with this.
  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
  bkardell: and the intent is for MathML to have a healthy future with
            additional levels
  bkardell: so will be unknown elements
  bkardell: So weird to say you don't have access to the magic to make
            other elements work like L1
  iank: Broadly agree with that
  iank: Also from what we've heard from screenreader developers
  iank: this sort of text-transform is only presentation
  iank: That ship sailed a long time ago
  bkardell: It's not that they couldn't be that
  bkardell: the new one has to be
  iank: text-transform: uppercase is definitely exposed to

  NeilS: Another case we haven't resolved yet
  NeilS: is hyphen-minus
  NeilS: vs minus
  NeilS: They're defined to be equivalents
  NeilS: it should map hyphen-minus to U+2122 MINUS
  NeilS: Could imagine that text-transform would be the way to do this
         as well
  fantasai: You could go either way with that one
  faceless2: You'd also struggle to do that with text-transform
  faceless2: 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
  astearns: Any objections to adding math-auto to text-transform?
  emilio: Not quite objection, but want to clarify how it behaves
  astearns: Resolve to add, then work on details

  RESOLVED: Add math-auto to text-transform

  astearns: Still seems like there's concerns around the rest of
  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?
  iank: 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
  NeilS: this is all for legacy support
  bkardell: Maybe talk about that, maybe at HTML layer we can do
  NeilS: I have to drop off for another MathML meeting


math style (minimizing logical height of an equation)
  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
  NeilS: One is taller one
  NeilS: shifts positions / sizing rules, etc.
  NeilS: Designed so you don't have as much gap in lines if you have
         math in it
  NeilS: Rules defined in TeXBook
  astearns: The switch is true or false for display style?
  astearns: I like normal and compact much better
  iank: Makes sense, but seems to also be able to affect the font size?
  iank: 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?
  astearns: Would it go into display module?
  iank: Goes into MathML Core

  RESOLVED: Add math-style: normal | compact
Received on Friday, 11 September 2020 12:33:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 11 September 2020 12:33:52 UTC