# Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

## Re: Sharing MathML data for Firefox

Source: www-math@w3.org Mail Archives • Gunter Königsmann (gunter@peterpall.de) • August 22, 2019 • Permalink

Currently much Math is expressed as TeX+mathJaX, as things like Equation Labels tend not to work in MathML+MathJaX as a fill-in.  Which is a pity, given that the latter possibility is faster. Which means we can scan for MathML, but not for website admins that almost switched to it and therefore only measure part of the need this world has for MathML.

Kind regards,

Gunter.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


## Re: Sharing MathML data for Firefox

Source: www-math@w3.org Mail Archives • Hammond, William F (whammond@albany.edu) • August 22, 2019 • Permalink

I assume this is about MathML elements such as "mfenced" that previously you have expressed a wish to drop.  I continue to advise you not to take any such step.  That said, I have questions:

Will your probe pick up instances where MathJax ("CommonHTML") rendering of MathML is used?

Will your probe pick up instances served as "application/xhtml+xml"?  I mention this case because some web searching algorithms seem often to have bypassed it.

-- Bill

________________________________
From: Frédéric Wang <fwang@igalia.com>
Sent: Thursday, August 22, 2019 11:24 AM
To: public-mathml4@w3.org <public-mathml4@w3.org>
Cc: www-math@w3.org <www-math@w3.org>; Mozilla Math Developers <dev-tech-mathml@lists.mozilla.org>
Subject: Sharing MathML data for Firefox

Hi everybody,

In [1], Emilio has re-enabled MathML telemetry on all Firefox channels.
Currently we only have one probe measuring the number of top-level
documents containing MathML [2]. However, we plan to add more probes for
legacy MathML 3 features soon in order to complement the survey [3] and
decide whether we can remove them from MathML Core and unship them from
Firefox.

If you are a Firefox user and want to participate to this data
collection, then please make sure you checked the option

"Allow Firefox to send technical and interaction data to Mozilla"

MathML folks in order to maximize the measured population and make the
data more accurate/useful.

Thanks,

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1538985
[2]
https://telemetry.mozilla.org/probe-dictionary/?detailView=scalar%2Fmathml.doc_count
[3] https://github.com/mathml-refresh/mathml/issues/55

--
Frédéric Wang


## Sharing MathML data for Firefox

Source: www-math@w3.org Mail Archives • Frédéric Wang (fwang@igalia.com) • August 22, 2019 • Permalink

Hi everybody,

In [1], Emilio has re-enabled MathML telemetry on all Firefox channels.
Currently we only have one probe measuring the number of top-level
documents containing MathML [2]. However, we plan to add more probes for
legacy MathML 3 features soon in order to complement the survey [3] and
decide whether we can remove them from MathML Core and unship them from
Firefox.

If you are a Firefox user and want to participate to this data
collection, then please make sure you checked the option

"Allow Firefox to send technical and interaction data to Mozilla"

MathML folks in order to maximize the measured population and make the
data more accurate/useful.

Thanks,

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1538985
[2]
https://telemetry.mozilla.org/probe-dictionary/?detailView=scalar%2Fmathml.doc_count
[3] https://github.com/mathml-refresh/mathml/issues/55

--
Frédéric Wang


## [CSSWG] Minutes Toronto F2F 2019-06-06 Part III: Grid, Fonts, SVG, Media Queries & CSS Sizing [css-grid] [css-fonts] [mediaqueries] [css-sizing]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • July 11, 2019 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

CSS Grid
--------

- RESOLVED: Add Oriol as an editor

CSS Fonts
---------

- Dynamic text size (Issue #3708) is a proposal to respect user's
font sizes without arbitrarily overriding website styles and is
based partly on -apple-system-font
- Generally there was support to keep investigating this proposal
and refine the recommendations
- The biggest concern was that this setting may not be used much and
therefore sites won't test against it, however no one at the
meeting had usage data to either validate or resolve this
concern.
- Another concern is that this is just adding another way to do font
sizing when there are already so many guides, some of which are
outdated but still referenced. The hope is that this change
would be a new way to level set font sizing rather than piling
on just another setting.
- Work will continue on investigating and improving this proposal
before the group is asked for a resolution.

SVG
---

- RESOLVED: SVG spec says that <foreignObject> creates a containing
block for fixpos and abspos children (FXTF Issue #307)
- The group felt issue #245 (Disabling masks/clip paths when
display:none) likely is not worth special casing. Additionally,
new browser interop testing needed to be done.
- Issue #249 (Clarify how userSpaceOnUse and objectBoundingBox apply
to non-SVG elements) needs additional review to decide between
multiple proposals.

Media Queries & CSS Sizing
--------------------------

- RESOLVED: Change <integer> to <number> in the aspect-ratio (Issue
#3757: Support <number> (and therefore calc) as a
<ratio>)
- RESOLVED: Allow <number> and <number>/<number> both for
<aspect-ratio> (Issue #3757)

- There's still not interest to implement the else conditional, but
the proposal originally drafted will be linked into the draft to
continue discussion

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/toronto-2019

Scribe: TabAtkins
Scribe's Scribe: dbaron

CSS Grid
========

------------------------

RESOLVED: YES

CSS Fonts
=========

Dynamic text size
-----------------
github: https://github.com/w3c/csswg-drafts/issues/3708

AmeliaBR: Want to be able to respect user's font sizes, especially
on mobile, without arbitrarily overriding website styles
in ways that break pages
AmeliaBR: Want good pages to be able to opt into user's prefs at the
OS level.
AmeliaBR: I brought it up because in the issue's long discussion
there were some straightforward proposals.
AmeliaBR: One was a new "system-font" keyword (for 'font' shorthand)
AmeliaBR: WebKit has a keyword for that
AmeliaBR: Suggestion is to standardize that after agreeing on the
shorthand keyword
AmeliaBR: Already have font-family keyword that is system-ui,
waiting for FF impl, but in two browsers and in spec
AmeliaBR: Different for 'font' keyword is you'd also get default
sizing
AmeliaBR: Second, trickier aspect is what if an author wants to opt
into the user's font size without getting the system font.
AmeliaBR: My argument is that's what "medium" was supposed to be.
AmeliaBR: Might get messy, maybe we can talk about that.

myles: Some context:
myles: Browsers have 11k ways to adjust text sizes
myles: All area balance between making text readable and trying to
not break layout
myles: Having a website opt in and say "I know this part of the page
will respond well" won't fix every site, but will at least
let us resize that part more freely.
myles: General request is really important for a11y.
myles: (and just people like to change their font size)
myles: Every OS has this, ebook readers too.
myles: So I'm just hoping for some way for a website to say "for
this part of the page, go hogwild"
myles: We have a non-standard prefixed mechanism for this
myles: Would be cool to resolve on that, but we're not married to it
myles: Another idea is to use env()
myles: Interesting on iOS which lets you change both size *and*
weight
myles: I don't wanna prescribe any specific solutions, but would be
cool to come up with something for this.
myles: Our existing solution is a 'font' keyword
myles: You can say "font: -apple-system-body"
myles: It'll resolve to a specific size, so if you want your page to
react fluidly as the user slides their font-size slider, you
put that value on the root element and let the inherited
style work correctly
<AmeliaBR> Proposal is to add a system-body keyword for the font
shorthand. Sets the font-family and size together.
koji: I don't have a preference for solution, but I'm hearing the
koji: Would be great to standardize

dbaron: Presumably there's some default size for this keyword.
dbaron: What percentage of users have it at this default size?
dbaron: My concern is that if it's over, say, 75% or more, pages
will likely still not work if it changes.
myles: Dunno
AmeliaBR: The whole point of this is to not change anything by
default
AmeliaBR: Webpages have to opt into it
AmeliaBR: So your concern is that they might opt in thinking they're
getting a standard default, and not realize it's
dbaron: My concern is that things that don't get tested get broken.
If it's only true for a small percentage, it won't get
tested, and even if original design got it right, someone
will come along later and make it break for a non-default
size.
dbaron: Just like before we made px be a 96:1 ratio with in. Users
with a different ratio, only in Firefox and IE, saw broken
websites.

myles: Can't answer directly, but can offer some info
myles: In our experience, this isn't just a11y. Many users change
just because they like bigger text sizes
TabAtkins: It sounds like from your suggestion from using
-apple-system-body on the root and then using rems or
inheritance
TabAtkins: does address Amelia's request to just get the font size
people want?
myles: Yes
TabAtkins: It sounds like from your response to david that there's a
decent percentage changing to a non-default value?
myles: Yes

jensimmons: Is what's being proposed only affecting font-size? Or is
there an easy way to cascade that measurement into
layout?
jensimmons: Is it different from just using 'em's, etc?
myles: This should be a way of setting font-size like any other way
jensimmons: There are many websites that don't do things right, we
have to consider them because they're majority. But this
is an issue been incredibly important to front-end
designers/teachers: make a webpage work when people
choose their font size.
jensimmons: These days the only thing left to understand is how to
zoom on desktop
jensimmons: Best practice has changed many times over the years.
jensimmons: A bit of tail-chasing, browsers trying to chase
badly-written sites, and good sites chasing browsers,
and round and round.
jensimmons: And because info about best practice ages, people don't
realize it's old; like people still say "set font-size
on root to 10px and use 'rem'"
jensimmons: So this comes down to, have an easy way to let users
change font size and have an easy way to adapt to it.
jensimmons: So I just want this to fit into that evolutionary
conversation.
jensimmons: Rather than YetAnotherWayToDoIt
myles: Agree 100%
myles: My intention isn't to make a new blessed way to design
responsive websites
myles: More allow authors to annotate their source with some info we
don't already have, and that annotation is "this part of the
page works well when font-size changes"
florian: I think this new proposal has a chance of breaking the
cycle, precisely because this setting is used by a large
number of people. It's always existed, but tended to be
used by few.
florian: Like dbaron said, when too few people use it, things break.
florian: But because this is used by many, there's a chance it'll
stay viable, rather than being poisoned by maintenance.
jensimmons: The idea we should take the preference setting and give
it to webdevs to use, I'm definitely for it.

chris: I noticed in the thread that someone suggested there should
be a property that is system-font-size * browser font scale
chris: I'm not opposed to a new generic font family, but if people
are using that purely to get at the size, that seems more
robust to me.
<chris> "the property in question should be SYSTEM_FONT_SIZE *
BROWSER_FONT_SCALE. On iOS and Android, BROWSER_FONT_SIZE
would likely always be 100% with SYSTEM_FONT_SIZE being
variable. But on Mac OS X, it would be the opposite. Windows
would likely support both. "
chris: To get the size directly, rather than using the whole font
just to get the size

AmeliaBR: There's content out now that's UA-dependent, trying to
recreate the system body font.
AmeliaBR: (which I find annoying, as I don't like Window's system
font...)
AmeliaBR: But a keyword would be smarter than the website trying to
*guess* that I want Seguo UI.
AmeliaBR: So I think there's a demand for combined, but we should
also do apart. But Tab did say that if we have the font
keyword on root, we can just use 'rem's.
AmeliaBR: But I would prefer "font-size: medium" to do actually
that, but...
chris: You ran some tests; we saw that browser didn't do that.
myles: We've tried to make "medium" reflect preferred size. It
breaks too much, can't do it.

astearns: Why is this a keyword on 'font' rather than a keyword for
font-size?
myles: There's a collection of 'font' keywords.
myles: This one means "this is the size that best fits apple body
text"
myles: Now that we have system-ui generic font family distinct from
that, I think the use-case is [...?]
astearns: So system-ui is on font-family, not 'font'?
myles: Yes.
<chris> so I guess it sets the line spacing too

heycam: You answered "Why is this just not the default". What
specifically did you try? Did you try switching "medium" and
leaving the initial font-size to 16px, did you try changing
initial and leaving "medium", or?
myles: The latter
heycam: What actual font-family is set by this? Same initial value
that kinda depends on lang and so on? Or always serif?
myles: The system font, "San Francisco" on Apple
TabAtkins: So it's the system-ui font?
myles: Yes
AmeliaBR: system-ui is a new generic, an alternative to 'serif' or
'sans-serif'

jensimmons: If your CSS you use to react to different preferences is
different on mobile than desktop, that's bad. Is it?
myles: Android and iOS both have this setting, windows desktop has
this setting. Don't think it would differ.
jensimmons: [missed]
jensimmons: If this is something you're supposed to use, but it only
works in some browsers, that's a problem.
AmeliaBR: So your concern is that browsers with an in-browser
font-size option, the system font being pulled from
outside the browser wouldn't match?
myles: Does "work" mean that it draws from the OS? That can be done
on every platform. Or does it mean some devices on a platform
will have one value and other devices on that platform will
have others?
AmeliaBR: So should the value come from browser, or browser+OS, or
what?
<heycam> preferred-font-size:no-preference
TabAtkins: I don't think there's any reasonable use-case for "OS
size" different from "browser-provided default size"
chris: I wasn't suggesting two vars, I was suggesting a single thing
from multiplying those together.

myles: So I think we have consensus for a font-size env()?
myles: Also, since we expose weight, do we want an env() for weight?
<AmeliaBR> So, to get the effect of the -apple-system-body keyword
would be font: env(preferred-font-size) system-ui;
TabAtkins: Sounds okay, but slightly concerned due to dbaron's

emilio: Firefox's font settings are per-lang, so I'm not sure how to
distill that to an env() value
emilio: And to get the opposite would be font: -apple-system-body;
font-family: foo;
astearns: I don't like the default weight; the page would lose the
the distinction between bold and not.
myles: Yeah, they're asking for that.
astearns: They're asking for it in system UI, which doesn't use much
bold. Not necessarily in web content.
TabAtkins: Does Apple system ui tend to use bold to distinguish
stuff, such that the default weight would lose
information?
myles: There's some, but it's rare, so not much info is lost.

astearns: So emilio, if you had an env(), you'd have to pick which
size to use based on lang, etc.
astearns: But you have to make the same decision for the keyword,
right?
emilio: Different. You'd have the element language, you'd apply the
generic family.
TabAtkins: So you're saying that the font keyword, being resolved on
the element, can be different per-element based on lang?
But the env(), which should be global, can't do that?
emilio: Yes.
AmeliaBR: "medium" on Chrome and Firefox currently resolves to user
font size.
emilio: Right, so I guess an env() font-size for that would be okay.

koji: I'm confused. This is about exposing system font size setting
not user's setting in browsers, right?
koji: But windows/mac/etc all expose only a single value
emilio: That makes sense.
AmeliaBR: The idea is that the exposed variable is the setting in
the browser, if they capture that, or OS otherwise
fantasai: A problem with "medium" is that it can't reflect user
setting
TabAtkins: Myles did tests for the *initial value* being user's
setting, and that broke stuff. But Chrome/Firefox reflect
"medium" being the user's setting.
AmeliaBR: But that's the same thing, as "medium" is the initial
value.

myles: So I think this topic is an investigation, we're not going to
finish right now.
astearns: But I think the room has a general intent that this is a
good idea.
AmeliaBR: If people have data for what percentage of users change
their default font size, or how much breakage is observed
when things change, this would be useful info in the issue.

SVG
===

SVG container elements
----------------------
github: https://github.com/w3c/fxtf-drafts/issues/307

AmeliaBR: Filters create a containing block for abspos/fixpos
AmeliaBR: When specified nobody thought about SVG, because it
doesn't have abspos.
AmeliaBR: But you can do a foreignContent with html that uses abpos.
dbaron wondered what happens there.
AmeliaBR: Looking at browsers, they're non-interop.
AmeliaBR: In discussion, consensus seems to be that the
foreignObject is a containing block for abspos/fixpos, so
you don't have to worry about whether an ancestor svg
element has a filter or not.
AmeliaBR: That's what Chrome does
AmeliaBR: So we need to specify foreignObject better in general
about how it provides a containing block for css content
inside of it, and making this dfn makes things simpler,
but it does add a new place where we're trapping fixpos
elements.
astearns: chrishtr says that the SVG spec already defines that
foreignObject defines a fixpos containing block
AmeliaBR: Maybe
<bkardell> is this totally related?
https://github.com/mathml-refresh/mathml/issues/48

mstange: I think all browsers already agree on this
mstange: The difference Amelia found might be an old version of
chrome; I think browsers now agree
mstange: I think having foreignObject be a containing block for
everything makes a lot of sense
AmeliaBR: Weird ones that don't match are Safari: <foreignObject>
contains fixedpos but not abspos. stickypos is a big
untested mess too
mstange: We may want to add something about sticky to the spec, then?
iank: Maybe better as a separate issue
dbaron: I don't think anything special needs to happen with sticky,
because I don't think it escapes very far
AmeliaBR: I think the definition of what happens with it will fall
out of defining it as a containing block
emilio: sticky is about scroll containers, not containing block

astearns: So what needs to be done here?
dbaron: Larger answer is that we need a spec to centralize a bunch
of this
dbaron: Part of reason for all these questions about CBs and
stacking contexts, etc are such a mess is that there are
multiple specs amending dfns that don't actually exist.
dbaron: So someone needs to write a spec that defines these terms.
dbaron: So opacity/mix-blend-mode/etc can all hook that instead of
dbaron: Simple thing is to resolve that <foreignObject> establishes
a containing block for abpos and fixpos
flackr: I think sticky says it moves according to the nearest
ancestor with non-visible overflow
dbaron: Can <foreignObject> overflow...?
AmeliaBR: Haven't tested
AmeliaBR: I think it overflows, I've done it to get a <label>.

astearns: Let's resolve on abpos/fixpos and do sticky separately?
chris: Rossen wanted it to be an ICB...?
hober: Without him explaining why, I'm loathe to define that
iank: Yeah, ICB has a lot of other implications.
AmeliaBR: I can take action on edits
TabAtkins: Ping me and fantasai for review
astearns: proposed resolution: svg spec says that <foreignObject>
creates a containing block for fixpos and abspos children

RESOLVED: svg spec says that <foreignObject> creates a containing
block for fixpos and abspos children

--------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/245

AmeliaBR: I don't expect a resolution here. SVG call discussed it,
we decided we needed detailed testing for browser interop
AmeliaBR: What browsers are doing doesn't match long-standing SVG
text tho
AmeliaBR: This is about SVG elements that are never rendered:
AmeliaBR: In SVG1, these all had an opaque paragraph that said
"display doesn't apply to these elements, no matter what
you say it won't be rendered, and no matter what you say
they'll always be usable"
AmeliaBR: For SVG2, I was working on trying to make <use>-element
AmeliaBR: To make <symbol> not work directly, but work if you render
it in which case 'display' does apply
AmeliaBR: Figured I could replace that prose with a UA stylesheet
using !important to mean authors can't change 'display'.
AmeliaBR: So say "display:none; except for <symbol> that is a direct
child of a <use> shadow tree"
AmeliaBR: But turns out that in browsers, display:none *does* do
something
AmeliaBR: In most browsers, if you set <mask style=display:none>, it
has no effect on elements using it as a mask
AmeliaBR: This isn't in specs but happens in multiple browsers.

dbaron: Interesting is whether the element has display:none *and*
whether ancestor has it
dbaron: Tied to "is the thing that makes these work the presence of
their DOM node, or the presence of boxes they create"
dbaron: For many browsers, these live in the box tree, and using
them links to the box tree, and display:none means no boxes
are generated and they fail
dbaron: So question is if that's what we want to do
dbaron: So in general display:none and ancestor display:none are not
distinguishable
dbaron: So using a non-none !important value doesn't work, as it
doesn't solve the ancestor problem

hober: Do we need to special-case these at all? In HTML <style>
defaults to display:none, but you can display:block it to
render it.
hober: So who cares?
dbaron: I think at this point that's not backwards compatible
chris: Used to be that you couldn't display <title> no matter what
you did. But now you can.
AmeliaBR: I don't know how much will break, I didn't know that
browsers were doing it anyway.
AmeliaBR: I suppose it could be useful sometimes to disable a
clip-path by setting one thing on the <clipPath> rather
than changing all the uses...
AmeliaBR: Practical case it breaks. Lots of inline SVGs using a
gradient, so you have an inline SVG somewhere that defines
those gradients. You don't want it to draw, so can you
tell that SVG display:none?
AmeliaBR: Some browsers you can, some you can't, because of what
dbaron mentioned earlier.
AmeliaBR: So instead you throw a pile of styles at it to make it
visually hidden but not display:none
* bkardell still thinks there should just be a visually-hidden class
or even just attr with that class in the UA sheet

emilio: Is part of the reason it depends on the box tree-- we have a
special thing for SVG that says "this frame is non-display"
that doesn't do anything on its own
emilio: What that gets you is that a lot of elements don't generate
a box at all when they're invalid markup - not in an SVG
parent or whatever.
emilio: You need to make all those checks in two places now

AmeliaBR: So if anyone wants to help us build up that
interop-testing table, that would be very helpful.
astearns: So I think you can take that back to the SVGWG with our
notion that it's probably not worth special-casing, and
maybe impossible.
<dbaron> Is there going to be some attempt to drive towards interop?

Clarify userSpaceOnUse and objectBoundingBox on non-SVG elements
----------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/249

AmeliaBR: Mega issue that affects everything in SVG graphical
effects that we support applying to CSS boxes
AmeliaBR: SVG effects (gradients, patterns, clips) have a switch for
how they're scaled and positioned
AmeliaBR: So when you apply it to a rect, it can either be scaled to
that rect, or to the svg as a whole so a gradient spreads
smoothly across multiple rects, etc.
filters to CSS boxes, it was never defined how they map to
CSS coordinate spaces
AmeliaBR: Actual impls are inconsistent
AmeliaBR: I periodically get bug reports about how this is supposed
to work

TabAtkins: Both anchor position according to CSS coordinate space,
(and some other stuff)
TabAtkins: You at least get consistent sizing, but don't have the
ability to have multiple boxes with views into the same
AmeliaBR: Yes, that's the simplest approach that still has sensible
results
AmeliaBR: So boxes are always the size of the css box
AmeliaBR: And OBB, which assumes the effect is scaled 0->1 gets
that, and USOU gets normal px measurements
AmeliaBR: Other possibility is that you map USOU to the ICB (or
nearest CB). Firefox does one of these, don't remember
which CB.
AmeliaBR: This doesn't match roc's proposal.
AmeliaBR: So can we get more eyeballs on this? It prevents us from
getting a reasonable spec on several of our fxtf specs.

Media Queries & CSS Sizing
==========================
Scribe: fremy

Support <number> (and therefore calc) as a <ratio>
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3757

AmeliaBR: Currently for the aspect-ratio media query we define a
ratio type (integer slash integer)
AmeliaBR: we are thinking about using the same type for the
aspect-ratio property
AmeliaBR: I think we should support decimal in addition to the
fraction
AmeliaBR: so <int>/<int> or <number>
jensimmons: I can see how this looks like a fraction, but I don't
think of it this way
jensimmons: Interested people can look at the history of aspect
ratio in the film industry
jensimmons: There is both 16/9 or 16:9 or 1.77
jensimmons: I don't see us wanting to have 1.77:1
jensimmons: That is confusing
<chris> its a rational number, not a fraction
<chris> https://www.mathsisfun.com/rational-numbers.html

myles: Is it bad that when you actually divide these numbers you get
non-round numbers?
AmeliaBR: yes, this is why we prefer the "fraction-looking"
expression
myles: So we don't want to convert to a number, right?
jensimmons: No, we would keep the other representation
myles: I don't want to have a 1px gap because of people's mental
rounding errors
AmeliaBR: But when authors have numbers they computed themselves in
some other way, we don't want to force them to use a
fraction
heycam: So, if you want to use css variables, you would want to use
calc() right?
myles: Native APIs often expose numerator and denominator as
distinct in those cases
* leaverou wonders why we can't do both? There's no syntactical
ambiguity. <number> | <number>/<number>
<astearns> we are talking about doing both, I think

chris: Come on folks, are we really discussing this?
chris: This is a rational number, we can allow that and other forms
of numbers, this is very common outside of CSS
<chris> The ancient greek mathematician Pythagoras believed that all
numbers were rational, but one of his students Hippasus
proved (using geometry, it is thought) that you could not
write the square root of 2 as a fraction, and so it was
irrational.
<chris> But followers of Pythagoras could not accept the existence
of irrational numbers, and it is said that Hippasus was
drowned at sea as a punishment from the gods

TabAtkins: I think I agree that accepting all <number>s is
reasonable, for the calc() cases
TabAtkins: but I don't think we need to add just plain <number>
because it's nice to have a single consistent syntax
pattern
<dbaron> Tab's proposal (do just change <integer>/<integer> to
<number>/<number>) sounds good to me

