- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 11 Sep 2020 08:33:05 -0400
- 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:
math/inline-math)
- RESOLVED: Add 'inline-math' as a <display-legacy> value. (Issue
#5385)
- 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
github.
Math
----
- RESOLVED: Add math-style: normal | compact (Issue #5387: math
style (minimizing logical height of an equation))
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0004.html
Present:
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
proposal
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
Chromium
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
standardize?
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
properties
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
<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
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
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
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
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
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>
basically
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
day
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
available
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
time
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
something?
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
element?
bkardell: In the example or in general?
bkardell: mi is special, because it has this idea of a single-letter
identifier
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
screenreaders
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
exactly
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
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?
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
something
NeilS: I have to drop off for another MathML meeting
Math
====
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