leaverou: I don't understand why we can't do both. There is no
syntactical ambiguity.
leaverou: Can't we do both? Why do we want to pick one?
TabAtkins: ok, there is no ambiguity, but it makes the syntax more
complex, I appreciate consistent things
TabAtkins: but you are are right that it's not ambiguous
AmeliaBR: We can wait until we have more authors using this, and
then see if get questions anyway, some will wonder why you
have to write 1.5/1 instead of just 1.5 but ok that's
doable

jensimmons: calc() and variables, can someone explain how that would
work now and with the proposals?
TabAtkins: Today, if you use calc, it would get weird results,
because we only allow integers, so they would be rounded
TabAtkins: so it works in theory, but it's not very practical
TabAtkins: The proposal would allow to have any number, so you can
compute using a ratio of two variables
jensimmons: That sounds reasonable, but there is a very common case
with just a number, I don't see why not adding that as
well
astearns: And that seems common, so I'd plus on that
TabAtkins: I would prefer not to add syntax when it doesn't add
much, but if there is strong demand for this, I could get
convinced

astearns: So, can we resolve to change <int> to <number> for aspect
ratio values?

RESOLVED: change <integer> to <number> in the aspect-ratio

TabAtkins: For the second part, what do implementers think?
dbaron: I think that I cross-multiplied to avoid rounding, but I'm
not sure
dbaron: I considered it because otherwise it's a bit scary if people
might try an equality and rounding is risky then
dbaron: but code has been rewritten since then anyway
dbaron: so I don't know
<chris> people comparing two floats for equality need to learn why
that is never a good idea
* flackr wonders if people would be confused by having to specify
aspect-ratio: calc(16/9)/1 if the /1 is required
astearns: I think we should try to keep the syntax simple, and
revisit if we get requests
hober: But priority of constituency indicates that we should favor
allowing to drop the slash one
astearns: Also, looking at the example emilio pasted in irc, the
slash one looks dumb, so I changed my mind a bit
jensimmons: Also, I don't buy the complexity of having two syntaxes
<myles> <number> | <number> / <number>

astearns: Ok, so let's try to resolve to allow <number> and
<number>/<number> both
dbaron: Well, that constrains syntax a bit, but I'm fine with it
<jensimmons> this is really good. And it’s good to do it now.

RESOLVED: Allow <number> and <number>/<number> both for
<aspect-ratio>

Media Queries
=============

else conditional
----------------
github: https://github.com/w3c/csswg-drafts/issues/112

TabAtkins: heycam wanted to put this on the agenda, and I'd be
interested to know why he brought this up
heycam: I made a proposal and it never got discussed further
<TabAtkins> http://tabatkins.github.io/specs/css-when-else/
TabAtkins: Yeah, I had limited time so I didn't push forward, but if
there is interest I can reprioritize my work
astearns: So, heycam, are you volunteering to implement that?
heycam: No
TabAtkins: In that case, I'd rather leave this in the status of
proposal

fantasai: Could we maybe cross-link the issue in the draft, so this
TabAtkins: Okay, sounds reasonable
TabAtkins: It's not right now, but I can do this
ACTION: Tab to cross-link the issue from the draft

heycam: So, shall we table this discussion for now?
florian: Just wanted to note that also unless everybody is doing it,
it's not useful
myles: Sure, but if one does it and authors finds it useful, others
will follow
TabAtkins: But the point is that right now we don't even have one
promise to implement

astearns: Okay, let's try to do easing timing functions, then take a
break


## [CSSWG] Minutes Toronto F2F 2019-06-05 Part II: CSS Text, CSS Inline [css-text-4] [css-inline]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • July 06, 2019 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

CSS Text (Continued)
--------------------

- Issue #3745 (Add new CSS text-transform values for math) will be
deferred to TPAC when a11y experts can be a part of the
conversation as well as spend time to see if it's possible to
decouple the style and the markup a11y

CSS Inline
----------

- Discussion of issue #3749 (resolved value of line-height) didn't
lead to a resolution but several people had actions to move the
topic forward:
- florian will take some of the edits removed from CSS2.1 during
the clean up of that spec and will add them to the Inline L3
spec.
- emilio will experiment with having Gecko return normal and see
if it causes web compat issues.

===== FULL MINUTES BELOW =======

Agenda: https://wiki.csswg.org/planning/toronto-2019

Scribe: emilio

CSS Text
========

Add new CSS text-transform values for math
------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/3745

fantasai: I really think this should be done with i18n experts
fantasai: probably at tpac
Rossen: Who added it to the agenda?
bkardell: I did
Rossen: Are we ready to discuss this?

bkardell: There were very strong objections when I added it to the
agenda but it seems that has been solved
bkardell: I'd like to make some progress on that issue
astearns: What's the points you're talking about?
bkardell: The philosophy of text-transforms and how it interacts
with a11y
* fantasai agrees with Asmus in
https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-478206009
bkardell: We have a new transform that probably needs to do
something different
bkardell: there are at least two answers to the questions
florian: I think that's why we need other experts on the discussions
florian: because whether text-transform affects the semantics is
complicated
fantasai: I think text-transform, if we're stuck for compat with
a11y for capitalization that's unfortunate, but we
shouldn't introduce the same for math
<fantasai> https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-478206009

florian: Once we have the markup communicate the semantics, we
probably want text-transform to affect some of the
presentation but not a11y
bkardell: My understanding is that we'd encourage putting it in the
markup, but there's a bunch of legacy content which is
what would make this necessary
AmeliaBR: I think florian's point is that you could have a
presentation transform but the accessibility stuff should
be in the markup
bkardell: I'd like to get some kind of checkpoint on this

AmeliaBR: The question is: for math-variant to be exposed and
accessible, does it need to be exposed through
text-transform transforming the text-content, or via an
attribute that gets passed to the a11y tree, which _also_
gets a UA rule to make the presentation change
fantasai: I think that's the right way to go, and gives you the
ability to give more accurate info to a11y than doing
unicode transformation
fantasai: Unicode transformation doesn't contain math semantics
fantasai: that needs to be in the markup, if that information is in
the content it should be given to a11y directly, rather
than via text-transform
fantasai: A11y doesn't say "Bold", it uses the fact that you're on
<strong>
AmeliaBR: Actually that's not true, ARIA WG is trying to introduce
roles for <strong> and similar, authors don't distinguish
<i> or <em>
AmeliaBR: if there's an italic <span> in a header it'd be called out
depending on the verbosity level
Rossen: It calls out format stops

bkardell: There's a similarity here with html's kinda-weak
semantics, a11y tools get mostly plain text with other
hints, for math a11y my understanding is that some tools
use the unicode information
Rossen: We don't support mathml in Edge
bkardell: Well, Edge does parse mathml as XML content
bkardell: which is why mathml is a kinda weird place
Rossen: [describes how a11y works in Edge and how screen readers can
poke at the DOM / render tree in non-Edge (Chromium /
Firefox)]
Rossen: Edge doesn't allow third-party processes in its process

florian: I think this is a topic for TPAC, since different a11y
experts have diverging opinions
Rossen: Are we going to make any progress?
bkardell: Do we have some specific questions?

AmeliaBR: I think my point was previously said, so to wrap up: We're
saying that the specific proposal is to take it back to
see if we can decouple the style and the markup a11y, and
defer for TPAC?
bkardell: yeah

iank: Seems like the people objecting about text-transform is just
AmeliaBR: Yeah, it's about whether it sees the characters for a11y
before or after transform
florian: It's not just about a11y but more generally the semantics,
like what would happen in reader mode and such?
iank: Another point is that mathml has a lot of legacy content, and
mathml does this in a very magic way. We don't want to get in
a situation where other math libraries cannot opt-in to this
power
Rossen: Let's stop here for now

CSS Inline
==========
Scribe: heycam

resolved value of line-height
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/3749

AmeliaBR: What's the question to be resolved?
florian: This is about the resolved value of line-height: normal
koji: Right now Blink behaves differently from Gecko / WebKit
koji: One of our contributors is willing to try to change Blink
koji: seems smoother for Blink to change, want to confirm that
with WG
emilio: Gecko and WebKit already have this behavior since CSS 2
emilio: CSS2 defines the used value of line-height as something
based on the primary font of the element
emilio: I did try to switch Gecko to return normal, and it's
probably not impossible, but it's a bunch of work
emilio: Also mats disagreed with it
florian: What CSS 2 has to say is fuzzy
florian: different editions
florian: All browsers are interoperable about what
line-height:normal does, to an approximation
florian: that is different from what CSS 2.1 says
florian: 2.1 claims normal is equivalent to a number
florian: That's not what everyone does
florian: therefore it would make sense that for resolved value, you
return the word "normal"
emilio: There is
florian: There isn't
florian: There is only if the element is empty

dbaron: Part of the problem is we had a long discussion at Tokyo F2F
dbaron: and there's nothing written down that reflects the results
of that
dbaron: Some edits made to CSS 2 and reverted
dbaron: There's no usable reference for the results of that
discussion, therefore some people involved here including
emilio and mats, who don't know what's discussed there
florian: I'm frustrated about these edits being reverted
florian: I'll take those edits and put them into css-inline

florian: Skipping over the details, the behavior of
line-height:normal is not equivalent to a number
emilio: You compute a number at the start of the element (and the
element itself), but once you get that number, which is what
Gecko and WK return from gCS, it's the same as if you use
that px value ...
dbaron: It's not
dbaron: there are 2 ways it's different at least
koji: I think dbaron and florian are talking about how
line-height:normal is laid out
koji: emilio is talking about how line-height is computed
koji: and that is interop between Gecko and WK
dbaron: What florian and I are saying is that there does not exist a
number or a px value that is equivalent to normal
dbaron: because depending on the text you have in the element, and
what font fallbcak occurs, you'll get different results
koji: That's for layout.
florian: The computed value is normal as a keyword
dbaron: I don't think the point you're making is relevant here, I
think florian's argument is that we're looking at situations
where the computed value is normal, from a style perspective
dbaron: and we're asking what resolved value to report there
dbaron: florian's point is that in most cases when we have a
resolved value, putting that resolved value back in the
computed value is basically equivalent
dbaron: So there are cases where the computed value is a % and
resolved value is px
dbaron: but if you take the resolved value and put it back in
computed value, you would get the same result (at least for
that element, not necessarily for inheritance etc.)
dbaron: florian's point is that in this case, there is not a single
number that leads to that result, because what normal does
around say font fallback, looking at metrics of possibly one
possibly multiple fonts, is different from what any
particular number does
dbaron: That's the stuff that is not well documented because the CSS
2.1 edits were reverted
florian: The right value to return from gCS would be normal
florian: but if there's broad interop everywhere but Chrome, to
return what that number would be if the element is empty,
then that's unfortunate but not unfortunate enough to
object to that

<tantek> reverting the 2.1 edits (there were a bunch more) was the
right thing to do because not all of it was based in minuted
discussions nor even test cases, and that kind of editing
for a stable document like 2.1 is irresponsible

emilio: I was going through the Gecko code, we have various bits of
if line-height is normal, update the line
dbaron: There are a bunch of things in Gecko code based on
line-height normal, a bunch are wrong
dbaron: Some were discussed at that previous meeting,
dbaron: a bunch of the conditions in the gecko code are in the wrong
place
dbaron: There's a bunch of design decisions important for
interactions with other features, due to the lack of
interop, we probably still have the freedom to make
emilio: After seeing our usage of line-height:normal in our layout
engine, I agree that given normal is more special, the right
thing to do would be to return normal
emilio: I can try again to change Gecko, and if I can't I can report
back
<tantek> from my recollection, line-height normal was a way used (by
implementation) to capture the legacy Netscape behavior of
inline line layout, as opposed to what Håkon & Bert wanted
line-height to do

florian: Getting interop would be nice
florian: If the only way for that is to return a number, that's OK,
otherwise let's try normal
myles: Philosophically returning normal would be great
myles: might break the web
florian: Chrome has been returning normal for a long time, so maybe
wouldn't?
florian: Maybe there is UA sniffing that would make it break
emilio: Given this conversation I can try to convince Mats
florian: I will try to take the CSS 2.1 fixes and put them in Level 3
emilio: Notes in the spec about how that not only affects resolved
value, but other stuff, would be great

koji: dbaron's explanation I finally understand why we want normal,
it makes sense
koji: but I also want interop. Is WK willing to change?
myles: I don't think I would change this before Gecko does
myles: If Gecko succeeds we'd probably be willing to do it
dbaron: My memory of the discussions we had in Tokyo, I'm not 100%
sure we all agreed that we want to stick to a behavior that
normal cannot be mapped to a number
dbaron: That number might depend on something in the first available
font, it almost certainly would, but I'm not sure we agreed
that we do not want the behavior that you couldn't convert
normal to an equivalent number based on available font
metrics
dbaron: That is using font metrics but not particular character
availability

florian: How about we reopen that issue as necessary, based on the
Tokyo text, which describes ~reality
florian: and do that based on the text
myles: Are you suggesting you want to change the behavior to make
normal not magic? or numbers be more magic?
dbaron: Change normal so that its magic is a bit different
dbaron: e.g. how font fallback interacts with line rhythm
dbaron: One piece there is that maybe it is better if the box that
normal gives you is only a function of the first available
font, and not the fallback fonts
dbaron: Then when you have multiple lines/elements, some of which
trigger fallback, you don't get unstable line rhythm
dbaron: I'm not sure we sorted that out fully
myles: I have opinions on this but maybe that's a different topic
dbaron: The reason I'm bringing it up, is it relates to the
conclusion that there does not exist an equivalent number
dbaron: but that's a full day long discussion
florian: I agree there's room for discussion
florian: I propose we first get back the text, and go from there
dbaron: Sure


## [CSSWG] Minutes Toronto F2F 2019-06-04 Part III: CSS Fonts [css-fonts-3]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • July 06, 2019 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

CSS Fonts
---------

- RESOLVED: Remove min-font-size and max-font-size from Fonts 4,
replace with an example of using clamp() to handle safe
responsive typography. (Issue #3739: font-min/max-size
and computed value)
- A note will be added to Fonts spec about the font-size: 0px vs min
font-size web-compat issue
- RESOLVED: Capture that font-size keywords carry an additional bit
of information having some (unspecified) interaction
with some font families. (Issue #3906: Clarify how
computed font-size is determined for size keyword)
- RESOLVED: François does compat research on the effect of font-size
keywords and generic font-families, and report back on
interop. (Issue #3906)

- Discussion on the request to add math-script-level and math-style
properties to CSS (Issue #3746) became a wider topic about the
best way to support math on the web.
- There is a request for more examples and more of a sense of
scope of the larger issue leading to these properties to
allow the group to ensure that they're building properties
in the right way.
- Without the full understanding it's unclear if some aspects
of this, e.g. the 'script level', need to be encoded as
information in the DOM rather than in CSS (so that they can
be selected against)
- CSS and the MathML group need to establish a standard approach
to communication going forward so that specs can stay
aligned.
- Before any final decisions the meta topic of the future of MathML
needs to be addressed. There are three possible futures that
need to be evaluated in order to decide the path forward:
1. MathML is in browser engines, CSS has to be compatible with
what it is.
2. MathML is in browser engines, but we might make substantial
changes as we develop and can adjust it to fit with CSS
better.
3. MathML isn't the right path forward, and math should be
taking a new path forward.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/toronto-2019

Scribe: TabAtkins
Scribe's Scribe: fantasai

CSS Fonts
=========

font-min/max-size and computed value
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3739

emilio: Browsers have minimum font-size settings for a11y
emilio: And they work differently in WK-based vs Firefox
emilio: WK-based browsers, it affects the font-relative units.
emilio: In Firefox they do not.
emilio: So I was considering implementing min-font-size, and that
affects the computed value of font-size, I would assume
emilio: So first, the a11y setting in Blink can break websites
emilio: I'd also like min-font-size to work the same as the a11y
setting.

fantasai: Reason it affects computed and not just used font size is
that if you were using ems correctly (for the purpose of
making something relative to text size), then everything
should scale and match the size of text.
AmeliaBR: How much would things break if we declared a different
computed value for inheritance vs font-relative units?
dbaron: Which is what I thought Gecko did, and maybe what it did
pre-servo
fantasai: That would be fine and would honor the constraint we want
emilio: Would it?
[Amelia re-explains their proposal]
TabAtkins: So on any given element, 1.2em would still be 120% size
of the text

emilio: That would still break websites if we used this to implement
the a11y setting
dbaron: People use the root font size to create a unit that's not
really related to the font size, and that breaks if you
apply font size minimums to it
dbaron: I think this is also significantly problematic because of
people misusing rem to get a custom-sized unit
jensimmons: And they want nice math, yeah

myles: So it sounds like users are getting min-font-size via the UI
settings; could you just keep that separate from
min-font-size property?
emilio: Yeah, we could. But it would still mean the minimum font
size setting is magical; you couldn't override that in a
user stylesheet.
dbaron: Also one of the underlying principles of CSS is that it
explains how author and user expectations work with each
other. Settings/prefs are usually explained as part of the
user stylesheet.
myles: Right. There just might be a distinction between an author
saying they want to scale up a font size, and the user saying
they can't see text smaller than a certain value.
dbaron: Also, minimum font sizes don't seem to work well in practice
anyway, many pages break. So maybe this isn't the most
useful anyway.

fantasai: Still if authors do understand font-relative units and use
them correctly, things should still scale correctly.

jensimmons: So to clarify, there's a min/max-font-size, and maybe
you set font-size with a calc(vw) or whatever.
jensimmons: CSS provides a variety of units to allow authors to
express the why of their sizes through relative
measurements, against the font or the screen or the
container or the pixels, etc. Authors who understand
these units will use font-relative units when they want
things to scale with the font, so if you hit a min or a
max, and we cap it when you hit the limit, should that
propagate to the 'em' unit, that's the question, right?
<chris> yes, exactly
[yes]
jensimmons: It doesn't even make sense to me that it wouldn't
transfer over.
<florian> +1 to jensimmons
[jensimmons gives an example of e.g. gmail which doesn't handle the
scaling of text correctly, so zooming in creates a suboptimal
layout -- but this is a case of the author not choosing to use
the correct units ; it's fixable using correct units smartly, but
breaking the connection between ems and font-size would make it
impossible to fix]

AmeliaBR: So while CSS gives people the tools to use things
properly, we have to recognize that some people won't use
it correctly.
dbaron: I think I agree that making 'em' honor min/max is the only
thing that makes sense. It's not clear to me which to go
with inheritance, as it depends on use-case
<leaverou> Agreed with dbaron. Authors use ems assuming they
correspond to actual used font size. If that assumption
breaks, a lot of UIs would too.
fantasai: There was a comment from Fred Wang, where if min/max
clamped the value before inheriting, you'd have a size in
the multi-step process that gets messed up and messes up
all subsequent sizes.
fantasai: So I agree with Amelia that the computed / inherited
font-size should not be affected by the min/max, but that
the min/max should factor into not just the used font size
but also the resolution of font-relative units
fantasai: We would be doing authors a disservice if we did not
ensure that the font-size and 1em matched.
<chris> I agree with that proposed solution
<chris> ... otherwise things end up double-applied, growing too much
<chris> ... clamping should happen as late as possible

dbaron: I think this is a reasonable conclusion, I think it doesn't
work well for Jen's use-case, but I think what does work
well for that is using min()/max() inside of font-size.
dbaron: Because you want clamping to happen at a particular point,
not to be inherited down further into the tree. So you'd use
font-size: clamp(10px, ..., 36px);
AmeliaBR: Right, and that would be bad for min-font-size, as then a
<small> child would also get clamped and not get
smaller. While clamp() works properly
chris: This has been interesting. Not sure I could reproduce this
after a few days. I want some examples in the spec of what
you should use each with.
<AmeliaBR> +1 to examples!
<fremy> (side note for people interested in this and would love
examples, Jason Pamental talk at cssconf this year is a
great resource)

TabAtkins: I think we're leaning toward the properties being
designed purely for the a11y/settings use-case, and if
you want to just clamp a value in a range, you should
always use the math functions.
iank: Currently the way we do this in Blink for a11y isn't via a
property because the font-size clamping we do applies on a
per-region basis.
myles: Ours is also complicated, probably in a different way.
myles: It seems like dbaron was saying the function of CSS was to
explain browser features. It sounds like this feature
shouldn't be explained in CSS, and it should remain magic.
emilio: It sounds like Ian is talking about the text auto-sizing
actually?
myles: Ah, but I wasn't in mine.
myles: We have a lot of systems that interact to produce a text size.
myles: I've spent a long time trying to increase readability, and...
myles: The issue is "I want to use this CSS feature to do a11y, but
things break", then we just shouldn't use that feature.
florian: So what are we using these for?
myles: These predate me, there was just a note in the spec and I
started implementing
TabAtkins: These predate the math functions; they were meant to
implement the "keep vw-based font sizes from getting too
big/small"
TabAtkins: So we can just drop the properties, then
chris: I was looking at history; this looks like something that was
dropped from Fonts 3, and Myles dropped it into Fonts 4 two
years ago.
<tantek> agreed with TabAtkins
<tantek> proposal: drop the properties because not implemented
anywhere
astearns: So these aren't implemented in a user-facing way anywhere,
and we're not convinced they're good for any use-case...
jensimmons: responsive typography is what the use-case is
called, you can search for it
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Jun/0187.html

<AmeliaBR> font-size: clamp(12px, 10vmin, 24px) vs font-size:
10vmin; min-font-size: 12px; max-font-size: 24px;
astearns: So looks like we have consensus to remove these
properties, until we have a use-case that
min()/max()/clamp() don't serve.
AmeliaBR: And replace the section with an example of how to use
clamp().

RESOLVED: Remove min-font-size and max-font-size from Fonts 4,
replace with an example of using clamp() to handle safe
responsive typography.

heycam: The effect of these properties on the computed value of
font-size... still worth resolving on how these browser
settings affect things?
ChrisL: Example of broken is page with <html style="font-size:
1px">. Answer is, don't do that.
TabAtkins: The way it inherits separately is a problem for designing
a font hierarchy relative to a base size, tho
AmeliaBR: Should we give advice to browsers on whether font-relative
units should be affected by browser settings?
myles: Arguments on both sides
myles: If we don't expose to author, they don't know what happened
to their page
myles: I don't think it should be specced
TabAtkins: Note tho that h6 defaults to smaller than standard font
size. If min-font-size is set to standard-font-size (both
16px, say), and you defined your hX hierarchy by starting
from h6 size and then calc()ing up the higher values, the
Chrome behavior would mess things up; starting from h1
and calc()ing down would be fine. So it's not *all*
pathological cases.

dbaron: To respond to myles there's another tradeoff around a11y
dbaron: Some users that need a11y are concerned about privacy, and
are willing to have the feature not work as well to keep
secret that they're using it.
TabAtkins: For this feature, no matter how you do it it'll be
page-exposed tho

font-size: 0px is special wrt minimums
--------------------------------------

dbaron: Also, the browser minimum isn't *really* a minimum.
dbaron: If you specify a min of 10px to font-size:1px, you get 10px
font. But applied to font-size:0px, you get 0px. That's very
important. So it's not a strict "minimum" anyway.
myles: Example is layout with inline-blocks, set font-size: 0px so
that the gap below the baseline is zero.
TabAtkins: Myles, wanna capture that 0px point in the spec? If
everyone agrees something is needed for webcompat, it
should be captured
myles: In a note, sure

ACTION myles Add a note about the font-size: 0px vs min font-size
web-compat issue
<trackbot> Created ACTION-879

Clarify how computed font-size is determined for size keyword
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3906

myles: I don't think we can get rid of the fact that monospace is
special, for webcompat
chris: So this is really about the fact that Courier looks too big.
chris: And browsers also noticed that CJK fonts can look too big at
16px by default
emilio: In gecko we do this based on the generic family specified.
myles: So "a, b, serif" gets a different font size than "a, b,
monospace"
dbaron: Yes, because of the assumption that those fonts are probably
monospace as well
fremy: As I recall that's not what was implemented by browsers...
myles: In WK, we only adjust if you say *only* "monospace"

myles: So using font-family to dictate font-size is fundamentally
broken, we all agree
[we all agree]
myles: So the question is if we should write down exactly how it's
broken. It sounds like everyone does it differently
dbaron: Given there's incompatibility, there's maybe room to improve
this

[emilio describes some details of how this works]
dbaron: At one point I had part of a plan to replace with with
dbaron: Probably not web-compatible, but maybe... Would require new
values.
fremy: Last I recall Edge didn't do any adjustments, but at some
point we got a bug and added new UA rules that only targeted
elements that get monospace by default. We don't apply it to
the *monospace value* tho.
TabAtkins: We should capture in the property that extra bit of
information captured about whether size was specified as
a size
TabAtkins: because browsers seem to do something special in that case
AmeliaBR: Keywords are a bit vague anyway
TabAtkins: No flexibility in that they convert to a <length>
TabAtkins: You honor a <length> as a <length>
TabAtkins: But that's not how browsers work
TabAtkins: We might need to keep it underdefined, but at least that
there's some thing special going on
fremy: We have interop, so let's spec that
TabAtkins: OK, but let's capture there's something
emilio: Gecko code... when you have multiple families, we behave
like WebKit
emilio: Yay interop!
AmeliaBR: So weird behavior, but cross-browser consistent

chris: So how are we resolving?
dbaron: The thing this was solving is really a use-case for
dbaron: Would like engine that doesn't implement font-size-adjust
that doesn't implement it to fix it
dbaron: It's ugly because it's designed to be compatible with its
non-existence
dbaron: It's a way of saying "i want to specify font-size in terms

astearns: So it sounds like proposal is to acknowledge reality in
font-size property that it makes font-sizes strange.
astearns: And at minimum capture "it's strange" in the spec.
<dbaron> oh, actually, font-size-adjust may be behind the
experimental web platform features flag in Chrome...
TabAtkins: Let's capture that keywords come with extra bit of info
TabAtkins: And also investigate if there's compat, and if so spec
that
myles: sgtm
astearns: Is there someone volunteering to do the investigation?
fremy: I volunteer.

astearns: proposal: acknowledge reality that font-size keywords have
some weirdness with particular generic font families.

RESOLVED: Capture that font-size keywords carry an additional bit of
information having some (unspecified) interaction with
some font families.

astearns: Second is to deputize François to try and capture what the
weirdness is

RESOLVED: François does compat research on the effect of font-size
keywords and generic font-families, and report back on
interop.

math-script-level and math-style
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3746

https://MathML-refresh.github.io/MathML-css-proposals/math-script-level-and-math-style-explainer.html
bkardell: In doing Chromium impl of MathML, and trying to explain
the MathML magic in a way that's part of the platform,
there are some funky areas
bkardell: So we want to get that funky added to CSS.
bkardell: One is math-style. As part of layout, takes into
consideration whether your math equation is happening
inline in text or as a block; aligns baselines differently
and tries to minimize vertical size in inline, etc.
bkardell: If we have that, this is one more thing that becomes a UA
stylesheet rule.
bkardell: math-script-level is in my mind a lot like counters. It
lets you scale up or down font-size
emilio: So when you nest an element that's a subscript or
superscript, or part of a fraction, the font-size shrinks.
emilio: But in CSS it affects the computed font-size, which is
annoying.

fantasai: This effects the font-size. Why is it called script-level,
and why is separate from font-size?
bkardell: This is how I think it's similar to counters, it carries
AmeliaBR: So fantasai's question is why not do this with relative
font sizes. I think reason is to give browsers some more
flexibility...
fantasai: We can have math-larger and math-smaller...
fremy: If you have a fraction, 1/2. You can nest, 1/(1/2). But third
level of nesting, switch to a side-by-side fraction.
bkardell: Even within that context, you can have sub/superscripts
too.
AmeliaBR: There definitely needs to be a new property. Math fonts
have a property saying how much you scale down as you go
down a script level.
AmeliaBR: Do you need to be able to absolutely set "3 sizes down
from normal", or is it always single steps?
bkardell: These map straight from MathML attributes. I know the name
isn't great, but
<AmeliaBR> font-size-math-adjust???
<una> what about font-size-math-adjust: <nesting-level>

emilio: Figuring out which nodes need to increment or decrement the
script level is pretty tricky
emilio: It would be good to see if we can decouple the script-level
from font-size, because it becomes much easier, add an
"auto" value and figure it out doing layout or something
AmeliaBR: Does nesting level have effects other than font-size?
myles: fremy said yes
fantasai: So then you'd want to *select* based on that level. So
then that info must be in the DOM.
fantasai: We've had similar cases in the past of things thought to
be in CSS that we pushed back and said "no, this needs to
be in the DOM".
fantasai: Like directionality.
<fremy> (yep, for the record I agree with fantasai)

dbaron: I think one of the reasons for this is that MathML has
attributes that specify both the ratio of font-size for each
change in script level, and the min font-size at which you
stop changing it.
dbaron: script-size-multiplier and script-min-size
fantasai: Does this mean we're adding font-min-size back?
myles: There have been a half-dozen or so of these proposals. How do
these affect existing elements outside of MathML?

<una> font-size-math-adjust: <max-nesting-level> / <min-font-size>
<tantek> how well supported/used is MathML in the platform
currently? Like who else besides Firefox supports it?
<TabAtkins> tantek, igalia is implementing it for Chrome right now

bkardell: Some people do indeed think that [itex] isn't great, and
math layout should be a normal part of CSS.
florian: I think we want the building blocks of math in normal CSS.
And I've heard the argument that MathML is bad for math;
mathjax people will do that.
florian: So mathjax renders math into HTML or SVG, but they're
missing some tools, so makes it subpar.
myles: So what's the criteria here: should math layout be dumped in
whole-hog?
<chris> https://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle.attrs
<chris> also https://www.w3.org/TR/MathML3/chapter3.html#presm.scriptlevel
bkardell: We're trying to find the MathML core and eliminate as much
as possible.
bkardell: So far we've been doing good at that.
bkardell: Reusing CSS stuff well.
astearns: I hear this as a request from another group, like the
timed text people, to get something that they can't
currently do in CSS.

TabAtkins: Is the goal that you can implement math layout with
<div>s, or are we saying that MathML is a special layout
form, like SVG, that can have its own specialized CSS
without influencing arbitrary text layout?
dbaron: There are two different groups in w3c working on different
solutions here
myles: So if this is a generic layout mechanism, you need to be able
to put flexbox inside of it
florian: I don't think we want to be able to take naive markup and
get good math out of it.
TabAtkins: Are we intending that you can make a fraction, and the
numerator is a flexbox?
TabAtkins: If so, you can nest flexbox into it. If not, then you
can't.
TabAtkins: But need to know which way we're going so we can figure
out how to interact with it
chrisl: ...
TabAtkins: We'd make a Math Layout spec

iank: So basically MathML is already in this state where you can
nest CSS layout inside of it
iank: And it uses CSS layouts to achieve some of its layouts
iank: so <mtable> uses css tables
iank: The text inside of MathML is just text layout, it can do
floats, etc.
iank: This was the feedback we gave to the group: you need to define
how this interacts with all of CSS.
myles: Are you saying that philosophically that's how this should be
designed, or that it's just a quirk of impl?
Rossen: So support rich layout that allows math, and interacts
nicely with the rest of css.
astearns: A detail is that some requirements, we may not get to.
Like western typography, some details we never get to.
myles: So the intention is that we end up with display:math at some
point?
AmeliaBR: display:fraction, perhaps, like display:ruby : some
specialized focused layouts as necessary
<dauwhe> this is a w3c strategy funnel issue
https://github.com/w3c/strategy/issues/43
<dauwhe> https://www.w3.org/community/knowledge-domain/

fremy: So math-level.
fremy: If you want a layout that's different depending on the math
level, that's fine. We could do that.
fremy: But the way I see this is that math-level is changing other
properties, in some weird interaction.
fremy: So my mental model matches fantasai, this is at the DOM level.
fremy: And if we go the "you should do math using divs", that
doesn't work.
fremy: My impression from when I worked on this, is that this is
complex to put in a CSS property.
fremy: But if our goal is to allow everything in CSS, I don't see
how it's a markup thing.
fremy: So question is we need MathML markup, or is there a
simplified markup that would provide the grouping/level/etc
that we could provide the levels on top of.
* leaverou wonders if that means we should add a pseudo-class to
select it instead (re: it's at the DOM level)
<TabAtkins> leaverou, yeah, that was a question earlier

myles: So let's say we do wanna go on this path where we induct math
layout into CSS.
myles: When we write CSS specs we have to describe layout exactly.
myles: Do you envision that this group would make those decisions,
or that MathML would do it and deliver them to us and we'd
put them into our docs?
bkardell: Right now they're trying to get that defined.
bkardell: Huge criticism right now is that it's super underdefined.
<tantek> FYI: https://caniuse.com/MathML
iank: As part of our launch process we require interop-capable
specification.
iank: And the two impls currently aren't remotely interoperable,
especially layout.
iank: I spent two or three hours one day and created a list of
issues where Firefox and WebKit differ.
fantasai: If MathML is going to define a layout model closer to css,
they should definitely interact with us more than what's
happening currently.
fantasai: So we can make sure it's compatible with css layout and
all the interactions with other properties.
fantasai: Just because of where the expertise lies.
<tantek> Is there an opportunity for CSS/MathML joint meeting at
TPAC?

astearns: I would really like to see more stuff in the explainer.
Right now it looks like a reiteration of the proposal. It
has some markup examples without intended renderings, etc.
fantasai: Same, I don't really understand what it's trying to do
currently. So I can't even comment on whether they're
doing it right or not.
fantasai: So somebody came up with a solution to a problem, but I
don't understand the problem, or why this is the best
solution to that problem.
fantasai: Would love to advise them, but can't right now.

florian: Back to fremy's point, for those trying to solve math with
CSS, I don't think the goal is markup that resembles MathML
and uses display:fraction, display:sqrt, etc. I think it
was to start from a MathML-ish markup that is processed
into a pile of divs, then rendering fractions with a
vertical flexbox, etc. Only a few lacking aspects would
fremy: I don't disagree, that's also an option. But if that's the
goal then you don't need the math-script-level property.
myles: Agree. We already have SVG then.
TabAtkins: SVG doesn't quite solve it - we still need a few small
things, like baseline control, stretchy characters.

AmeliaBR: So wrapping up, we have some requests for Brian's team at
Igalia about how we want communication to happen, better
explainers. Larger comprehensive use-cases, rather than
one proposal at a time.
AmeliaBR: Would be useful if this group gave feedback about how we'd
like to be communicated with.
AmeliaBR: And then there's further concern about where things should
live, CSS vs DOM, etc.

dbaron: fantasai was asking about the problem to be solved. There is
a political disagreement about the problem.
dbaron: In that, there is the question of whether MathML is the way
forward.
dbaron: A few years ago when it was in Firefox only and we thought
we might remove it, everyone thought MathML wasn't the right
way to do it; do it in CSS instead, etc.
dbaron: And add to CSS to improve mathjax output.
dbaron: Now we're somewhat surprisingly getting to a world where
MathML is supported across browser engines.
dbaron: So question is whether MathML is, like html, something that
needs CSS to reflect the things in it.
dbaron: Are we concerned with MathML backcompat such that CSS needs
to care about its legacy mechanisms.
dbaron: Or do we have substantial flexibility to change things as
necessary.
dbaron: So three possibilities:
dbaron: 1. MathML is in browser engines, CSS has to be compatible
with that.
dbaron: 2. MathML is in browser engines, but we might make
substantial changes in the process and can adjust it to CSS
better.
dbaron: 3. MathML isn't the right path forward, and math should be
taking this up the path.
dbaron: Path to making this decision right now is very uncoordinated
and not based on principles, but rather on lots of small
decisions where people might not be aware of the larger path
they're supporting.
dbaron: Possible we should be discussing this more explicitly.
dbaron: I think before we decide what we're trying to solve, we
might want to have that discussion.
bkardell: Before I went to Igalia, I spent a lot of time thinking
bkardell: My own thoughts were between 2 and 3.
bkardell: HTML isn't very perfect semantically either, it's focused
on text.
bkardell: So it has no starting point. It's not like SVG, where we
all agree what SVG is.
bkardell: Thirty years the community has been working on something,
lots of back and forth.
bkardell: When we got to HTML5 and MathML was codified into the
parser, now it's in a special weird place.
bkardell: If there's something I'd personally advocate, it's that we
need to find a starting point or we can't have this convo.
bkardell: So back with corporate hat on, the core-math group is
trying to find the minimal bits that hold things together.
bkardell: I don't want to personally be like "MathML is the best
thing ever", I dunno. I want to be malleable here.

<TabAtkins> myles: Minutes of the Math session during last year's
tpac:
https://lists.w3.org/Archives/Public/www-style/2018Nov/0008.html

<br dur=20min>


## Syncing Braille Cell buttons with OfficeMath

Source: Murray Sargent: Math in Office • MurrayS3 • May 29, 2019 • Permalink

A typical refreshable braille display has a row of braille cells with a button above each cell as illustrated in the figure of a HIMS Braille Edge 40. The purpose of a button is to move the insertion point (IP) to the character or abbreviation represented by cell below the button.

This post discusses how pressing a cell button associated with a math braille cell can move the text selection to the closest matching character position (cp) in the corresponding math zone. The algorithm accounts for the many-to-many relationship between braille cells and OfficeMath character positions (cp’s). A single math symbol may be represented by multiple braille cells (‘=’ is represented by the four braille cells “⠀⠨⠅⠀”) and characters appear in math zones that aren’t shown on a braille display (there’s a start delimiter for 𝑎² that has no counterpart in the corresponding braille “⠁⠘⠆”. This is discussed further in Math Braille UI and below. And there are other cp differences such as hidden text as discussed in the post Using MathML-Based Speech to Edit Math in Different Math Models. In math braille, abbreviations are not used, a simplification that allows Nemeth math braille to be embedded in the braille for any language.

## Synchronization algorithm

The algorithm given here to synchronize the math-zone insertion point with a braille-cell button is analogous to the algorithm for finding the cp from a mouse-button hit on a line of text. For the latter, you measure the text until its width equals or passes the hit position. For the braille-cell button press, you

• Get the braille for a whole math zone or some valid selection therein. Note that if you select the start delimiter of a math object, such as a fraction, the selection is automatically extended to include the entire fraction.
• Press a braille cell button and get its offset into the math braille string. I’ve found that Narrator reports the offset via ITextRangeProvider::Move() and Select() calls.
• Recreate the same math braille noting the math-zone cp where the length of the evolving braille string equals the braille offset for the braille-cell button.
• Adjust that cp so that it is a valid IP in the math zone.
• Set the math-zone IP equal to the adjusted cp.
• Once again recreate the math braille to update the braille cell IP (⣀) corresponding to the new math-zone IP.

## Braille-cell buttons versus ←/→ key navigation

The left and right arrow keys can traverse every valid cp in an OfficeMath math zone, while the braille-cell buttons only have access to cp’s that have braille counterparts. Let’s consider the two cases mentioned in the introduction. The ‘=’ sign is represented by “⠀⠨⠅⠀”. If you press the button above the starting braille space (U+2800), the corresponding math-zone cp should be in front of the ‘=’. Remember that insertion points in rich text like math zones are in between characters, not on top of characters. If you press a button above any of the remaining three braille characters, the math-zone cp (IP) should follow the ‘=’. Meanwhile a single → key press in front of the ‘=’ moves past the ‘=’.

Now consider 𝑎². In a math zone this is represented by {𝑎|2}, where { stands for the superscript-object start delimiter, | is the argument separator, and } is the superscript-object end delimiter. In RichEdit these delimiters are given by the Unicode characters U+FDD0, U+FDEE, and U+FDEF, respectively. The start delimiter has no counterpart in the corresponding superscript braille string “⠁⠘⠆”. So, pressing the braille-cell button above the ‘⠁’ could set the IP in front of the superscript object or at the start of the superscript-object base (in front of the 𝑎). Structured navigation that selects the whole superscript object or just the ‘⠁’ could be used to choose between these two possibilities. Meanwhile a single → key press in front of the superscript object moves to the start of the superscript-object base.

The subscript object 𝑎₂ also appears as {𝑎|2} in the OfficeMath backing store. The object type is specified in the character formatting of the start delimiter. But in Nemeth math notation, 𝑎₂ is given simply by “⠁⠆”. The subscript operator ‘⠰’ is implied. In computer braille notation, this is “A2”. So, for such simple subscript objects, the start, middle, and end points are all ambiguous. For example, in the string “⠁⣀⠆”, with ‘⣀’ marking the insertion point, the next character typed could be at the end of the subscript base (first argument) or at the start of the subscript (second argument). Math Braille UI disambiguates the two by including a dot 8 (‘⠠’) in the braille-cell character(s) in the object argument that contains the insertion point. If the IP is at the start of the subscript, the math braille for 𝑎₂ is “⠁⣀⢆”, whereas if it’s at the end of the base, the math braille is “⢁⣀⠆”.

Similar cases include the ends of integrands, summands, accents and math-function objects as well as optional arguments like missing integral limits and radical indices (a square root has a missing radical index).

A braille user should have at least three kinds of OfficeMath navigation: braille-cell buttons and vertical scrolling, structured navigation, and the ←/→ keys. Currently, I have to use a keyboard for structured navigation and the arrow keys. But we should be able to assign keys on refreshable braille displays to perform such navigation in addition to the braille-cell button navigation.

## MathJax v3 beta.4 released

Source: MathJax • May 21, 2019 • Permalink

The MathJax team has been working hard on a major rewrite of MathJax from the ground up, with the goal of modernizing MathJax’s internal infrastructure, bringing it more flexibility for use with contemporary web technologies, making it easier to use with NodeJS for pre-processing and server-side support, and making it faster to render your mathematics. We have made headway in all these areas and we are pleased to announce the fourth public beta release of MathJax v3.

## Where to Find the Beta Release

The code for the release is available in the beta branch of the MathJax v3 github repository.

The mj3-demos repository includes examples of how to use MathJax v3 in web browsers, including interactive examples, custom configurations, custom tex extensions, and custom builds that you can use as a starting point for your own projects. See the instructions in that repository for more details.

The mj3-demos-node repository includes examples for how to use MathJax v3 in NodeJS applications, and includes sample tools and examples of how to use a number of MathJax v3’s features.

## What’s Included in MathJax v3

This beta version includes two input processors (TeX and MathML) and two output processors (CommonHTML and SVG). Other input and output processors (e.g., AsciiMath input) will be added in the future.

The current TeX input processor has all the core functionality of the MathJax v2 TeX input, and nearly all the extensions that are now available in v3.

The CommonHTML and SVG output implement all the MathML elements that they do in v2, but do not yet include support for line breaking (neither automatic nor explicit ones); this will be implemented in a later version. Both output renderers currently only support the MathJax TeX font; other fonts will be added in the future.

## What’s New

This beta includes a number of important improvements over the beta.3 version.

### MathJax Components

The biggest change is the ability to create MathJax “components” that can be dynamically loaded by MathJax as needed (much as could be done in version 2). This allows portions of MathJax to be bundled together into components that include most or all of what you need to run MathJax, but still allows less-used pieces to be loaded on demand later when needed. This is similar to v2’s combined configuration files and TeX extensions.

The main goal of these components is to use them for the delivery of MathJax from the CDNs that host MathJax. This allows you to customize the MathJax components that you use without having to have (as single files on the CDN) every possible combination of parts that anyone would need packaged together. We will provide a number of all-in-one packages that include an input and output jax together with the data for a font to be used, but also will provide separate components for the individual input and output jax, fonts, TeX extensions, and so on, so that you can mix-and-match them as needed.

MathJax components can be used in the browser as well as on the server in NodeJS applications, so browser and server-side applications can use the same code base and configurations. Components can be combined together into larger packages, either with other MathJax components, or with your own code, via webpack, for example.

Moreover, the tools for building components are available so that you can create your own custom components that you can serve from your own website if you have special needs not addressed by the CDN. For example, authors writing TeX extensions for MathJa can create their own components that can be loaded into MathJax from a different server even if the core MathJax is loaded from a CDN.

Although components are a convenient way of working with MathJax, those writing NodeJS scripts that use MathJax need not use the components as we have packaged them at all; they can continue to import MathJax into their projects directly, as in previous beta versions.

### Configuring Components

The component system described above can be configured using a global variable MathJax that you set before loading the main MathJax component that you are planning to use. The MathJax variable specifies configuration blocks for the various components in much the same was as was done in version 2 (this is illustrated in the examples below, and described in more detail in a separate section below). MathJax will modify this global variable to include the methods and data that it creates during the startup process for your use in your applications.

### Rendering and Converting Math

The mechanism for rendering expressions in previous beta versions of MathJax 3 involved calling a sequence of MathJax commands to perform the individual actions required to find, compile, typeset, and insert the math into the page. These functions are still available, but there are now several new functions to make that process easier and more natural to perform. The render() method of the MathDocument and MathItem classes will perform all the actions normally needed for typesetting math to the page, and the convert() method will perform conversion from the input format to the output format of the page (or to MathML, which is used internally by MathJax).

These methods use an internal list of actions to be taken when they are called, and those lists are updated automatically when extensions are loaded. For example, when the semantic-enrichment extension is loaded, the action that performs the enrichment is added to render() and convert() automatically, so you don’t have to call the extension’s methods yourself. You can even add your own actions to the list, if you want, or could remove the automatic ones to fully customize the rendering process.

If you use the MathJax components described above, MathJax will set up short-hand functions for you for typesetting the page or converting from input to output formats. For example, if you load the input/tex and output/chtml components (or the tex-chtml combonent that combines them), you automatically get methods Typeset() and TypesetPromise() for typesetting the page, and tex2chml(), tex2chtmlPromise(), tex2mml(), and tex2mmlPromise() that convert from TeX to HTML or MathML. You also get texReset(), TypesetClear(), and chtmlStylesheet() that reset TeX’s labels and equation numbers, reset the typesetting system entirely (the information about CSS used, font caches, etc.), and produce the CSS stylesheet object used by CommonHTML for the expressions you have processed so far. The ones ending in Promise return a promise that is resolved when the math is completed (use this if there is a chance that an external module needs to be loaded, e.g., with \require), while the others perform the typesetting or conversion and return the result immediately (they will throw an error if an external module needs to be loaded).

If you are using the MathJax components, then the MathJax.startup object includes references to the important objects created by MathJax automatically, like the input and output jax, the DOM adaptor, and the MathDocument. You may reference these as needed in order to access their methods for more special-purpose needs. Some of the examples below illustrate this.

A contextual menu similar to the one in version 2 has been added to MathJax v3 in this beta version. It has the actions familiar from version 2, but also includes some new features like copying to the clipboard.

### Assistive Technology

This beta version now includes support for assistive technology via the generation of speech strings attached to the math elements, and via an interactive expression explorer like the one in version 2. These can be activated using the contextual menu, as in version 2, or by importing the a11y components into your node project or custom webpacked version of MathJax.

### CommonHTML CSS

The CommonHTML output now produces only the CSS needed for the expressions on the page, rather than the CSS for every possible character in the font being used. This reduces the number of CSS rules used by CommonHTML considerably, and improves performance of browser refreshes and zooming. If you use NodeJS applications to preprocess math expressions and capture the CSS output to a separate CSS file, you may need to process all the math expressions before generating the CSS file. Alternatively, there is a new adaptiveCSS option for the CommonHTML output jax that you can set to false to have MathJax return to the beta.3 behavior.

### SVG Font Caching

The SVG output now includes the option of caching the glyphs used to render the mathematics so that the paths are shared if a character is used more than once. The cache can either be global (all expressions on the page share a common cache) or local (each expression has a cache for glyphs used within it, but they are not shared between expressions). This can be set using the fontCache option for the SVG jax, and it can be set to 'global', 'local', or 'none'. The default is 'local' so that conversion of math to SVG will produce self-contained SVG expressions.

### TeX Extensions

As part of the new components feature discussed above, the TeX input jax can load TeX extensions in much the same way that v2 could. This is accomplished through the new require extension that implements the \require macro to load extensions. There is also and autoload extension that will load extensions automatically when their macros or environments are first used. These are included in the default input/tex component, so you if you use that component (or one of the combined components based on it, like tex-chtml or tex-svg), you should have access to these extensions automatically. For example, \require{physics} will load the physics package.

Another new TeX package is the configMacros extension that allows you to configure pre-defined macros using the TeX input jax options, much like you could do in v2.

The new tagFormat extension allows you to customize how tags are handled in MathJax, and provides the equivalent of the formatNumber(), formatTag(), formatID() and formatURL() options of the TeX equationNumbers configuration block from v2.

The new braket extension implements the physics bra-ket notation macros. They will be loaded automatically if you use the input/tex component, or include the autoload extension in your project.

### Color Macro

In version 2, the \color macro worked in a non-standard way. The LaTeX \color macro acts as a switch, to change the current color for all the math that follows it, while the MathJax version took a second argument that enclosed the math to be colored. Version 2 included a color extension that implemented the LaTeX \color behavior, but it was not loaded by default.

In version 3, the LaTeX \color macro will be the default behavior if you are using the input/tex or input/tex-full components, or any component build on them (e.g., tex-chtml or tex-svg). You can restore the v2 behavior by setting color: [] in the autoload configuration for the tex component (when using input/tex), or by removing the color extension from the package list using packages: {'[-]': ['color']} in the tex configuration (for input/tex-full).

## NOTE

This is the fourth public beta release of MathJax v3.

Mathjax v3 is in beta release. Do not use this in production, but please test it and report issues on the MathJax v3 issue tracker!

This is the final planned beta version. We expect an official 3.0 release in the near future.

## [CSSWG] Minutes San Francisco F2F 2019-02-27 Part III: Getting images' aspect ratio right from html attributes, CSS Inline, Houdini <3 Text (aka Houdini and text layout) [css-inline] [houdini]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • May 16, 2019 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

Getting images' aspect ratio right from html attributes
(continued from Monday)
-------------------------------------------------------

- After a few days to think about the proposal as there was no
consensus on what was the best way forward - add new attributes
(original plan) or do property mapping (new plan).
- Chrome is committed to investigating further and will analyze both
approaches before selecting one and putting the work into WICG.

CSS Inline
----------

- RESOLVED: We'll add a separate property for this [first/last
baseline values of vertical-align] (Issue #861: Should
first/last baseline values of vertical-align belong to
alignment-baseline or separate longhand?)

Houdini <3 Text (aka Houdini and text layout)
---------------------------------------------

- There are several different paths the group could take when
Houdini builds its API for interacting with Text (Houdini Issue
#854). These range from a region-like API, where your content
flows from one box to the other to exposing glyph indices and
font metrics through the API. These approaches also come with a
similar range of potential for footguns.
- Widely the group leaned toward collecting use cases and solving
the safest of them first (that still would have broad usage)
before extending the API further.
- Exposing justification was one possible first step. Another
possibility was a property set to assist minority languages such
as what's being done in Graphite and AAT.
- Work will continue one scoping out a preliminary feature set and
drafting a proposal.

CSS Text
--------

- RESOLVED: Add the stable value [to text-wrap] (Issue #672: Allow
for paragraph-level line breaking)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: argyle

Getting images' aspect ratio right from html attributes
(continued from Monday)
-------------------------------------------------------

florian: My understanding is that we all agreed this would be a good
idea if possible, and we should check if possible
florian: Tab disagrees, I want to hear that
florian: For context: "it" is using the width and height HTML
attributes to trigger the intrinsic aspect ratio
fantasai: Specifically, where we map the width and height HTML
attributes to width and height CSS properties, we could
also use them to calculate the ratio and also map that
back to CSS (using the new aspect-ratio property).
fantasai: That would solve the problem around the aspect ratio
information would be lost due to waiting for the image to
load, waiting to discover auto sizing
fantasai: so the proposal was to do that instead of introducing new
attributes to solve the same problem
Rossen: What is the data we need to gather then?
florian: So we don't break the web
Rossen: For the width and height
florian: Do we not agree?

TabAtkins: Having width and height be presentation attributes, and
not affecting those new and exciting ways
TabAtkins: The other reason I liked it, some of the other things,
like picture, you wanted to give an intrinsic size to
them, and it feels semantically better to be specific
about being intrinsic than doing css things that also set
intrinsic sizes.
florian: There's no intrinsic tools to do this
* fantasai thinks ojan should be here
<AmeliaBR> +1 to Tab's argument about <picture><source
intrinsicsize="..."> making more sense than width &
height

myles: We should consider the interaction with canvas where w and h
have other meanings other than mapping to css
TabAtkins: It sets the backing store on width/height, which is
compatible

dbaron: ... If this is a major thing sites can do to improve
loading, if a cms can just do this, that's great, and it
means that lots of sites can get it cheaply
dbaron: I think, if it's it's own attribute it we can do that, I
don't think it's as safe to do if we're re-using width and
height
florian: If the cms wanted to check if there was previously a width
and height, they could still inject the w/h and multiply by
what's needed, but they also need to check min-height and
max-height, and then it gets messy

astearns: We're theorizing about things Ojan has experience in, at
the most this conversation should inform what he continues
to do as he tries to find a solution
astearns: but I'm not sure I see the utility of theorizing when we
have an experimenter
florian: Utility is we don't need to experiment if we have other
demos, not worth checking if we don't want to do it anyway

<TabAtkins> <style>img { width: 100%; }</style> <img
intrinsicsize="350x450"> works by default. Changing it
to <img width=350 height=450> doesn't work; you have to
manually set height: auto in CSS too.

jensimmons: I think the original intention behind what fantasai was
saying, here's an idea, might be much simpler than
adding new attributes, we'd like this considered
jensimmons: I do think there's a way to do it that hooks into CMSes
and existing things, instead of making it more
complicated
jensimmons: If only width is coming out of a cms, and there's no
height, there's no mapping to intrinsic, we can map with
that limited data
jensimmons: Maybe there's something more complex needed, and we do
both
jensimmons: But I think there's an elegance here tapping into what
we already have. Perhaps that's what ojan is intending
jensimmons: Hey, we're going to solve some of this in css, and to
have that really heard, .. that's what I'd like to see
happen

Rossen: Where does this leave us?
jensimmons: Sounds like someone's going to find something out
AmeliaBR: I think it's great, we're leveraging something that
already works, but I think I agree with the arguments
there's too many cases where things can get messy for
repurposing
AmeliaBR: If browsers implemented the attr() function that maps
values to lengths, ... any image, grab these values,
put them together, here's the ratio
AmeliaBR: Not sure if there's utility if no one's has implemented it
yet
<jensimmons> +1 to what AmeliaBR just said
<jensimmons> maybe that could even be included in a project called
CSS Remedy
TabAtkins: I feel like there's just more discussion, but in the way
of being explicit with cases and approaches, and I don't
know if I want to spend time trying to nail it down

fantasai: There are advantages of using existing attributes. Like
for images in pages already out there, we get the faster
fantasai: No updating cms, no html file updates, it would let
browsers hook into it via current functionality
jensimmons: There's 100,000s of sites that put height and width on
images in the CMS already. Then in their code, put
width: 100%; height: auto in their CSS. Decade of work
is built that way, and likely aren't maintained
jensimmons: Quick way to boost all sites by re-using existing attrs
jensimmons: Don't get deep into picture element, ..., hey this is a
performance thing, but it back in and it'll be faster
jensimmons: Other proposals will use it for be used for simple and
complicated things, and some it'll be too much
fantasai: Historically, we've asked users to put weight and height
on images for performance, all the way back into the 90s,
and we'd be hooking into that advice. This proposal hooks
into existing content and knowledge better. It won't only
work on new things developed by people who keep up with
latest tech.

TabAtkins: Happy to do more discussion, but not confident enough to
decide now, or for us.
chrishtr: Maybe we could break out and talk about it?
chrishtr: I don't think I fully understand, and I'd like time for
that

Rossen: Okay so, I didn't hear that say the HTML width and height
attributes is the worst idea I've ever heard, we shouldn't
do it
Rossen: I also didn't hear we shouldn't think about the intrinsic
aspect ratio, because it'll just work
Rossen: TabAtkins has committed to work on this fully
TabAtkins: Chrome people will be working on this
Rossen: Kidding aside, we'll close this issue for now. Thanks for
introducing it to the working group, and making it an actual
proposal

Rossen: I think there was another bit in this, which was css
property, which will then have to map using either the
height or width attributes, as a ratio, or whatever else is
Rossen: I think the property can be discussed at a later point, or
is this something you want to discuss later today
fantasai: It's already in the draft, we resolved to add awhile back
https://github.com/w3c/csswg-drafts/issues/333
https://drafts.csswg.org/css-sizing-4/#aspect-ratio
jensimmons: So this discussion about not doing other things in HTML,
jensimmons: There will be more to talk about aspect-ratio with
min-height and min-width
jensimmons: There is a question of: do we put in what's there
already in the draft, support for ??, whether it's
happening in the UA style sheet, we do have the ability
to grab information about height and width
jensimmons: Might be right in between, and I think we should do what
Rossen mentioned
Rossen: Great point, thank you. Before we move on

AmeliaBR: I have a question: it's not being proposed by a web group.
Before we get a css spec, we need to get that moving up
into the HTML wg, so it's outside our scope, so long as
it's going through process and getting standardized.
chrome pushed it without standardization, we need to make
sure that happens
TabAtkins: Definitely should be in wicg - we'll get it there

CSS Inline
==========

Should first/last baseline values of vertical-align belong to
alignment-baseline or separate longhand?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/861

dauwhe: No opinions
fantasai: Ditto
fantasai: This issue keeps coming up because I don't have any points
in favor or against either options, and I'd like to hear
why we should pick one over the other
fantasai: Do we have the board, do you want the [..] baselines,
[fantasai explains the problem]
fantasai: When aligning inline boxes to each other, you first match
corresponding baselines, then you shift if there's an
offset
fantasai: Once one of those has multiple lines of text in it,
do we use first or last? We wanted to add keywords to
choose.
fantasai: Do we put it in it's own property,
fantasai: Or do we merge it with alignment-baseline, which chooses
the type of baseline (alphabetic, mathematical,
ideographic, hanging)?
AmeliaBR: Reminder: long hands exist for legacy compat. So svg had
vertical-align...they describe the same functionality but
behave slightly differently
AmeliaBR: ..., adding new features to the longhand, when it's just
for compat, seems questionable. Also, not sure how first/
last would work in SVG. I don't see benefit there
[fantasai outlines things on the easel]
fantasai: We can't just add values to the vertical-align shorthand:
they need to be part of a longhand, too. So if there's a
reason to choose one over the other, it'll help us resolve
AmeliaBR: New property may not be used

fantasai: Related issue: from the MATH ML folks, they want to take
the baseline not from the first or last item, but from a
specific item
[See https://github.com/w3c/csswg-drafts/issues/1339 ]
fantasai: So that ties in a little bit with this. We don't have a
proposal, but we have an idea we should do it. So that
might tie into we end up with another that helps us solve
this as well.

AmeliaBR: I suppose the value of a new property is that vertical
align is already supported with current functionality
AmeliaBR: you may end up with duplication anyway
fantasai: Does anyone want to think about it more, or push it off to
later?

dbaron: I can imagine there's reasons you want them separate,
unknown how important they are. Consider multiple
languages [...]
fantasai: Alright, we have a reason, we can resolve the issue!
dbaron: I'm not convinced anyone will want to do this, but it does
seem like a good thing to do
dbaron: You might want to set alignment-baseline as a function of
the language without messing with the first/last choice set
for other reasons
AmeliaBR: Resolve to make a new longhand property
astearns: We figure the name out later
fantasai: No matter how silly, make suggestions in IRC, we'll
evaluate later
<astearns> best-baseline
<dauwhe> good-baseline | better-baseline | best-baseline
<TabAtkins> west-baseline
<AmeliaBR> baseline-line

Rossen: Okay, any other opinions that can top dbaron's?
Rossen: Anyone object to dbaron's proposal? or oppose?
Rossen: No objections. Resolved.
astearns: So, dbaron, could you put your actual suggestion into
resolve line
dbaron: The question was a boolean, do we want a separate prop or not

RESOLVED: We'll add a separate property for this

astearns: Great
fantasai: Thank you

Houdini <3 Text
===============
Scribe: emilio

Houdini and text layout
-----------------------
github: https://github.com/w3c/css-houdini-drafts/issues/854

myles: So, houdini has a lot of stuff, and I think everything is
things that browsers do already, which is cool
myles: There's one of these things that is not in houdini so far,
which is text
myles: so there's a chance that authors are going to want text layout
myles: There's a lot of ways this could go. Text is complicated, and
different to other parts of houdini, in the sense that (a)
it's pretty easy to get wrong and (b) if it is, users will be
misled and confused
myles: It's easy to get it wrong when things like how BiDi works
should work by default, we don't want authors to have to
remember how to do these
myles: There's a bunch of things like that listed in the issue
myles: so I wanted to discuss how should we approach such an API to
avoid causing pain

myles: A strawman proposal just to get the discussion started would
be a region-like API, where your content flows from one box
to the other, and regular CSS properties apply in that box
myles: That'd be very high level. Another approach would be to
expose glyph indices and fonts and let the author place all
of them
myles: I think that'd be bad
<fantasai> +1 to that being bad
myles: So, there are these two extremes, these high-level things,
and there's this low-level thing which we can agree it's a
bad idea. There's a range in there that we should figure out

AmeliaBR: (summarizing her comment in the issue)
AmeliaBR: (https://github.com/w3c/css-houdini-drafts/issues/854#issuecomment-459146355)
AmeliaBR: There's a lot of steps, like [...], that we need to break
this down into.
AmeliaBR: Within all the individual steps which happen during text
layout, we need to figure out which of them authors want
to customize. One of them could be justification
AmeliaBR: other things like bidi unicode stuff we don't want to ever
expose
AmeliaBR: We could expose (though maybe trickier) glyph selection
(sounds scary, but there's lot of fun stuff you could do
with OT glyph selections instead of having to create a new
font because you want to create a space-maximizing layout)
AmeliaBR: That's something that people may want but that is easy to
get wrong / break
AmeliaBR: Also, the steps are very dependent on one another, so we
need to come up with a nice model of the data that goes
through the pipeline if we want authors to insert their
custom stuff
fantasai: This is not just a sequential pipeline, some of the steps
interact with each other. An excellent line-breaking
engine will account for glyph selections and such
fantasai: so you can't just break that up into ordered steps

iank: I think we agree in spirit with myles, we don't want to get
into the business of bidi resolution or glyph selection or such
iank: We may want to get smarter about where to break and such, but
not atm
iank: The current model in the spec is a box where you run layout
giving the available width and you get back an inline box /
line box fragment
iank: You can re-request that if the resulting height is too big for
iank: Some layouts require the available width to change on a
per-line-box basis
iank: We want to prototype that
myles: So, I also agree that we mostly agree
myles: The idea of giving available width works well if the area has
vertical end, but if you're not a perfectly vertical
container it doesn't, it's not clear how much we care for
shapes in Houdini
iank: We care about shapes a lot
iank: In our engine we do at most two layout passes to avoid shapes
iank: which sort of fits in this model
myles: I think doing two layouts is unfortunate, describing geometry
would be nicer
iank: That'd be difficult, a lot of the use cases that devs want to
place a line depending on how the previous line has been laid
out
iank: I think describing all the geometry upfront would be limiting
iank: One of the examples we want to work is an arbitrary line grid
iank: The avail width of the next line really depends on the line
height of the previous line box

dauwhe: My industry is very interested in using Houdini to improve
justification / hyphenation, since the browsers have
different requirements

florian: I share the concern that this is important and hard to let
people do a lot of random stuff
florian: but Dave shared examples about hyphenation and
justification, and there are many more of the same kind of
when you consider i18n where a lot of effects needs a lot
of low-level access
florian: For example, Japanese people may want to increment distance
between some glyphs or such
florian: or implement stuff that isn't in browsers yet
florian: The approach of getting line boxes doesn't get far enough,
but I'm not sure how to get far enough but not being
dangerous
myles: You're right, but we have competing desires, letting authors
implement nice effects, and making pages legible, the latter
has been historically more of a priority
<fantasai> +1 to ensuring legibility

fantasai: Side comment, about justification and the model that is in
Houdini, which I agree is the right one to get started.
For justification would it make sense to return the
fragment without filling the available width, but also let
the user set it to be wider and that'd trigger
justification and alignment
fantasai: That way I can see where it fits much more easily, and
position it more easily
fantasai: and justification and alignment properties would work the
same way it works when you place it in a bigger size.
Justification would still be in control of the user-agent
myles: dauwhe, when you said for example you wanted to improve
justifications, is ^ what you were referring to?
dauwhe: I think we want more

Rossen: Thanks for bringing the issue, and I'm glad it's getting
more and more traction. The one common theme that I see so
far is that we are trying to get the "custom" part of layout
out of custom layout. Everything that's been discussed so
far how to force people to do the thing what we're already
doing and tweak it a bit here and there
Rossen: The nice thing of custom layout is that we're not giving
restrictions for where people to position boxes in the block
layout case, but when it comes around text we through our
hands in the air and say it's too hard, and I don't agree
with that
TabAtkins: We have existence proof that every single custom layout
has done bidi wrong.
Rossen: It seems to me that we're talking about levels of
customizability
Rossen: one where you expose bidi and shaping at every breaking
opportunity, the other where you give it a box and we'll do
the layout inside
Rossen: I'd be interested to go and explore the options in the
middle which would allow most custom layouts that people want
Rossen: so that we're still not insisting on that rigid one box
Rossen: We're also assuming that we're doing inline layout the way
browsers do it now, but maybe my lines are spiral, or I want
to go on top of floats
Rossen: Let's not try to take the custom part of layout outside
of css

dbaron: I just wanted to bring up another use case that hasn't come
up today
dbaron: I think having a low level API is very important for
minority languages
[general nodding]
dbaron: Gecko has shipped graphite support
<dbaron> https://en.wikipedia.org/wiki/Graphite_(SIL)
dbaron: One of the things it does is let languages that have shaping
requirements that aren't in browsers do it in fonts instead
dbaron: Another approach for this would be a low-level JS API using
houdini
<dholbert> (I believe "glat" is one of these graphite font tables
that dbaron is referencing)
<dauwhe> "For example, it may be the case that a minority language
is tonal, while the national language is not, and the
orthographic solution involves using the standard writing
system with some extra diacritics to indicate tone. Or the
minority language might have a set of sounds characterized
by a certain linguistic feature, such as aspiration or
breathiness, that are not present in the national language,
and the desire is to add to the standard orthography a set
of variant characters to represent these variant sounds."
dbaron: I think that's a potential real use case

skk: From Japanese digital books perspective, more precise Ruby
would be amazing
skk: We'd like more control over ruby text positioning
<xfq> more than what ruby-position/merge/align currently provides?

dauwhe: Responding to the philosophical point, being able to explain
and expose all the platform features?
Rossen: It is, what I'm saying is, let's not prevent that
Rossen: So that we can avoid limiting the inner pinnings of how
things work. Said that, we want to open the engine so that
we don't need to implement all the stuff people want, that's
the fun part of it.
Rossen: We've never said "and we don't want to let you do this
because it's hard"
Rossen: why?
myles: If your layout is quite not what the author intended, the text
still exists. For box layout, bad layout is wrong for
only for some
fantasai: It may be because somebody typed something you (the Houdini
author) didn't expect
fantasai: and you didn't care of thinking of those users
fantasai: and those users are our users
Rossen: That's my problem, those users are going to complain to me

koji: From my POV I think "don't do bidi and don't you your own
thing" is more "we want to start from simple things", and as
we can confirm it performs properly and works we can extend
further
koji: but I'm not very confident that JS running through glyphs is
performant enough, so box-level layout seems simpler
koji: so re. Rossen's point, we're not against, but we want to start
from the simple thing

AmeliaBR: I agree with Rossen and dauwhe, the point of Houdini is
being able to tweak one of the little things the browser
does without having to re-implement the browser, and we
want to let authors do what they want
AmeliaBR: You can do some sort of custom layout with SVG, but
probably badly. We should let authors do what they want
without forcing to reimplement what they don't want to
tweak
AmeliaBR: I think we should prioritize our work to start with the
safest things to change and isolate
<dauwhe> I want to tweak what the browser does, not build my own
rendering engine
<skk> +1 to dauwhe
<heycam> Agree with AmeliaBR -- we should bias towards coming up
with APIs that allow users to benefit automatically from
the browser implemented bidi, complex text shaping, etc.
features that the author doesn't want to reimplement
<heycam> make it harder for them to accidentally not support those
things

florian: So, I think when we say is "this is too hard", this is not
saying that devs in this room are smarter than all of them.
But very little people have resources to implement all the
complexities right
florian: Very few people have the business justification to deal
with all languages
florian: Minority languages is where this is interesting and
dangerous
florian: The low level things that enable minority languages to work
on the web, are also what enable companies to write
western-only layouts that don't work with other minority
languages that browsers support today
florian: In the process of creating an api that's good enough to
support minority languages we'd have created the chance of
Chinese pages where you only can write in Chinese, or
English pages that allow you to only work in English
florian: So if you force people to rebuild text-layout itself, they
will not do the right thing, and we'd have disabled some
florian: So I'm more on the side of caution, and making sure that
everything we add to this API is a thing we can tweak
<fremy> very good point florian
florian: And yes, people will break stuff for their own customers,
but we'll also break the fact that the web is multilingual

fantasai: I think koji and AmeliaBR and florian said everything I
wanted to say

myles: Most of my job is fixing bugs that the text experts in the
piece of software they created because they only spoke English
myles: There's tons of places in WebKit where there are assumptions
because it was coded by English-only speakers
myles: I agree we should investigate the middle parts in the
spectrum, but I think we disagree with the criteria for
success
myles: I think text is different, where if you get it wrong it may
work for you but not for your users
myles: An approach where we take everything the browser does and
making it scriptable is not the highest priority
myles: Raising use cases is a good way to prioritize, the idea of
tweaking specific parts of the browser is great and makes
total sense
myles: Picking specific use cases and filing in holes is probably
the right idea, creating a low level platform and tell people
to write it yourself is probably not
<florian> +111!1!1
<fantasai> myles++
myles: Minority languages is a very interesting case, apart from
Graphite we also have a similar thing with AAT
myles: I wish we could find a way to solve that problem in a way
where safety is preserved

Rossen: I see a lot of passion and interest, zero reasons for us to
stop working on this. A lot of things said will hopefully be
taken into account as we move forward. One thing that I
wanted to make sure that the record reflects what I said.
Rossen: I wasn't suggesting to start exposing the far end, like
glyphs
Rossen: but as we go forward we should start walking towards the
end, I just want to ensure that we don't preclude us from
going forward
Rossen: Myles, is there something that you think it wasn't discussed?
myles: I think the next thing is gathering use cases, so we're done

iank: To try to wrap up, is there anything inside of the current
version of the spec that particularly scares you?
myles: My biggest concern is about encouraging authors to do layouts
in loops
myles: where they try over and over, but I understand such an
approach allows for dynamic use-cases, so I guess the
question is to which side we fall
iank: I think we agree, but we don't want to limit people which is
why we chose this approach
myles: We heard a lot of use-cases in this discussion that aren't
covered by the API, so maybe it's too early to create APIs
Rossen: We have a proposal and we have a lot of discussions, let's
not say yay or nay

dauwhe: I wanted to make a point regarding the responsibility about
us making software for our use case vs. browsers
dauwhe: We publish English and Spanish, I don't think there should
be obligation for us to handle vertical or rtl
* dauwhe admits that some of our books have snippets of Arabic,
Hebrew, Japanese, Chinese, and MathML :)

AmeliaBR: I'm glad myles brought this discussion
AmeliaBR: One thing that myles and fantasai said is that text was
AmeliaBR: I don't think that's true, there are lots of ways you can
break content in another ways
AmeliaBR: I agree with Rossen that the developers of the websites
are responsible for being user friendly and would be the
ones to pay the price. I don't think that this proposed
ways which could break websites are worse that other ways
to break stuff with CSS
fantasai: I think it is actually worse
<astearns> I disagree with AmeliaBR's comment, and agree with
content inaccessible

<fremy> iank myles: I do have some ideas on how to progressively
enhance the current api to cover more cases that have been
discussed here without starting from scratch and would like
or in the github issue if not.

Rossen: This is not the end of the discussion, but some of the
starting points
Rossen: We need go back and work more on this, we should keep
participating passionately
Rossen: Next steps is engaging in the specs
Rossen: So go help iank ;)
iank: I'd love that

CSS Text
========

Allow for paragraph-level line breaking
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/672

myles: Similar to houdini, there are lots of different ways to do
line-breaking. Houdini solves some of them. Other ways people
want to do line breaking are some fancy book-like
line-breaking
myles: ine-breaking on the web is greedy, and doing something
slower but higher quality is a longstanding request
myles: I proposed a value for this, which got to the spec and then
got removed because of lack of consensus
myles: I'd like to see which opinions for this
myles: it's a very high-level switch
<xfq> will the behavior be UA-defined?

florian: I want to know which one is the editing value
florian: I want one of the values to be stable when you type
<astearns> default is 'wrap' which is stable
myles: Right now the default is stable in every browser
florian: Not for print [PDF renderes like PrinceXML and AntennaHouse]
myles: You don't type in print preview
myles: I don't think you need another value, we already have it
florian: I think there should be a stable value
myles: I think reflecting reality and saying that auto should be
stable is fine
fantasai: I think the initial value should allow the UA to do
whatever

dauwhe: If the property is added to iBooks I'll add it everywhere
fantasai: I think iBooks should just add it to its default UA
stylesheet
[ compat? ]
dauwhe: I think you want to change it in existing books too
dauwhe: Having the text break better is just going to be a win

eae: I think this is a great idea, I'm a bit concerned that if we
don't define what pretty does we'd get interop issue, so we
should try to explain what pretty would do
<xfq> https://github.com/w3c/csswg-drafts/issues/803 is the related
issue for the algorithm ("pretty")
myles: In the issue I listed a dozen different criteria
myles: So describe it explicitly is probably not realistic, do you
think agreeing on the goals is fine?
eae: yeah, I think that's ok
fantasai, dauwhe, myles: I think it's important to _not_ get compat
<AmeliaBR> There will always be perf trade-offs, so that it makes
sense that a print book will get prettier pretty
results than a browser on a low-CPU device.

heycam: I was going to make eae's point, though maybe I'm a bit more
worried about the compat impact, I don't we can change the
default algorithm because of compat, why wouldn't that
happen with pretty?
astearns: The current algorithm is not that interoperable
myles: Also, this is an opt-in
heycam: Once we have this, why would we not expect authors to just
use it all the time. Why would they not do that?
myles: It's the same answer for text-rendering: optimizespeed vs.
optimizelegibility
fremy: It's mostly useless
myles, AmeliaBR: it's not
heycam: I don't think people will think about speed, and many people
will just use it without thinking about it, having a perf
impact
astearns: I think that's the reason for the auto value
astearns: so that the UA can change it
heycam: I'm skeptical about changing line-breaking (by default)
myles: I'd like to keep the discussion less about the existence of
auto

dauwhe: I think there are a lot of trade-offs. Browsers are optimized
for speed right now, and taking any step to opt in to better
systems is going to be great regardless of interop
dauwhe: text layout is so sensitive that there's never going to be
interop

myles: I want to resolve to put this value back in
Rossen: Objections?
florian: I want to make sure we have the three values, including
stable.
fantasai: I think we should rename it, but no objection
fantasai: I'm a bit concerned that we are going to add another
switch that does nothing
fantasai: but if people feel strongly I won't object
fremy: not an objection either but we need a better definition on
what it does

RESOLVED: Add the value back in

myles: There are three values: auto, balance and this new thing
fantasai: I object to the multi-line name
myles: Proposals?
fantasai: 'pretty' sounds good to me
fantasai: It's what we used to discuss it here



Source: Murray Sargent: Math in Office • MurrayS3 • April 30, 2019 • Permalink

The post Using MathML-Based Speech to Edit Math in Different Math Models discusses the need to navigate math zones in the edit space rather than in a MathML copy of the edit space. This need arises for editing since the navigation location must be synchronized with the edit selection. It’s also important for defining the selection bounding rectangles even if editing isn’t allowed. The present post compares the math-zone edit navigation in Microsoft Office apps to the structured child/parent/next/previous tree navigation provided by MathPlayer and other systems. Combining both approaches results in rich navigation and editing experiences for blind and sighted users alike.

The OfficeMath math zone represents math as a “flattened” tree, in which nested math objects such as fractions and matrices have start and end delimiters. This allows character navigation to traverse every character in a math zone. Typing the → key at the start of a fraction moves into the numerator. Typing → at the end of the numerator moves into the denominator. Typing → at the end of the denominator moves out of the fraction. The → and ← keys let you “escape” from a math object (go to the next higher level in the tree) and to enter a math object (go down a level into the tree) as well as moving past characters.

Typing Ctrl+→ moves by siblings. So, typing Ctrl+→ at the start of a fraction moves past the fraction to whatever follows the fraction. A Ctrl+→ at the end of the denominator moves out of the fraction, so like the → key, Ctrl+→ can escape from down inside an object (go to the next higher level in the tree). But it cannot go down into a lower level of the tree. Both Ctrl+→ and → leave the selection as an insertion point (IP), ready for inserting more characters and math objects. Shift+Ctrl+→ and Shift+→ select the next object or character. The Ctrl+← and ← keys work the same ways but move toward the start of the math zone. (Note that Word hasn’t yet implemented this Ctrl+→ and Ctrl+←behavior, but OneNote and PowerPoint have).

All eight editing hot keys ([Shift+][Ctrl+]←/→) move out of the math zone when they come to the end of the math zone. The keys are usually geometric but are logical as well in that → moves from the end of a numerator to the start of the denominator. Such movement isn’t geometric since the motion is down and to the left rather than to the right. At any time, the user can enter and delete characters. If the selection is nondegenerate, entering a character replaces the selection and results in an insertion point (IP). If the selection is already degenerate, e.g., an IP following Shift-less key motion, the character is entered at the IP.

With OfficeMath speech, you can use this kind of navigation while entering and editing equations with a keyboard. You don’t need to see the screen. As far as I know, the Office apps Word, Outlook, PowerPoint, and OneNote are the only major apps that let blind users enter and edit equations using only speech and a keyboard.

Contrast these edit movements with structured Parent/FirstChild/LastChild/Next/Previous tree navigation. This structured navigation always selects a character or object unless it ends up inside an empty argument. At the start of a fraction, FirstChild selects the numerator and LastChild selects the denominator. If the numerator is selected, Next selects the denominator. But unlike Ctrl+→, another Next does nothing since a fraction only has two arguments. To get out of the fraction, you enter Parent and then Next to go to the next sibling of the fraction.

If an argument is only partially selected, then Next goes to the next sibling in the argument. If the last sibling in an argument is selected, Next does nothing. Entering Parent selects the whole argument and another Parent selects the math object. The highest level in the tree is the whole math zone and structured navigation commands won’t move outside the math zone.

If a selection consists of multiple characters, e.g., the “sin” in the math function object “sin 𝑥”, FirstChild selects the ‘s’ and LastChild selects the ‘n’. Next/Previous select the next/previous character, respectively, unless the last/first character is selected (in which case Next/Previous do nothing). In this way, you can examine every character in the math zone using structured navigation.

Possible hot keys for Parent, FirstChild, LastChild, Next, and Previous are Alt+↑, Alt+↓(or Alt+Home), Alt+End, Alt+→, and Alt+←, respectively. Since these differ from [Shift+][Ctrl+]←/→, both kinds of navigation can be used together. It’s desirable to have corresponding navigation buttons on refreshable braille displays.

While structure navigation takes more keystrokes than edit navigation, it’s valuable for understanding complicated equations, particularly if you cannot see the equations easily and are navigating with the help of math speech.

## Conclusions

Ideally for editors like Word, Outlook, PowerPoint, and OneNote, both kinds of navigation would be available. If using structured navigation, you want to enter a character at the end of the current selection, type → to collapse the selection to an IP at the end and type the character. If you want to enter a character at the start of the current selection, type ← to collapse the selection to an IP at the start and type the character. With these techniques, visually impaired users can have a rich navigation experience and all users can enter and edit equations easily.

## Re: W3C TPAC 2019 - Will your Community Group meet in Fukuoka?

Source: public-mathonwebpages@w3.org Mail Archives • Alexandra Lacourba (alex@w3.org) • April 04, 2019 • Permalink

[This e-mail is bcc'ed to all public lists of existing W3C Community
Groups]

Dear participants of the W3C Community Groups,

Please fill in the form below if your Community Group wants to meeting
during TPAC2019, before *12 April 2019*:

https://www.w3.org/2002/09/wbs/1/CGsTPAC2019/

For the W3C TPAC 2019 Event team
Alexandra Lacourba
W3C Global Event Coordinator

On 03/07/2019 21:21, Alexandra Lacourba wrote:
>
> [This e-mail is bcc'ed to all public lists of existing W3C Community
> Groups]
>
> Dear participants of the W3C Community Groups,
>
> Once again, the Community Groups have the possibility to meetduring
> TPAC2019 which willbe held in Fukuoka, Japan at the "Hilton Fukuoka
> Sea Hawk"[1].
>
> TPAC 2019
> 16 - 20 September 2019
> Fukuoka, Japan
> https://www.w3.org/2019/09/TPAC-template/Overview.html We ask you to
> start discussions to determine whether and when yourgroup(s) would
> like to meetduring this week. Please complete the following
> questionnaire by 12 April 2019:
> https://www.w3.org/2002/09/wbs/1/CGsTPAC2019/ W3C Community Groups can
> hold 2-hour meetings on Monday, Tuesday, Thursday, Friday. The
> Available slots willbe: 8:30 - 10:30 10:30 - 12:30 13:30 - 15:30 15:30
> - 17:30 We willbe able to accommodate 4 meetings per day, so 16 over
> the entire TPACweek. Outside of their Community Groupmeetings, non
> W3C-Member CG participants may attend as observers the Working and
> Interest groups meetings who accept observers, as well as the
> Technical Plenary Day willbe held on 18 September from 08:30-18:00.
> There will be registration fees to offset a portion of the meeting
> <w3t-tpregister@w3.org <mailto:w3t-tpregister@w3.org>>. We look
> forward to another successful meeting!
> For the W3C TPAC 2019 Event team
> Alexandra Lacourba
> W3C Global Event Coordinator
> [1]
> https://www3.hilton.com/en/hotels/japan/hilton-fukuoka-sea-hawk-FUKHIHI/index.httm
>

--
World Wide Web Consortium                       http://www.w3.org
W3C/ERCIM - 2004 route des Lucioles - Sophia Antipolis 06410 Biot - FR
Voice: +33.4.92.38.50.76                                        Fax: +33.4.92.38.78.22


## RE: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Sina Bahram (sina@sinabahram.com) • April 04, 2019 • Permalink

Will do as I get a chance.

President, Prime Access Consulting, Inc.

Phone: 919-345-3832

https://www.PAC.bz

Personal Website:  <https://www.sinabahram.com> https://www.sinabahram.com

From: Charles LaPierre <charlesl@benetech.org>
Sent: Wednesday, April 3, 2019 3:53 PM
To: Sina Bahram <sina@sinabahram.com>
Cc: public-mathonw. <public-mathonwebpages@w3.org>; George Kerscher <georgek@benetech.org>
Subject: Re: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Hi Sina,

I think it would be good for you to review/comment on these two pull requests they will be discussing tomorrow.

* https://github.com/w3c/aria/pull/923
* https://github.com/w3c/aria/pull/924

Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Skype: charles_lapierre
Phone: 650-600-3301

On Apr 3, 2019, at 12:51 PM, Sina Bahram <sina@sinabahram.com <mailto:sina@sinabahram.com> > wrote:

I’m at a conference, so my regrets on this, but I’m really passionate about this topic. Please let me know if there’s questions I can answer or things I can comment on/provide feedback for.

President, Prime Access Consulting, Inc.

Phone:  <tel:919-345-3832> 919-345-3832

<https://www.pac.bz/> https://www.PAC.bz

Personal Website:  <https://www.sinabahram.com/> https://www.sinabahram.com

From: Charles LaPierre < <mailto:charlesl@benetech.org> charlesl@benetech.org>
Sent: Wednesday, April 3, 2019 3:04 PM
To: public-mathonw. < <mailto:public-mathonwebpages@w3.org> public-mathonwebpages@w3.org>
Cc: Sina Bahram < <mailto:sina@sinabahram.com> sina@sinabahram.com>; George Kerscher < <mailto:georgek@benetech.org> georgek@benetech.org>
Subject: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Hello everyone,

I wanted to let you know that in tomorrows ARIA WG call the topic of new Braille Properties added to ARIA will be discussed.

Unfortunately I can not attend as I am presenting at that time, but I hope those who joined the ARIA WG from this group will be able to attend.

Here is the agenda Item and information regarding the call which is tomorrow April 4th at 10AM Pacific / 1PM Eastern

* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Time:
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1> https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1

* New issue triage:

<https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+
* New pull-request triage:

<https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+> https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+
* Quick status check of active role-parity issues:
- fieldset/legend:  <https://github.com/w3c/aria/pull/911> https://github.com/w3c/aria/pull/911
- label:  <https://github.com/w3c/aria/pull/886> https://github.com/w3c/aria/pull/886
- time:  <https://github.com/w3c/aria/pull/895> https://github.com/w3c/aria/pull/895
* Quick, straw-poll-level discussion:
- Keep children-presentational on math role?
<https://github.com/w3c/aria/issues/425> https://github.com/w3c/aria/issues/425
- Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
<https://github.com/w3c/aria/issues/667> https://github.com/w3c/aria/issues/667
* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Previous Meeting Minutes:
<https://www.w3.org/2019/03/28-aria-minutes.html> https://www.w3.org/2019/03/28-aria-minutes.html

IRC:  <http://irc.w3.org:6665/> irc.w3.org:6665 #aria

Call Details:  <https://www.w3.org/2017/08/telecon-info_aria> https://www.w3.org/2017/08/telecon-info_aria

To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number:  <tel:+1-617-324-0000;641%20291%20851> +1-617-324-0000
<tel:+1-617-324-0000;641%20291%20851> Access code:641 291 851
Mobile Auto Dial: <tel:+1-617-324-0000,,,641291851%23> +1-617-324-0000,,,641291851#



## [CSSWG] Minutes Telecon 2019-04-03 [css-easing] [css-env] [css-text]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • April 04, 2019 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

Easing functions to CR
----------------------

- RESOLVED: Ask to take Easing Functions to CR once these editorial
changes [for Issue #3205] are made.

CSS Environments
----------------

- The proposal to get document title using css env() (Issue #3685)
met with skepticism from the working group. In order to proceed
with this approach the group needed to see more evidence that
this would solve most of the potential use cases either as is or
as an enhancement to the original proposal or that there are
other document properties that would want to have the same
functionality as proposed for document title. Interested parties
will continue to investigate the use cases.

High Contrast Spec
------------------

- Rossen wrote up a proposal to bring the Edge high contrast
behavior into CSS specifications. There was debate on where this
work should go so the group will review it this week and then
decide where this should be put in the official CSS repo.

CSS Text
--------

- When looking into a new property for MathML a larger question was
raised concerning if the stated design of text-transform when
applied to something like a screen reader needed to change in
order to align with current implementations (Issue #3775:
text-transform's design, intent and reality resolution)
- It was questioned if the difference is actually as large as the
issue indicated since the text-transform is not changing the
fundamental structure of the document and cannot be treated as a
core part of the document since some view modes remove the CSS.
- text-transform contains many possible values so there will be a
need to either split this into more than one property or spec
how the properties differ as there are different solutions per
property.
- Other groups will need to be brought into this conversation to
ensure that the decision reached is correct for a wide audience.
CSSAAM was specifically called out at a task force which should
discuss this.
- A possible way forward is to expose detail of transform and
original content at the same time instead of only exposing the
transformed content so that screen readers can make a smarter
decision then they can today.
- Discussion will continue on the issue.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0000.html

Present:
Rossen Atanassov
Amelia Bellamy-Royds
Brian Birtles
Oriol Brufau
Simon Fraser
Dael Jackson
Brian Kardell
Peter Linss
Myles Maxfield
Cameron McCormack
Ian Pouncey
François Remy
Melanie Richards
Florian Rivoal
Alan Stearns
Greg Whitworth

Regrets:
Tab Atkins
David Baron

Scribe: dael

astearns: We should get started
item #2
<Rossen> Thank you!
astearns: Anything else people would like to change?

Easing functions to CR
======================

birtles: I don't have anything that needs to be added. Ready to go.
astearns: No more edits?
birtles: Not that I'm aware of
astearns: This isn't the first time to CR so there's not much
besides deciding to
birtles: Good point

<fantasai> only open issue is https://github.com/w3c/csswg-drafts/issues/3205
<fantasai> which is editorial
<fantasai> significantly editorial, but still editorial :)
birtles: That's [the open issue] probably worth doing
fantasai: Worth doing but not block CR. Nothing technically wrong
with document and won't effect impl. Editorial that can be
done during CR. We should signal this spec is done and
people should impl and deploy
astearns: Not concerned with review before this change?
fantasai: This change is about making spec easier to reuse in area
that need timing mapping but aren't animations and
transitions so I don't think that will make a difference
to implementations. I don't think it needs to prevent CR
astearns: birtles what do you think? Change in first or CR update?
birtles: Can I do the change today and get a resolution?
fantasai: Sure. I just didn't want to wait for some indefinite years
AmeliaBR: We're agreeing to change words timing function to easing
function and relating edits? That's all you're changing?
birtles: Yeah and all the descriptions that say these can be applied
to animations to say things like animations
florian: But it's a generalization of sentences, not a deep re-write
birtles: Yep
florian: Then I see no problem resolving before edits
<Rossen> Ship it!

astearns: Objections to Take Easing Functions to CR once these

RESOLVED: Ask to take Easing Functions to CR once these editorial
astearns: Thanks birtles to getting to those edits

CSS Environments
================

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

astearns: This was introduced last week, discussion of scope and
that it's not useful in all situations. What else did you
want on this florian?
florian: Not much to add, just cut by clock. I think it would be
useful to be able to access doc title from env. tantek
pointed out this is not powerful enough for general problem
florian: The generic solution pretty much calls for regions, though.
This is much simpler and solves some cases so I think it's
good to do. I recognize it's not a full solution

AmeliaBR: One thing is that CSS has a mechanism for what florian
wants in GCPM module. That is a much more complex and
nuanced system of pulling bits of text from a heading and
reusing in other parts of layout.
AmeliaBR: I don't know if there's any interest in getting that
cleaned and into browsers or if we want the quick win
florian: I think we should do this regardless. Other is slightly
more powerful, but it's still plaintext only and only works
in paged margin boxes so if you don't paginate you get
nothing. So this is less expressive but more applicable and
simpler
florian: I was discussing in context of Viviostyle and there were
cases to not invoke the whole complex process, just I want
the title and put it there.
florian: I don't think I wouldn't be pushing if we didn't have nth
function. We have the mechanism so this is exposing a value
through it

Rossen: Main motivation is in paginated scenarios?
florian: Commonly seen in paginated but this doesn't have to be
restricted. With nth works everywhere. If you want
something pagination-like you can invoke things like this
Rossen: Just curious use cases
florian: Same type of layout as paginated media but actual
pagination with css level of page is one thing, but
something that visually looks like pages is another. I'm
aware of wanting to do things that look page-like is a use
case

fantasai: Concern is this is too simple for what's wanted. If we go
in this direction we'll be too limited. Don't know how
urgent this is. If it's not something we have to do really
soon might be worth trying to sort out more generic that
solves this class of problems rather then special casing
this
<bkardell> it seems like we have maybe a lot of things that are
almost related to this
florian: Don't think particularly urgent. In that sense okay with
punting. More generic is way more complicated. I don't see
this as trying to solve whole problem. If want to expose
more through nth it seems reasonable.
fantasai: If it would solve 80% use cases it's worth, but seems
closer to 20% so I don't know it's worth introducing a new
pattern if we're not planning to pursue patterns
florian: I think for ebook this would solve most of the problems.
Depends on how you say 100%
fantasai: But they also want page number and chapter
florian: But in ebooks, chapters are HTML files, so, it is
sufficient for that case. It is simple

bkardell: I'm interested in this use case. I feel like I would like
to talk to florian a bit to understand more off call. If
it only can give you the plain text would you not be able
to achieve most by setting a custom prop for now? I think
we said it's just plain text so the 20% of use cases
wouldn't they be served equally as well with a css custom
property?
astearns: It's content duplication and you run the risk of out of
sync. This is slightly better then duplicating in custom
properties
florian: ebook with 25 chapters if you use nth you pull from doc,
custom prop you have it for each chapter
bkardell: That's what I'd like to understand more. They're not input
manually, they're built.
bkardell: Would mean multiple rules
astearns: Prob enough for now. Not hearing enough to pursue for now.
Maybe if we saw use of custom properties for this could
make better solution

florian: I'm hearing sufficient skepticism we're punting
AmeliaBR: florian worth looking if there are similar doc properties
where worth a common mechanism. Doc URL or parts of URL
might be similarly useful. Have permalink on a file. I
haven't looked and it's a matter of looking at what people
are actually using to insert into the generated content
florian: We can think of a few more, but that's enough for the topic
today. We can go offline

High contrast spec
==================

Rossen: I don't have a github issue for this
Rossen: I had an action after the F2F to go and put what we had in
an explainer and add more spec text to introduce high
contrast feature as is defined and working inside of edge
and IE
Rossen: The pretty print of the HTML is linked above
Rossen: Request is to move this out of my github and into CSSWG repo
as one venue or pursuing this. Or identify parts of spec
that will go to currently worked on specs. I can see a MQ go
to get from WG and figure out next steps

Rossen: Not sure if anyone had a chance to review, it's fairly short
fantasai: I haven't but TabAtkins and I plan to tomorrow. I can get
review by next week
Rossen: Sounds great. I just want to take it out of private repo and
get it into CSS
Rossen: I'm okay breaking this apart into appropriate specs or keep
as one until it solidifies more and then break. Either is
okay
fantasai: Ultimately want all MQ to go int MQ5. High contrast props
should go together, don't know spec
<fantasai> there was a printer color adjust control as well that
should go together with this
Rossen: This is something...this is why I wanted to keep it as one
spec to begin so it brings whole picture together in terms
of what the high contrast feature does. Once this is better
understood we can break apart into appropriate modules
florian: Depends how many we want to break into. Mostly together
makes sense. I'm interested in splitting MQ early because
the whole thing is interaction between that MQ and others
in that domain. I'd hate to go too far and it doesn't mesh
Rossen: You suggesting break MQ out now and add to MQ5?
florian: And the rest in the stand alone ED and work on that
AmeliaBR: Looking at Rossen's draft there isn't a lot of the rest.
Any problem with all into MQ5 for now and maybe we find a
better place for the extra property later?
Rossen: Not opposed
fantasai: Makes sense. Not stay indefinitely but for current state
of discussion makes sense to have a section that deals

florian: Rossen do you want to be a coeditor of MQ5?
Rossen: Sure

astearns: Do we want to resolve to add this to MQ5 now or give a
week for review?
<fantasai> MQ is re-used outside of CSS, so definitely shouldn't
stay there :) But fine to be there for a few months while
we figure out where things should go
<heycam> +1 to move it all into MQ5 for now
Rossen: Comfortable with either. If people feel this is better in
MQ5 and this is where we're going to go let's just go. We
can always make changes
fremy: Agree with Rossen. We can start to files issues against it
which is better then filing issues when it's not official. If
we all agree it's in MQ5 let's agree on it
fantasai: I'd say wait a week. I can do a review and maybe we have
clearer idea of what we want to assign
fremy: I have issues I'd like to file but I don't know where
fantasai: We do have a single repo so you can file and tag later

Rossen: If it's okay with WG I cam move spec as-is right now knowing
it's unofficial into CSS Repo. I'm attending blink-con next
week during call so I'm not going to be present. I would be
happier if people started shooting issues into a repo and
tag against spec
florian: Okay with that
astearns: I'd rather not put it in repo as-is if going to put it
into MQ. Rather open issues on repo and tag later. Just @
Rossen and melanierichards

<AmeliaBR> We also have another proposal for a "media-query
adjacent" CSS property in supported-color-schemes,
which should probably go in the same place as this
high-contrast override property.

florian: There's 2 parts in this to me. MQ and high-contrast-adjust.
high-contrast-adjust is a pattern I think we'll see so it
belongs. The new cascading border doesn't belong. It's got
the backdrop in there?
Rossen: It's not there. It's not currently expressed as a reachable
entity through style layer. If you recall the discussion I
did point out to be successful for impl. There was some
interest this could apply to things like captions. In event
that we believe this new feature should surface on CSS layer
I can add the spec text. For now not exposed because can't
be reached by author
florian: That part just doesn't feel like it should be in MQ
Rossen: Agree, totally different. Maybe it's B&B if anything

astearns: Let's keep in Rossen's repo for now. Please review doc and
open issues on our repo and we'll descide after a bit of
review what we'll do

CSS Text
========

text-transform's design, intent and reality resolution
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3775

astearns: Wanted to have this introduced so can make a bit of
progress before bringing in more people
bkardell: I don't see where this was spec originally in the design,
but at some point it became a stated thing we have talked
exposes to screen readers and why
bkardell: Feel like I dropped the ball a bit on kana discussions
because I know it wasn't reality and assumed other people
did too. Some of the text stuff I don't feel I can comment
so wasn't paying close attention
bkardell: Opened a different issue requesting something that is
inline with how screen readers work. That changes to how
we have designed to not expose text to screen readers.
It's come up that it does not match reality
bkardell: AT and browsers have chosen universally to expose
transform text. I'd like to consider that so that we can
properly discuss the other issue
bkardell: My position is that the ones that exist and in wide use
are stated design principle is out of touch with reality.
It's a conscious choice that's what users want. At a
minimum our principle needs some finesse

florian: The discussion is a bit long winded, I'll jump to where we
are. I don't see the same contradiction as bkardell if we
look a little deeper. Don't think it's interesting to
debate what screen reader users what, the experts have
present it. It's easier to include the transform. I don't
think that makes semantics change
florian: I don't think we could do that. There are places where we
don't present CSS so we can't say that text-transforms are
an intrinsic part of doc that can't be removed. If screen
readers as one UA think best way to present is to apply the
text-transform, great. But I don't think we can go from
there to never not allow them to be applied. If you
introduce a new text-transform old browsers won't know
florian: I think we have to recognize that the doc is the doc and
the text-transforms need to be allowed to apply. I think
the claim that case transforms are desirable is credible,
but I don't want to generalize to say all transforms always
must be preserved. I think cjk and i18n transforms you want
the other way.
florian: I think we need to discuss transform by transforms, but
can't say all must be preserved

fantasai: I agree with florian that text-transform can't be
intrinsic part of doc semantics. They were designed as a
way to have this distinction partly. If we don't have them
to different doc and visual rendering we'll have to find a
way to do it.
fantasai: Someone suggested creating a custom font, I don't want to
get into that arms race
fantasai: I'm not sure how deeply this was investigated in the past.
I don't see anything in bugzilla. Chrome issues had people
arguing on both sides. I don't know if this has been
investigated deeply enough. We need to talk to the people
we need to talk to and figure out what to do. It's
possible the current situation is what fell out of
original implementations, and screen readers just dealt
with it but it's not ideal. If no discussion on Gecko it's
probably what's convenient

IanPouncey: Few points, to reiterate bkardell's point it seemed to
those of us who work with screen readers that this was
common knowledge, that's on us. For what florian said I
think misconception about where problem lies. It's not
screen readers doing transform, it's the browser and
a11y tree exposing it
IanPouncey: It's not screen reader doing anything in most modern
browsers. Any of the ideas of a screen reader making a
decision about what to present is problematic because
you cannot reverse a transform to uppercase because you
don't know what char were uppercase
IanPouncey: Speculating on this, I wonder if there's a similar issue
for content on the radar. I think there was an
assumption when property introduced that it's not
exposed to screen readers and it is now. I wonder if
there's a similar problem there
<fantasai> Point about delivering transformed text through AT
meaning screenreaders can't access original text even if
they want to is imho important

Rossen: Way screen readers work is a long discussion. How text is
represented also heavily depends on current platform support
and AT consuming that information. nvbia on windows will
have different characteristics to express richness of text
compared to narrator using ui automation
Rossen: One thing I know from interacting with the community and
a11y wgs and impl a11y the thing I can tell you is a lot of
people think of screen readers for the blind. It's part of
the users but not all. Most people are those with low
vision. They can see parts of the screen. So when you start
producing disparity between rendered results and what screen
Rossen: Consider editing scenarios- most people will navigate text
by character to check spelling. If at that time you have
text-transform that caps for example for them to not know
it's upper case will be confusing. Same reason why we map
ital to em, lots of font features that map to a11y prop I
don't see why this should be unique
Rossen: Other thing I want to give a big shout out, CSSAAM would be
ideal place to continue this discussion
<fantasai> wrt checking spelling in editing environment... ideally
you want to know what text you're actually typing, for
when the text-transform goes away -- source text should
be following standard capitalization rules, would be
problematic if ::first-line { text-transform: uppercase;}
led someone to type in all-caps when replacing one word
with another in the first phrase of a para
<fantasai> generally, editing text with text-transform turned on is
going to be very confusing regardless...

AmeliaBR: There's 2 aspects to the discussion. What should happen,
how is best way to expose full information. Then specific
practical issue in that we have recently added values of
text-transform with some impl and this new prop for math
variants
AmeliaBR: By putting it all in text-transform it forces us to treat
them the same for exposing before or after transform values
AmeliaBR: Even if not complete agree on optimal for exposing case
changes I'm trusting florian that exposing CJK
typographical is a problematic situation from a11y.
AmeliaBR: If mathML comes through it's very important to expose
transformation.
AmeliaBR: With these different semantic impacts it might be worth
discussing if these should be split up, even if it's
transform to long hands that could all reset by a
shorthand but there is a text-transform case that's
different then CJK text-transform. If we separate to
different properties we can start talking semantics and
what strange transformations happen
AmeliaBR: Especially in terms of what's exposed to a11y, innerText,
copy/paste APIs, lots of places where people use
text-transform and if they're not all equal maybe use
different properties
<fantasai> reason to have separate longhands is needing them to
cascade separately... if the only concern is what impacts
they have, we can categorize within the spec

florian: I am aware about difference IanPouncey mentioned between
what screen readers do and what's in at. Idea is that text
in AT would be end transformed text and have the original
information so screen readers can make decision. In case of
case transforms if every screen reader wants to do the same
thing with it and the current AT does the transform already
it will be uphill to un-transform. For case transforms if
it's a standard today fine let's leave it
florian: But that's what I want to Japanese which is keep
untransformed text and keep information about transforms so
The Math case I think is kind of related. I don't think we
can rely on the transforms to change document semantics.
florian: If we want to introduce a new semantic differences we have
to introduce it in the document and that can impact the AT
tree. We can't just change the font and claim it lets us
introduce semantic differences that would change the
meaning of the document. Upper case is useful but not
changing doc meanings. If we want to introduce math it will
fail in all cases

astearns: To respond to AmeliaBR- I think the idea of separating
properties is interesting but maybe not entirely
necessary. If we want we can spec what happens to values
or properties and they can differ.
astearns: To respond to florian I think there is prob a fallback
that can work for new math transforms. If you see support
you get fractor, if you don't you do extra styling
florian: And it disappears in reader modes
astearns: Fair
florian: If you want to style that's fine. Introducing fundamentally
different semantics won't work.

IanPouncey: Cautious +1 to expose detail of transform and original
content. I can see if there's any appetite for that.
Hopefully we can get idea if that's possible. Also
acknowledging the prompt to add CSSAAM to this discussion

document. The request for math transforms is from MathML
as a way to describe behavior of MathML attribute in a way
that can be consistently impl. That is something where
there is semantics in doc level but nice to be able to
describe it. Maybe also use same effects in more
decorative cases
florian: Fair and useful so thing into a11y tree is the transformed
and may be useful

astearns: We're at time. The call bridge will stay open if people
want to chat and then put the discussion in the issue
astearns: Thank you all very much


## Re: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • April 03, 2019 • Permalink

Hi Sina,
I think it would be good for you to review/comment on these two pull requests they will be discussing tomorrow.
* https://github.com/w3c/aria/pull/923

* https://github.com/w3c/aria/pull/924

Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Skype: charles_lapierre
Phone: 650-600-3301

On Apr 3, 2019, at 12:51 PM, Sina Bahram <sina@sinabahram.com<mailto:sina@sinabahram.com>> wrote:

I’m at a conference, so my regrets on this, but I’m really passionate about this topic. Please let me know if there’s questions I can answer or things I can comment on/provide feedback for.

President, Prime Access Consulting, Inc.
Phone: 919-345-3832<tel:919-345-3832>
https://www.PAC.bz<https://www.pac.bz/>
Personal Website: https://www.sinabahram.com<https://www.sinabahram.com/>

From: Charles LaPierre <charlesl@benetech.org<mailto:charlesl@benetech.org>>
Sent: Wednesday, April 3, 2019 3:04 PM
To: public-mathonw. <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>>
Cc: Sina Bahram <sina@sinabahram.com<mailto:sina@sinabahram.com>>; George Kerscher <georgek@benetech.org<mailto:georgek@benetech.org>>
Subject: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Hello everyone,
I wanted to let you know that in tomorrows ARIA WG call the topic of new Braille Properties added to ARIA will be discussed.

Unfortunately I can not attend as I am presenting at that time, but I hope those who joined the ARIA WG from this group will be able to attend.
Here is the agenda Item and information regarding the call which is tomorrow April 4th at 10AM Pacific / 1PM Eastern
* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1

* New issue triage:

https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+

* New pull-request triage:

https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+

* Quick status check of active role-parity issues:
- fieldset/legend: https://github.com/w3c/aria/pull/911

- label: https://github.com/w3c/aria/pull/886

- time: https://github.com/w3c/aria/pull/895

* Quick, straw-poll-level discussion:
- Keep children-presentational on math role?
https://github.com/w3c/aria/issues/425

- Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
https://github.com/w3c/aria/issues/667

* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Previous Meeting Minutes:
https://www.w3.org/2019/03/28-aria-minutes.html

IRC: irc.w3.org:6665<http://irc.w3.org:6665/> #aria

Call Details: https://www.w3.org/2017/08/telecon-info_aria

To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number: +1-617-324-0000<tel:+1-617-324-0000;641%20291%20851>
Access code:641 291 851<tel:+1-617-324-0000;641%20291%20851>
Mobile Auto Dial:+1-617-324-0000,,,641291851#<tel:+1-617-324-0000,,,641291851%23>



## RE: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Sina Bahram (sina@sinabahram.com) • April 03, 2019 • Permalink

I'm at a conference, so my regrets on this, but I'm really passionate about
this topic. Please let me know if there's questions I can answer or things I
can comment on/provide feedback for.

President, Prime Access Consulting, Inc.

Phone: 919-345-3832

https://www.PAC.bz

Personal Website:  <https://www.sinabahram.com> https://www.sinabahram.com

From: Charles LaPierre <charlesl@benetech.org>
Sent: Wednesday, April 3, 2019 3:04 PM
To: public-mathonw. <public-mathonwebpages@w3.org>
Cc: Sina Bahram <sina@sinabahram.com>; George Kerscher
<georgek@benetech.org>
Subject: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Hello everyone,

I wanted to let you know that in tomorrows ARIA WG call the topic of new
Braille Properties added to ARIA will be discussed.

Unfortunately I can not attend as I am presenting at that time, but I hope
those who joined the ARIA WG from this group will be able to attend.

Here is the agenda Item and information regarding the call which is tomorrow
April 4th at 10AM Pacific / 1PM Eastern

* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404
T13&p1=43&ah=1> &iso=20190404T13&p1=43&ah=1

* New issue triage:

https://github.com/w3c/aria/issues?utf8=%E2%9C%93
<https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+cr
eated%3A%3E%3D2019-03-28+>
&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+
* New pull-request triage:

https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-0
3-28+
* Quick status check of active role-parity issues:
- fieldset/legend: https://github.com/w3c/aria/pull/911
- label: https://github.com/w3c/aria/pull/886
- time: https://github.com/w3c/aria/pull/895
* Quick, straw-poll-level discussion:
- Keep children-presentational on math role?
https://github.com/w3c/aria/issues/425
- Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
https://github.com/w3c/aria/issues/667
* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Previous Meeting Minutes:
https://www.w3.org/2019/03/28-aria-minutes.html

IRC: irc.w3.org:6665 <http://irc.w3.org:6665>  #aria

Call Details: https://www.w3.org/2017/08/telecon-info_aria

To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number: +1-617-324-0000 <tel:+1-617-324-0000;641%20291%20851>
Access code:641 291 851 <tel:+1-617-324-0000;641%20291%20851>
Mobile Auto Dial:+1-617-324-0000,,,641291851#
<tel:+1-617-324-0000,,,641291851%23>


## ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • April 03, 2019 • Permalink

Hello everyone,
I wanted to let you know that in tomorrows ARIA WG call the topic of new Braille Properties added to ARIA will be discussed.

Unfortunately I can not attend as I am presenting at that time, but I hope those who joined the ARIA WG from this group will be able to attend.
Here is the agenda Item and information regarding the call which is tomorrow April 4th at 10AM Pacific / 1PM Eastern
* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1

* New issue triage:

https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+
* New pull-request triage:

https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+
* Quick status check of active role-parity issues:
- fieldset/legend: https://github.com/w3c/aria/pull/911
- label: https://github.com/w3c/aria/pull/886
- time: https://github.com/w3c/aria/pull/895
* Quick, straw-poll-level discussion:
- Keep children-presentational on math role?
https://github.com/w3c/aria/issues/425
- Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
https://github.com/w3c/aria/issues/667
* New braille properties:
- aria-roledescription-braille
- aria-label-braille

Previous Meeting Minutes:
https://www.w3.org/2019/03/28-aria-minutes.html

IRC: irc.w3.org:6665<http://irc.w3.org:6665> #aria

Call Details: https://www.w3.org/2017/08/telecon-info_aria

To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number: +1-617-324-0000<tel:+1-617-324-0000;641%20291%20851>
Access code:641 291 851<tel:+1-617-324-0000;641%20291%20851>
Mobile Auto Dial:+1-617-324-0000,,,641291851#<tel:+1-617-324-0000,,,641291851%23>


## Using MathML-Based Speech to Edit Math in Different Math Models

Source: Murray Sargent: Math in Office • MurrayS3 • March 28, 2019 • Permalink

This post discusses how an Assistive Technology program (AT) can use Presentation MathML to create consistent speech for editing equations created with different math models, such as OfficeMath and MathType. A goal is to make the speech and editing experience be as similar as possible, even though the underlying math models differ in significant ways. An important aid for editing is that the editor handle navigation so that the insertion point (IP) and speech are synchronized. When navigation occurs in a MathML copy of the math zone, editing isn’t possible unless there’s a way to convert a location in the MathML copy to the corresponding character position (cp) in the document. Such synchronization is also needed in calculating the bounding rectangles of the math being spoken. Math keyboard input is facilitated by sophisticated input methodology, such as special hot keys, autocorrection, and autocompletion. The AT should not attempt to handle math keyboard input.

The post Speaking of math… describes two granularities of math speech: coarse-grained (navigate by words—siblings), which speaks math expressions fluently in a natural language, and fine-grained (navigate by characters), which reveals the content at the insertion point (IP) in enough detail to enable unambiguous editing. It seems clear that an AT can generate the same coarse-grained math speech from the MathML for an equation regardless of the underlying math model. The question arises as to whether the fine-grained math speech can also be the same for different math models.

## Math speech generality

To create math speech for all math models, the MathML and the speech generated therefrom need to be rich enough semantically to describe the union of all arguments of all math objects (fractions, subscripts, integrals, math functions, etc.) of the various math models. The post Integrands, Summands, and Math Function Arguments compares some math objects for OfficeMath, Presentation MathML, Content MathML, [La]TeX, MathType/Equation Editor, and Nemeth math braille. To illustrate one difficulty, Presentation MathML, LaTeX and Nemeth braille don’t have explicit ­N-ary elements, while the others do. If the same fine-grained math speech is to work for all models, they all need to supply MathML that lets the AT announce that the insertion point is at the end of an integrand, for example.

Another case is the OfficeMath math-function object which has a function-name argument and an argument for the function. For example, in memory sin 𝑥 is stored as a math-function object with the name “sin” and the math argument 𝑥. It’s important for fine-grained speech to announce, “end of function name” when the user navigates past the ‘n’ and “end of argument” when the user navigates past 𝑥 but not yet out of the math-function object. That notifies the user that subsequent keyboard input will be in the function name or argument, respectively. The user might want to change sin 𝑥 to sin 𝑥², for which the math-function argument is 𝑥² and thereby not mean (sin 𝑥)².

Math semantics are important for correct math speech. For example, most superscripts represent raising a base to a power, so that speaking 𝑎² as “a squared” is correct. But in tensor analysis, superscripts are used as indices and 𝑎² should be spoken as “a superscript 2” or “a sup 2”. Presentation MathML 3.0 doesn’t have a way to distinguish between these cases. Adding new MathML attributes could provide a concise way to convey the semantics for speech. Alternatively, the <semantics> tag could be included with the corresponding Content MathML, but that approach is probably too involved for most ATs.

## Differences in MathML and OfficeMath models

To illustrate differences in computer math models, consider how MathML, MathType, and OfficeMath represent sin 𝑥. In the PowerPoint and RichEdit OfficeMath memory layouts, sin 𝑥 appears as <U+FDD0>sin<U+FDEE>𝑥<U+FDDF>. Here the Unicode character <U+FDD0> is the math-object start delimiter, the <U+FDEE> is the argument separator, and the <U+FDDF> is the math-object end delimiter. Word also has such delimiters but with different values. Starting at the <U+FDD0>, each → arrow key moves past one of these characters. In a math model that doesn’t have the math-function object, no → arrow key is needed to move to the start of the function name or to move out of the math-function argument. That’s a basic difference in UI between models that affects fine-grained math speech. It doesn’t affect coarse-grained math speech, which in English is “sine x” for all math models.

Ideally the Presentation MathML for sin 𝑥 is

<mrow><mi>sin</mi><mo>&2061;</mo><mi>𝑥</mi></mrow>

How do you relate a position in this MathML to the corresponding position in the OfficeMath memory? Do the <mrow> and </mrow> each have a character position (cp)? They do for OfficeMath, but not for MathType. Are <mi>sin</mi> and <mi>𝑥</mi> separated by a character? They are in OfficeMath, but not in MathType. MathType represents the difference between the sin and the 𝑥 by character formatting and doesn’t use object delimiters for math functions.

Another cp mapping example is <mfrac><mi>a</mi><mi>b</mi></mfrac>. In MathML, there’s nothing between the numerator <mi>a</mi> and the denominator <mi>b</mi>, while in the OfficeMath backing store, there’s the U+FDEE argument separator. In a MathML model, when at the start of <mi>a</mi> the → arrow key might move directly into the denominator, while in OfficeMath it moves to the end of the numerator, allowing the user to insert characters there. It takes an additional → arrow key to move to the start of the denominator.

In addition to location differences in MathML and math-zone spaces, there are text-length changes resulting from automatic conversions of ASCII and lower-case Greek letters to math-italic letters, hidden text, revision marks, and special objects not representable in MathML such as images, hyperlinks, and fields. So, mapping from MathML space to editing space needs special assistance.

## Navigating in MathML space

MathPlayer uses a MathML representation of an equation and navigates in the abstract MathML space, not the editing space. Hence it needs a way to transfer MathPlayer locations to the user selection for inserting/deleting/selecting text and displaying bounding rectangles. In principle, the MathML writer can create a cp array indexed by the MathML-tag index. Every MathML tag would have an entry in the array, including all closing tags. Then a new UIA method could allow an AT navigating in the MathML space to set a client selection end to the cp for the nth tag. In particular, the AT could set the edit insertion point and bounding rectangles corresponding to locations in the MathML space.

This approach requires that the AT keep track of the MathML tag indices. The post Math Accessibility Trees compares a display tree to a semantic tree for the equation

This equation appears in Nemeth braille as

⠹⠂⠌⠆⠨⠏⠼⠮⠰⠴⠘⠆⠨⠏⠐⠹⠨⠈⠈⠙⠨⠹⠌⠁⠬⠃⠀⠎⠊⠝⠀⠨⠹⠼⠀⠨⠅⠀⠹⠂⠌⠜⠁⠘⠆⠐⠤⠃⠘⠆⠐⠻⠼

There are nodes in both trees to attach the MathML tag indices to. Each node needs to cache the tag indices for the start and end tags that delimit the node.

This approach isn’t likely to be implemented by Microsoft Word since Word creates MathML by converting the OMML for the requested math to MathML using OMML2MML.xsl, a process that doesn’t keep track of MathML tag cp’s. Word would have to create a native MathML writer to implement a tag-cp mapping array. Such an array could be implemented in the RichEdit native MathML writer, thereby enabling tag-cp mapping in PowerPoint and OneNote. The RichEdit MathML writer was created before the OfficeMath build up/down facility was written. That facility uses a subset of the TOM interfaces that is implemented by Word and OfficeArt enabling them to use the facility. The RichEdit MathML reader also uses the TOM subset and in principle could be used by Word instead of converting MathML to OMML using MML2OMML.xsl. In contrast, the RichEdit MathML writer is pretty RichEdit-specific. Math zones can be copied from Word into RichEdit, but the original Word cp’s aren’t copied.

## Navigating in editing space

If navigation is done in the editing space, the post Editing Math using MathML for Speech describes two ways for an AT to produce fine-grained math speech from MathML: 1) the MathML contains an <maction> element that gives the explicit math speech for the content at the insertion point, or 2) the MathML represents the math object in which the insertion point is located and includes an <maction> element identifying the insertion point. The first approach typically leads to different speech for different programs.

Character navigation in the editing space depends on the order in which math-object arguments appear in memory and how the arrow keys are handled. All math models put the numerator of a fraction before the denominator and can in principle be traversed using the ← and → arrow keys. MathType puts the integrand of an integral object first, followed by the lower limit and then the upper limit, while OfficeMath puts the limits first followed by the integrand, which is the visual order. Also, MathType uses ↑ and ↓ to navigate between N-ary object arguments vertically, perhaps because the arguments aren’t located in visual order and the ← and → arrow keys are strictly geometric and don’t traverse every character in an equation. In OfficeMath, the ← and → arrow keys move logically, rather than purely geometrically, and traverse every character in an equation. For example, the → arrow key at the end of a numerator moves to the start of the denominator. The MathML <mroot> puts the index after the radicand, while OfficeMath puts it before (in display order).

The most straight-forward approach is to navigate in the editing space as done with character and word (sibling) navigation with OfficeMath speech and Narrator. Then the insertion point is always synced to the speech. Characters are entered and deleted correctly, and information that MathML doesn’t represent is retained. MathPlayer was designed to explore equations and wasn’t intended to be used for creating and editing equations. The MathType editor has no accessibility support so editing equations using speech wasn’t a design scenario. In contrast, it was an essential design scenario for OfficeMath. It wouldn’t be hard to duplicate the richer MathPlayer navigation experience in OfficeMath but by navigating in the editing space rather than in a virtual MathML space.

One might ask whether it’s desirable to have a one-size-fits-all fine-grained editing experience. It might be unexpected or even confusing to say “end of argument” after the 𝑥 in sin 𝑥 in environments that don’t have a math-function object. That coupled with the differences in the way math text is laid out in memory makes the goal of identical fine-grained speech for all math models seem impractical. But for coarse-grained speech, these details are hidden, and it should be possible to have the same coarse-grained math speech for all math models.

It’s a pleasure to thank Doug Geoffray, Ron Parker, and Neil Soiffer for very helpful discussions on these topics.

## [CSSWG] Minutes San Francisco F2F 2019-02-25 Part I: CSS Values, MathML Summary, WPTest Center, CSS Color, CSS Pseudo Elements [css-values] [css-color] [css-pseudo]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • March 26, 2019 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

CSS Values
----------

- RESOLVED: We will use the bracket range notation (Issue #355:
Define value syntax that limits <integer>, <number>,
<length>, etc. to ranges)
- Flag against the issue all specs that need to have their grammar
updated and authors can remove the flag once they have made the
changes.
- Bikeshed might need an update to correctly parse the new syntax.

MathML summary
--------------

- There is a new community group called MathML Refresh that is
working on rewriting the MathML spec. It's starting to surface
questions and issues for the CSSWG in github and those
interested in Layout should take a look.

WPTest Center
-------------

- TabAtkins did a demo on http://wptest.center/ and how it can help
the group in writing tests.

CSS Color
---------

- RESOLVED: Updated WD of css-color-4

CSS Pseudo Elements
-------------------

- RESOLVED: pseudo() must always return the same object. Note that
object can be GC'd if this is unobservable. (Issue
#3607: Identity of Element.pseudo() return value)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sf-2019

Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
Amelia Bellamy-Royds, Invited Expert
Tantek Çelik, Mozilla
Emilio Cobos, Mozilla
Dave Cramer, Hachette Livre
Jihye Hong, LGE
Brian Kardell, JS Foundation (phone)
Chris Lilley, W3C (phone)
Cameron McCormack, Mozilla
Theresa O'Connor, Apeoplee
François Remy, IDLAB
Manuel Rego, Igalia
Florian Rivoal, Invited Expert
Hiroshi Sakakibara, BPS(Beyond Perspective Solutions)
Jen Simmons, Mozilla
Hyojin Song, LG Electronics
Greg Whitworth, Microsoft
Fuqiao Xue, W3C

Scribe: gregwhitworth

CSS Values
==========

--------------------------
github: https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757

AmeliaBR: Currently we have something like <length-percent> and in
the prose it says negative values are invalid
AmeliaBR: The idea is to get that into the actual syntax grammar
AmeliaBR: Especially with various houdini APIs we're providing
AmeliaBR: The issue is to discuss what this syntax looks like
AmeliaBR: My proposal was to look like something like sgml
attributes, we're using angle brackets for data types
AmeliaBR: fantasai concern is that that can get verbose
AmeliaBR: If you go down to the second to last issue I have the
different options with 4 real world examples
AmeliaBR: Any pros/cons - I've listed mine but would like to hear
people's feedback
fantasai: I like my proposal
fantasai: I really don't want to make things too verbose, the more
the grammar has to wrap lines the harder it is to read
fantasai: I prefer the more human readable version
<astearns> https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757

[TabAtkins shows options on screen]
[TabAtkins explains the various proposals in the link above]
fantasai: A minimum in human readable could be 0+

TabAtkins: I'm most a fan of the bracket range syntax
fantasai: If you're going to use multipliers, it uses similar syntax,
pattern.
TabAtkins: This is already in the syntax
TabAtkins: I agree with the idea in general
TabAtkins: I agree with AmeliaBR that with Houdini we need to

heycam: A non syntax question
heycam: When we have prose that restricts these values, when we have
calc expressions, when we have negative inside the calc -
would a change to this syntax make some values invalid
earlier?
TabAtkins: This shouldn't change anything this is just moving the
prose into the grammar
TabAtkins: calcs() are still valid and clamp to the range
heycam: If you have a property number 1-1000
heycam: and you use any calc inside that
TabAtkins: Yep, that should work

astearns: Does anyone have any objections to bracket notation
astearns: I would prefer to have explicit rather than empty
TabAtkins: What about writing infinity rather than the symbol
fantasai: No, too long
iank: Are we allowing the word infinity?
iank: I'm biased to the Javascript
iank: I'm fine with both
AmeliaBR: That sounds the best for me
AmeliaBR: The infinity symbol is nice in a spec but not necessarily
for typing in code
<myles> +1 to what AmeliaBR said
heycam: Rather than brackets and commas you can use ..
heycam: Some languages include two dots others use three dots
<astearns> ∞ in the grammar is the start of a slippery slope to
writing css specs exclusively in emoji
gregwhitworth: I would prefer no on that
AmeliaBR: As fantasai noted the brackets are known in CSS in the
grammar
iank: Also the ... may get confused with the destructioring in JS
TabAtkins: We will go with the bracket version and allow Infinity
and the infinity symbol
TabAtkins: I would never propose the infinity symbol for CSS itself,
this is for syntax

florian: Bikeshed feature request, convert infinity word to symbol

fantasai: There is an infinity code and ampersand version
<TabAtkins> &infin;

fantasai: What's the case sensitivity of the infinity keyword?
TabAtkins: In JS it's Infinity
fantasai: As a string?
TabAtkins: it would be <number [1, Infinity]>

<AmeliaBR> Proposal: Use the bracket range notation (from the
issue), but with infinite ranges (no max/min) represented
by either Infinity or &infin; (or negative thereof)
AmeliaBR: It's not a string it's a token within the syntax

fantasai: Question, is our syntax types case sensitive
TabAtkins: The Houdini syntax cares
fantasai: Yeah we're consistent in our specs but I was curious
<TabAtkins> syntax: "big | BIGGER" in registerProperty() is
astearns: Any objections to the proposal

RESOLVED: We will use the bracket range notation

Go through the specs and update the grammar
-------------------------------------------

AmeliaBR: I can maybe do some PM on that, but I'm hoping the spec
editors will do some work
<myles> I can do fonts
<chris> I can do color
heycam: Does that require Bikeshed changes?
TabAtkins: No
TabAtkins: We can tag the specs that need the changes and then untag
as you make the changes
astearns: If you could please make sure that they all get changed

florian: Do we do that for specs that are RECs?
TabAtkins: Do it to the ED and wait for it to get to rec - it's an
editorial change
<fantasai> We need to push out the changes to css-values-3 first

<chris> did people hear? I asked that Rec changes get propagated to
errata
[working on getting chris audio]
astearns: Unless there's a really good reason to do that extra work,
I would prefer not to [in relation to chris's question]
<chris> I'm not sure why not update the errata
<chris> it's much less than making a new Rec
astearns: I'm just looking at it as make work, this isn't adding
anything to the Recs it's just a shortcut
<chris> ok in his case, yes, no normative change

MathML summary
==============

rego: This is a quick point - we were talking with Google about the
state of things
rego: Wanted to make everyone aware
rego: There has been work to update the spec and align closer to how
the browser works
rego: There is a new CG called MathML Refresh to write a new spec
that focuses on what browsers do
https://people.igalia.com/mrego/mathml-refresh-community-group.html
rego: Basically they are starting to move this to a Github repo
rego: There is a MathML core there to implement in Webkit
rego: This was planned to be implemented in Chromium but we need to
clarify some issues with CSS, etc
rego: There are WPT tests and we'll be creating more tests and
porting the ones from webkit
rego: There are some new CSS proposals, but just in case someone is
interested in it to go take a look
rego: That's mostly all of it, Igalia has begun implementing MathML
in LayoutNG in collaboration with Google. It's currently in a
private Igalia fork
rego: Let me know if you have any questions
<gsnedders> there's a whole load of tests for the MathML subset
Opera supported in the old presto-testo repo, though I
don't know if they're very useful (they probably aren't
reftests :()

TabAtkins: These CSS proposals, they haven't showed up in the group
at all?
rego: No - people are just starting to talk about it, if people are
interested they can take a look
TabAtkins: Can you open an issue to link to the ideas so that we can
go look at them?
astearns: I was going to say similar, as things get further along it
would be good to bring them here
iank: I'm going through and filing some core issues with MathML
today and tomorrow, how should margin collapsing work in
MathML? Because there is currently no interop, etc
iank: Those that know layout and have opinions should probably chime
in
rego: That's all

dauwhe: How is the quality of the current MathML spec
dauwhe: Had to look at it and it's written in this older style that
is hard to follow
rego: The meaning of the group is meant to work on that, I can't
necessarily speak to the quality of the spec
rego: You can implement in many different ways, the spec didn't
necessarily define how to implement things
<bkardell> I believe one task the group wants to do is also spec it
out more like the newer HTML specs
dauwhe: Are they considering splitting out the presentational markup
from the content markup?
<bkardell> yes that is my understanding
<bkardell> to what dauwhe said
bkardell: One task group wants to do things like newer HTML specs
TabAtkins: Yeah, that's what they're currently doing
dauwhe: That's good to hear
dauwhe: afaik semantic MathML is only used in XML  toolchains,
is not exposed to the Web

WPTest Center
=============

TabAtkins: A little while ago fremy gave a presentation about
wptest.center
TabAtkins: I've been using it to write the CSS syntax tests from the
past 5 years
[TabAtkins shows a demo on how to do this]
TabAtkins: Syntax tools are almost all in JS
<bkardell> this is awesome
<chris> is there a way to add reftests?
<astearns> no reftests from this tool
<bkardell> thank you astearns
<chris> I like that this lowers friction for a quick test
fremy: It's primarily to help unblock the CR so people can quickly
submit a test
astearns: I was going to encourage everyone to take a look and try
it out
astearns: and we need to be writing more of these tests, maybe the
ease of this will be nice to add a reftest for this
astearns: It's OSS so it may be nice to add a file picker to add a
reftest
TabAtkins: You don't have to deal with the repo
astearns: We are still waiting on hearing from external people

[20 min break]

CSS Color
=========
Scribe: fantasai

Updated WD of css-color-4
-------------------------

chris: Hello everyone!
chris: Quick request to update Color
chris: Someone was saying "oh, there haven't been changes since
2016" and I realized they were looking at /TR
chris: Over weekend I made a list of changes
chris: Lots of issues still open, but just asking for updated WD
<AmeliaBR> https://drafts.csswg.org/css-color-4/#changes-from-20160705

fantasai: Any changes in scope?
chris: No just improvements to what's there
chris: Actually, one change in scope, removed color modification
function
chris: It was problematic and people weren't happy with it
chris: We need functionality like that, but not that particular thing
chris: Became an issue that people were trying to implement what was
on /TR and we didn't want that implemented

astearns: any objections to publishing?
<florian> +1 to publication

RESOLVED: Updated WD of css-color-4

CSS Pseudo Elements
===================

Identity of Element.pseudo() return value
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3607

heycam: Last time we discussed this on a call, I was suggesting that
the pseudo() function which returns a CSSPseudoElement object
heycam: should always return the same object regardless of what
values content has
heycam: just so that we don't have to rely on what the current style
state is to know when these objects should be dropped and
recreated
heycam: It felt a little strange at the time
heycam: One thing that might argue against returning same object is
if we have an API in the future that can create from script
one of these objects and insert it into the tree
heycam: Might be problematic to have stable object identity created
for style, vs created from script
heycam: But that's similar to what we do for @font-face

TabAtkins: If you re-parse the style sheet, we'll create new objects
myles: Actually, I spent a week of my time making that not true.
TabAtkins: Can you open an issue on not doing that?
myles: I originally wanted to do the thing you said
myles: It was brought to my attention that it was very common in JS
that authors would tack on properties to random objects
myles: so you can't just delete and recreate them
futhark: For Blink implementation, we used to recreate the
pseudo-element internally when content changed, but we
don't do that anymore
futhark: When content property changes, we regenerate ... but the
object stays the same
emilio: But you still regenerate when you switch content property to
none and back again, right?
TabAtkins: If you turn content to none and then ask for the pseudo,
you do return an object that you can return style on
right?
futhark: Are you talking about the pseudo() method or gCS()
TabAtkins: pseudo()
futhark: We don't implement it

emilio: Do we want to keep them lightweight objects or do we add
.style?
emilio: If we add .style we need to keep the ? around anyway
fantasai: Currently we've dropped .style from the spec
TabAtkins: Wait, we dropped .style?
heycam: We kept .type and .element and it's an event target
TabAtkins: OK
emilio: If you add some stateful thing that we don't want to
disappear randomly, then keeping object itself around is not
a huge deal because you need to keep that info around
emilio: but if not, then recreating it would be better
TabAtkins: I think it should have .style
TabAtkins: later
TabAtkins: Because pseudos act like DOM elements, they fill a
similar purpose
TabAtkins: Having object identity work it's nice
TabAtkins: Without that it's more annoying
TabAtkins: ...

TabAtkins: Myles's argument about FontFace objects suggests that
they should stay around on these objects, too.
myles: I don't know how applicable that argument is to pseudos
dbaron: I think one other comment about expandos is that CSSOM
objects are historically one of the objects where expandos
don't stay around
dbaron: They stay around in lots of places, but not in CSSOM objects
TabAtkins: Is it just font face objects that are connected, or
[missed]
myles: Font face rules will change... I don't remember.
<AmeliaBR> https://developer.mozilla.org/en-US/docs/Glossary/Expando
"Expando properties are properties added to DOM nodes
with JavaScript, where those properties are not part of
the object's DOM specification"
<AmeliaBR> in case anyone else hadn't heard that JS jargon before...

florian: Another argument in favor of long-lived is if they're not,
we need to specify in detail what their lifecycles are
florian: And if we don't we'll expose a lot of implementation details
florian: Do you regenerate on content property changing from one
string to another? Flip to none and back? a display : none
subtree?
florian: etc.
TabAtkins: If we just make the element have a weak ref to its
pseudo, then expandos let you observe GC.
TabAtkins: Need to be either long-lived or regenerated on every call
myles: Most important part is that right now it's undefined when the
CSS engine decides to reparse rules or recreate derived
objects
myles: That's pretty important for optimization
myles: so tying JS-visible semantics to that schedule would be scary
myles: Instead we should define something more rigorous

dbaron: Why is your GC idea not viable?
TabAtkins: It allows you to detect when GC happens by seeing how
long the expando survives
dbaron: Traditional way around that is that the expando makes it not
collectible
TabAtkins: OK. My idea was to just hold it as a weak ref
dbaron: I think your weak ref idea is workable if we make expandos
not collectible.
myles: It's true in our engine also
TabAtkins: If that's the case, then all the exposed possibilities
for GC are handled if expando force a strong reference
TabAtkins: Incompatible with .style

fantasai: One concern was about keeping around a lot of memory if
you iterate the entire tree
fantasai: If the pseudo doesn't generate a box, you return null, but
as soon as you generate a box you generate the object and
keep it around
emilio: That's also incompatible with making that API work with
stuff like selection
emilio: For ::first-line ::first-letter, fine, but won't work for
some other stuff
TabAtkins: I think returning null is OK only for things that don't
exist, like the name is invalid
<fremy> +1
fantasai: Shouldn't that throw an error?
TabAtkins: No

florian: How long-lived is it?
heycam: So we always return the same object, and it's kinda like
it's connected to the element you call it on
TabAtkins: You're allowed to drop the object if doing so is
unobservable
TabAtkins: e.g if no expando, no references, can drop it and
recreate it
TabAtkins: I guess you can't observe object identity without a
reference

smfr: Same object in IDL?
TabAtkins: That's advisory in the IDL. Have to say in algorithm what
happens
myles: Can we make another IDL attribute that means "for real"? :)
heycam: What it means for a particular API is not particularly
clear, so need to say in the prose what type of object and
stuff.
myles: So it means nothing
heycam: It's a hint to the JS engine, that's all.
florian: There's a hint to the spec reader that there's some prose
somewhere that matters?
TabAtkins: Yes

astearns: So afaict, the proposed resolution is that pseudo() will
return the same object always
astearns: and we will have text suggesting that this can be GC if
that is unobservable
<TabAtkins> Proposed Resolution: pseudo() must always return the
same object (up to observability)
<TabAtkins> "same object" for a given element/pseudo pair
astearns: Objections/concerns?

RESOLVED: pseudo() must always return the same object. Note that
object can be GC'd if this is unobservable.


## Re: meetings

Source: public-mathonwebpages@w3.org Mail Archives • Han (laughinghan@gmail.com) • March 21, 2019 • Permalink

Shoutout to Peter for all the organizational work you've done.

Han

On Thu, Mar 21, 2019 at 12:36 PM Kaveh Bazargan <
kaveh@rivervalleytechnologies.com> wrote:

> I need to thank you too for all your effort, although I have not been able
> to make any of the meetings. What you all are doing is an important subject.
>
> Regards
> Kaveh
>
> On Thu, 21 Mar 2019 at 19:30, Joanmarie Diggs <jdiggs@igalia.com> wrote:
>
>> Also please remember that with respect to accessibility support, the
>> ARIA Working Group is happy to help in any way we can.
>>
>> A number of members of this CG have already joined ARIA, which is great.
>> And any math-specific needs can be raised at the dedicated
>> first-meeting-of-the-month math-topic slot. (They can, of course, be
>> raised at any time; the dedicated slot is to prevent people from having
>> to go to meetings that might be irrelevant to them.)
>>
>> If there's anything else I or ARIA can do to help the effort, you know
>> where to find me. :)
>>
>> --joanie
>>
>> On 3/21/19 12:32 PM, Daniel Marques wrote:
>> > Hi Peter,
>> >
>> > That's a pity but fair. I would like to thank you for all efforts done
>> > during all this time.
>> >
>> > But remember that despite no meetings, maths are already in the browser
>> > in one way or another.
>> >
>> > Good luck! We are in time to setup a meeting if the occasion arises!
>> >
>> > Regards,
>> >
>> > Dani
>> >
>> >
>> >
>> > On Wed, Mar 20, 2019 at 11:43 AM Peter Krautzberger
>> > <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
>> >
>> >     Hi everyone,
>> >
>> >     Due to the lack of interest, there will be no meetings until further
>> >     notice.
>> >
>> >     Best,
>> >     Peter.
>> >
>> >
>> > ------------------------------------------------------------------------
>> > MathType 7 is out! Check the new version at wiris.com/mathtype
>> > <http://www.wiris.com/mathtype?utm_source=emailfooter>
>>
>>
>>
>
> --
> Kaveh Bazargan PhD
> Director
> River Valley Technologies <http://rivervalleytechnologies.com/> • Twitter
>


## Re: meetings

Source: public-mathonwebpages@w3.org Mail Archives • Kaveh Bazargan (kaveh@rivervalleytechnologies.com) • March 21, 2019 • Permalink

I need to thank you too for all your effort, although I have not been able
to make any of the meetings. What you all are doing is an important subject.

Regards
Kaveh

On Thu, 21 Mar 2019 at 19:30, Joanmarie Diggs <jdiggs@igalia.com> wrote:

> Also please remember that with respect to accessibility support, the
> ARIA Working Group is happy to help in any way we can.
>
> A number of members of this CG have already joined ARIA, which is great.
> And any math-specific needs can be raised at the dedicated
> first-meeting-of-the-month math-topic slot. (They can, of course, be
> raised at any time; the dedicated slot is to prevent people from having
> to go to meetings that might be irrelevant to them.)
>
> If there's anything else I or ARIA can do to help the effort, you know
> where to find me. :)
>
> --joanie
>
> On 3/21/19 12:32 PM, Daniel Marques wrote:
> > Hi Peter,
> >
> > That's a pity but fair. I would like to thank you for all efforts done
> > during all this time.
> >
> > But remember that despite no meetings, maths are already in the browser
> > in one way or another.
> >
> > Good luck! We are in time to setup a meeting if the occasion arises!
> >
> > Regards,
> >
> > Dani
> >
> >
> >
> > On Wed, Mar 20, 2019 at 11:43 AM Peter Krautzberger
> > <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
> >
> >     Hi everyone,
> >
> >     Due to the lack of interest, there will be no meetings until further
> >     notice.
> >
> >     Best,
> >     Peter.
> >
> >
> > ------------------------------------------------------------------------
> > MathType 7 is out! Check the new version at wiris.com/mathtype
> > <http://www.wiris.com/mathtype?utm_source=emailfooter>
>
>
>

--
Kaveh Bazargan PhD
Director
River Valley Technologies <http://rivervalleytechnologies.com/> • Twitter