# 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: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • August 30, 2015 • Permalink

On 30/08/2015 21:21, Neil Soiffer wrote:
> You are indeed right and I'm wrong. For whatever reason, the \big (and
> \bigg) versions of those characters produce very different looking
> characters than the non-stretched ones in LaTeX.
>
> So I agree with David's original suggestion for the values.

they are just available in large sizes as the texbook makes it fairly
clear they are just there as an artefact of the construction of large
braces, placing the pieces together in different combinations.

the TeXBook says:

\danger ......
You can also use ^|\lgroup| and ^|\rgroup|,
which are constructed from braces without the middle parts; and
^|\lmoustache| and ^|\rmoustache|, ^^{moustaches}
which give you the top and bottom halves of large braces. For example,
here are the |\Big| and |\bigg| versions of....

David

________________________________

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________


## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • August 30, 2015 • Permalink

On 08/30/2015 09:24 PM, Neil Soiffer wrote:
> It is good to have renderers be consistent, but MathJax is not
> consistent with what it is trying to emulate. Making Gecko be
> consistent with that mistake seems like an additional mistake.
Just a remark: as I said in my initial message the entries for
rmoustache/lmoustache have already been in Gecko for a long time & the
LaTeX commands available in itex2MML too (for both, probably since the
early days of MathML), so the plan was to keep them anyway. But having
them in the "official" operator dictionary is best to be consistent with
WebKit, LaTeXML, MATH fonts, MathJax (both LaTeX-to-MathML converter &
rendering), etc

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



## Single Line RichEdit Performance Runs

Source: Murray Sargent: Math in Office • MurrayS3 • August 30, 2015 • Permalink

In applications that have lots of independent text instances such as spreadsheets and complex dialogs, one wants to know the tradeoffs between rapid display, memory usage, and editing functionality. As noted in the post Flyweight RichEdit Controls, using RichEdit to display such text avoids display glitches in switching from static display to edit mode and allows text to be copied, edited, and made accessible.On the other hand, simple text can be rendered considerably faster by calling system APIs. To compare the various approaches, I dusted off an old (circa 1996) program called grid that displays 300 windowless RichEdit controls and added a bunch of interesting options to check out run times for a variety of scenarios. This post relates some results. The text instances all consisted of single lines and it’ll be interesting to see how the relative times change for multiline instances as some point.

The following table lists run times in seconds for laying out and displaying 300 windowless RichEdit controls 10 times for various text types. For each display pass, the controls are loaded with text that identifies the display pass 0, … ,9, such as “1 Control 0”, for pass 1 and control 0. Including the load times significantly increases the math run times, since the math load time is larger than the corresponding math display time. Run times for simple text displayed by GDI’s ExtTextOut and DWrite’s IDWriteTextLayout are included for comparison. The computer used is a Hewlett Packard Z400 running Windows Server 2012 R2 Datacenter. RichEdit also has a fast GDI path (no LineServices) for simple text (no complex scripts), for which the simple case ran in 0.15 seconds. LineServices was active for RichEdit run times in the table. Two kinds of D2D/DWrite run times are listed: elegant typography and simple typography (ST). The latter only glyphs complex script runs and is significantly faster especially for single-line scenarios. It’s used by OneNote and Excel Universal.

 Text type Ext TextOut IDWrite TextLay RE GDI RE D2D RE D2D ST RE GDI PTS RE D2D PTS RE D2D PTS ST Simple 0.03 0.09 0.35 0.44 0.17 0.43 0.66 0.38 BiDi 0.25 0.32 0.77 1.18 0.62 1.07 1.40 1.03 Ruby — — 1.32 1.77 1.12 1.61 2.03 1.45 Math — — 8.07 4.93 2.80 15.17 4.93 4.62

The simple text has strings like “Control 0”, the BiDi case has strings like “س Control 0”. The ruby object case is  meaning Japanese (nihongo) and the math text is the Pythagorean Theorem, entered via the linear format string a^2+b^2=c^2.

It’s striking that the D2D paths are significantly faster than the GDI paths for math zones. It will be interesting to examine these scenarios with profiling tools to see where we can improve the run times further. The math run times also depend on the format used for math strings. For the DWrite simple typography mode, the times are: RTF—2.46, linear format—2.80, MathML—3.34, and OMML—3.54.

When flyweight controls are used (one RichEdit control with 300 stories), the run times are about the same as with 300 single-story controls and about 30% less memory is used. This memory savings is reduced as the text size is increased, since the control overhead becomes a smaller fraction of the total memory usage.

Studying performance profiles reveals a couple of performance losses. With the RichEdit fast GDI path, there’s a call to GetObjectType to determine if the device context for rendering is an enhanced metafile. If this call is eliminated, the run time drops from 0.15 to 0.12. The difference becomes smaller the more lines one renders at a time.

The DWrite simple typography times are better than the enhanced typography times in large part because the LineServices line object cached when measuring a line is voided when the line is rendered and hence has to be recreated for rendering. This also becomes less important as more lines are rendered, since the line cache is voided whenever another line is measured and all line objects have to be recreated at render time.

From the run times in the table, it’s easy to conclude that using the OS APIs is considerably faster than using RichEdit for text that can be displayed by those APIs. When ruby or mathematical text is involved, the OS APIs are inadequate and RichEdit or some other more powerful rendering engine is needed. If the simple text needs to be edited, a RichEdit control can be instantiated for that instance. This is the approach used by Universal Excel. The challenge then arises to avoid glitches, e.g., font changes, going from the system function display to the RichEdit display. With general international text, avoiding all glitches can be quite tricky.

## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • August 30, 2015 • Permalink

On 08/30/2015 10:21 PM, Neil Soiffer wrote:
> You are indeed right and I'm wrong. For whatever reason, the \big (and
> \bigg) versions of those characters produce very different looking
> characters than the non-stretched ones in LaTeX.
This is weird...
> So I agree with David's original suggestion for the values.
BTW, while we are talking about that, Unicode defines the curly braces
as mirrorables while the moustaches are not. This means that Gecko /
WebKit won't mirror the moustaches in RTL math. I don't know whether or
not that's what we want...

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Neil Soiffer (NeilS@dessci.com) • August 30, 2015 • Permalink

You are indeed right and I'm wrong. For whatever reason, the \big (and
\bigg) versions of those characters produce very different looking
characters than the non-stretched ones in LaTeX.

So I agree with David's original suggestion for the values.

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~

On Sun, Aug 30, 2015 at 12:39 PM, Khaled Hosny <khaledhosny@eglug.org>
wrote:

> On Sun, Aug 30, 2015 at 12:24:35PM -0700, Neil Soiffer wrote:
> > I believe that the entry in http://www.w3.org/TR/xml-entity-names is
> wrong.
> >
> > I wrote an example in LaTeX and 23B0 & 23B1 are *not* the glpyhs that
> LaTeX
> > produces.
>
> CM fonts seem to not have normal size glyphs for those two, try
> \big\lmoustache and \big\rmoustache. The TeXbook only shows the big
> glyphs.
>
> Regards,
> Khaled
>


## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Khaled Hosny (khaledhosny@eglug.org) • August 30, 2015 • Permalink

On Sun, Aug 30, 2015 at 12:24:35PM -0700, Neil Soiffer wrote:
> I believe that the entry in http://www.w3.org/TR/xml-entity-names is wrong.
>
> I wrote an example in LaTeX and 23B0 & 23B1 are *not* the glpyhs that LaTeX
> produces.

CM fonts seem to not have normal size glyphs for those two, try
\big\lmoustache and \big\rmoustache. The TeXbook only shows the big
glyphs.

Regards,
Khaled


## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Neil Soiffer (NeilS@dessci.com) • August 30, 2015 • Permalink

I believe that the entry in http://www.w3.org/TR/xml-entity-names is wrong.

I wrote an example in LaTeX and 23B0 & 23B1 are *not* the glpyhs that LaTeX
produces. Not surprisingly, the characters that LaTeX uses look like the
left and right sides of a mustache. I've attached a source file and PDF
file, but I don't know if the w3 mailer will pass these on through. I also
attached an image of the PDF because I don't know if pdflatex embedded the
fonts it used into the PDF file.

It is good to have renderers be consistent, but MathJax is not consistent
with what it is trying to emulate. Making Gecko be consistent with that
mistake seems like an additional mistake.

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~

[image: Inline image 1]

On Sun, Aug 30, 2015 at 1:14 AM, Frédéric WANG <fred.wang@free.fr> wrote:

> On 08/30/2015 08:45 AM, Neil Soiffer wrote:
>
> Are you sure you have the mapping of lmoustache/rmoustache correct? It
> seems very strange to map them to a piece of a *vertical *delimiter.
>
> The unicode.xml file from http://www.w3.org/TR/xml-entity-names/ defines
> "moustach" LaTeX macros and entity names:
>
>       <character id="U023B0" dec="9136" mode="math" type="other">
>          <unicodedata category="Sm" combclass="0" bidi="ON" mirror="N"
> mathclass="R"/>
>          <afii>EEE7</afii>
>          <latex>\lmoustache </latex>
>          <mathlatex set="unicode-math">\lmoustache</mathlatex>
>          <AMS>\lmoustache</AMS>
>          <IEEE>\lmoustache</IEEE>
>          <entity id="lmoust" set="STIX"/>
>          <entity id="lmoust" set="9573-1991-isoamsc">
>             <desc>/lmoustache</desc>
>          </entity>
>          <entity id="lmoust" set="9573-2003-isoamsc">
>             <desc>/lmoustache</desc>
>          </entity>
>          <entity id="lmoustache" set="mmlalias">
>             <desc>alias ISOAMSC lmoust</desc>
>          </entity>
>          <description unicode="3.2">UPPER LEFT OR LOWER RIGHT CURLY
> BRACKET SECTION</description>
>       </character>
>       <character id="U023B1" dec="9137" mode="math" type="other">
>          <unicodedata category="Sm" combclass="0" bidi="ON" mirror="N"
> mathclass="R"/>
>          <afii>EEE8</afii>
>          <latex>\rmoustache </latex>
>          <mathlatex set="unicode-math">\rmoustache</mathlatex>
>          <AMS>\rmoustache</AMS>
>          <IEEE>\rmoustache</IEEE>
>          <entity id="rmoust" set="STIX"/>
>          <entity id="rmoust" set="9573-1991-isoamsc">
>             <desc>/rmoustache</desc>
>          </entity>
>          <entity id="rmoust" set="9573-2003-isoamsc">
>             <desc>/rmoustache</desc>
>          </entity>
>          <entity id="rmoustache" set="mmlalias">
>             <desc>alias ISOAMSC rmoust</desc>
>          </entity>
>          <font name="hlcrv" pos="123"/>
>          <description unicode="3.2">UPPER RIGHT OR LOWER LEFT CURLY
> BRACKET SECTION</description>
>       </character>
>
> and I didn't find another characters to represent moustaches in the MathML
> Operator dictionary...
>
> Of course, there's nothing stopping you from adding them to Gecko's
> operator dictionary, but if we added these to the one in the spec, why not
> add all the other pieces?
>
> To be clear: I'm only interested in making MathML work in concrete use
> cases, not to extend the spec to cover non-practical cases via abstract
> generalization as that happened when I raised the issue with menclose's
> updiagonalstrike. Gecko and itex2MML have used these mappings for a long
> time and I just checked that MathJax does the same, so that's a case worth
> considering.
>
> In general, I suppose it's not an unreasonable assumption to assume that
> if a piece of a stretchy operator is used as an operator, then it has the
> properties of the entire delimiter.
>
> That's what David says but I'm not sure we can make any assumption or
> reject the operator just because Unicode defines it as a piece of something
> else. I suspect what happened is that LaTeX/MathML people just wanted to
> implement \lmoustache & \rmoustache operators and they just took these two
> U+23B0 and U+23B1 characters because Unicode did not have specific code
> points to represent these operators. Probably from a "semantic" point of
> view it would have been better to create such separate code points...
>
> On the other hand, if someone is using a piece of a stretchy char, I
> suspect they are making up their own operator and who knows what its
> default properties should be.
>
> However when several popular applications use the same operators, adding
> it to the operator dictionary will help to be consistent. Like Gecko,
> MathJax treats 23B0 & 23B1 with default values fence, stretchy and
> symmetric and no spacing around:
>
>
> https://github.com/mathjax/MathJax/blob/master/unpacked/jax/element/mml/jax.js#L1761
>
> https://github.com/mathjax/MathJax/blob/master/unpacked/jax/element/mml/jax.js#L1480
>
> WebKit relies only on the official MathML operator dictionary so it will
> use the default value (not fence, not stretchy, not symmetric and
> thickmathspace around)
>
> For "\left\lmoustache x \right\rmoustache", itex2MML generates
>
> <mrow><mo>&lmoustache;</mo><mi>x</mi><mo>&rmoustache;</mo></mrow>
>
> and MathJax generates the same with explicit fence and stretchy. So the
> "symmetric" and surrounding spacing will be wrong in WebKit and in any
> other MathML rendering engines that do not have "private" entries for these
> two characters.
>
> Also the same command does not work in TeXZilla, because it relies on the
> official operator dictionary and so does not know that moustaches are a
> stretchy fences. LaTeXML also fails to parse this expression.
>
> Finally, when discussing with designers of OpenType fonts with a MATH
> table, I often refers to the official MathML Operator Dictionary to
> indicate which characters should be stretchable. At the moment existing
> fonts do not have constructions for 23B0 & 23B1 while Gecko has it in its
> private Unicode constructions so we again obtain inconsistent results. For
> example, Gecko is able to stretch moustaches with the deprecated STIX
> General but not the newest STIX Math (hopefully this will be fixed in
> version 2, see http://sourceforge.net/p/stixfonts/tracking/67/)
>
> --
> Frédéric Wangmaths-informatique-jeux.com/blog/frederic
>
>



## RE: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • August 30, 2015 • Permalink

The original proposal to the Unicode Technical Committee for encoding these symbols is http://www.unicode.org/L2/L1999/99043.htm. That document is concerned with brace pieces for building up arbitrarily large braces. But conceivably TeX already overloaded its use of such pieces for for l/rmoustache.

+Barbara

Murray



## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • August 30, 2015 • Permalink

On 08/30/2015 08:45 AM, Neil Soiffer wrote:
> Are you sure you have the mapping of lmoustache/rmoustache correct? It
> seems very strange to map them to a piece of a /vertical /delimiter.
The unicode.xml file from http://www.w3.org/TR/xml-entity-names/ defines
"moustach" LaTeX macros and entity names:

<character id="U023B0" dec="9136" mode="math" type="other">
<unicodedata category="Sm" combclass="0" bidi="ON" mirror="N"
mathclass="R"/>
<afii>EEE7</afii>
<latex>\lmoustache </latex>
<mathlatex set="unicode-math">\lmoustache</mathlatex>
<AMS>\lmoustache</AMS>
<IEEE>\lmoustache</IEEE>
<entity id="lmoust" set="STIX"/>
<entity id="lmoust" set="9573-1991-isoamsc">
<desc>/lmoustache</desc>
</entity>
<entity id="lmoust" set="9573-2003-isoamsc">
<desc>/lmoustache</desc>
</entity>
<entity id="lmoustache" set="mmlalias">
<desc>alias ISOAMSC lmoust</desc>
</entity>
<description unicode="3.2">UPPER LEFT OR LOWER RIGHT CURLY
BRACKET SECTION</description>
</character>
<character id="U023B1" dec="9137" mode="math" type="other">
<unicodedata category="Sm" combclass="0" bidi="ON" mirror="N"
mathclass="R"/>
<afii>EEE8</afii>
<latex>\rmoustache </latex>
<mathlatex set="unicode-math">\rmoustache</mathlatex>
<AMS>\rmoustache</AMS>
<IEEE>\rmoustache</IEEE>
<entity id="rmoust" set="STIX"/>
<entity id="rmoust" set="9573-1991-isoamsc">
<desc>/rmoustache</desc>
</entity>
<entity id="rmoust" set="9573-2003-isoamsc">
<desc>/rmoustache</desc>
</entity>
<entity id="rmoustache" set="mmlalias">
<desc>alias ISOAMSC rmoust</desc>
</entity>
<font name="hlcrv" pos="123"/>
<description unicode="3.2">UPPER RIGHT OR LOWER LEFT CURLY
BRACKET SECTION</description>
</character>

and I didn't find another characters to represent moustaches in the
MathML Operator dictionary...
> Of course, there's nothing stopping you from adding them to Gecko's
> operator dictionary, but if we added these to the one in the spec, why
> not add all the other pieces?
To be clear: I'm only interested in making MathML work in concrete use
cases, not to extend the spec to cover non-practical cases via abstract
generalization as that happened when I raised the issue with menclose's
updiagonalstrike. Gecko and itex2MML have used these mappings for a long
time and I just checked that MathJax does the same, so that's a case
worth considering.
> In general, I suppose it's not an unreasonable assumption to assume
> that if a piece of a stretchy operator is used as an operator, then it
> has the properties of the entire delimiter.
That's what David says but I'm not sure we can make any assumption or
reject the operator just because Unicode defines it as a piece of
something else. I suspect what happened is that LaTeX/MathML people just
wanted to implement \lmoustache & \rmoustache operators and they just
took these two U+23B0 and U+23B1 characters because Unicode did not have
specific code points to represent these operators. Probably from a
"semantic" point of view it would have been better to create such
separate code points...
> On the other hand, if someone is using a piece of a stretchy char, I
> suspect they are making up their own operator and who knows what its
> default properties should be.
However when several popular applications use the same operators, adding
it to the operator dictionary will help to be consistent. Like Gecko,
MathJax treats 23B0 & 23B1 with default values fence, stretchyand
symmetric and no spacing around:

https://github.com/mathjax/MathJax/blob/master/unpacked/jax/element/mml/jax.js#L1761
https://github.com/mathjax/MathJax/blob/master/unpacked/jax/element/mml/jax.js#L1480

WebKit relies only on the official MathML operator dictionary so it will
use the default value (not fence, not stretchy, not symmetric and
thickmathspace around)

For "\left\lmoustache x \right\rmoustache", itex2MML generates

<mrow><mo>&lmoustache;</mo><mi>x</mi><mo>&rmoustache;</mo></mrow>

and MathJax generates the same with explicit fence and stretchy. So the
"symmetric" and surrounding spacing will be wrong in WebKit and in any
other MathML rendering engines that do not have "private" entries for
these two characters.

Also the same command does not work in TeXZilla, because it relies on
the official operator dictionary and so does not know that moustaches
are a stretchy fences. LaTeXML also fails to parse this expression.

Finally, when discussing with designers of OpenType fonts with a MATH
table, I often refers to the official MathML Operator Dictionary to
indicate which characters should be stretchable. At the moment existing
fonts do not have constructions for 23B0 & 23B1 while Gecko has it in
its private Unicode constructions so we again obtain inconsistent
results. For example, Gecko is able to stretch moustaches with the
deprecated STIX General but not the newest STIX Math (hopefully this
will be fixed in version 2, see
http://sourceforge.net/p/stixfonts/tracking/67/)

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Neil Soiffer (NeilS@dessci.com) • August 30, 2015 • Permalink

I'm kind of dubious about including U+23B0 and U+23B1. Unicode says these
are:
U+23B0 <http://www.fileformat.info/info/unicode/char/23b0/index.htm> UPPER
LEFT OR LOWER RIGHT CURLY BRACKET SECTION ⎰ [image: sample of UPPER LEFT OR
LOWER RIGHT CURLY BRACKET SECTION (U+23B0)]
U+23B1 <http://www.fileformat.info/info/unicode/char/23b1/index.htm> UPPER
RIGHT OR LOWER LEFT CURLY BRACKET SECTION ⎱ [image: sample of UPPER RIGHT
OR LOWER LEFT CURLY BRACKET SECTION (U+23B1)]

Are you sure you have the mapping of lmoustache/rmoustache correct? It
seems very strange to map them to a piece of a *vertical *delimiter. Of
course, there's nothing stopping you from adding them to Gecko's operator
dictionary, but if we added these to the one in the spec, why not add all
the other pieces?

In general, I suppose it's not an unreasonable assumption to assume that if
a piece of a stretchy operator is used as an operator, then it has the
properties of the entire delimiter. On the other hand, if someone is using
a piece of a stretchy char, I suspect they are making up their own operator
and who knows what its default properties should be.

As with David's reply, just my own opinion and not necessarily that of the
Math WG.

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~

On Fri, Aug 28, 2015 at 8:05 AM, Frédéric Wang <fred.wang@free.fr> wrote:

> Dear all,
>
> It seems that lmoustache/rmoustache have been used as MathML stretchy
> operators for a long time. For example, itex2MML provides the \lmoustache &
> \rmoustache commands to generate these delimiters:
>
>
> https://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html#itex2MMLDelim
>
> and Gecko has entries for U+23B0 and U+23B1:
>
>
> https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathfont.properties?offset=300#1137
>
> However, the MathML Operator dictionary does not contain any mention of
> lmoustache/rmoustache:
>
> http://www.w3.org/TR/MathML3/appendixc.html
>
> Should they be added to the official MathML dictionary or are they
> excluded on purpose?
>
> Frédéric
>
>


## Re: Clipboard API: remove dangerous formats from mandatory data types

Source: public-webapps@w3.org Mail Archives • Paul Libbrecht (paul@hoplahup.net) • August 29, 2015 • Permalink

Hello Hallvord,

> Hallvord Reiar Michaelsen Steen <mailto:hsteen@mozilla.com>
> 27 août 2015 18:32
> On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht <paul@hoplahup.net
> <mailto:paul@hoplahup.net>> wrote:
>
>     do you not want to split the writable types list in safe and
>     non-safe ones and let browsers how they deal with unsafe ones?
>
>
> No, absolutely not. If we leave such things up to the browser we end
> up with implementations that do wildly different things and web
> developers suffering new levels of incompatibility pain.
I mean, let them decide if they support it or not.
>
>     Here's an idea:
>
>     html, xml, and picture formats should be in the unsafe ones.
>
>
> If we can help it, HTML should not be unsafe. It's the web's primary
> format, and if we class it as unsafe we basically prohibit scripts
> from being able to export formatted text to the clipboard.
>
> I do however know it takes a bit of a leap of faith to believe that
> it's safe enough, given that HTML parsing was a bit of a dark art for
> many years. Today we can at least hope a lot of software that consumes
> HTML has been updated to use HTML5 algorithms.
HTML5 has changed the parsing algorithm indeed.
But copying a fragment of HTML in the wild without reformulating it will
lead to privacy breach: it would copy references to external content. I
believe all browsers have an "inlining" method to solve that problem
when pasting from a web-page (I believe "save as web page complete" also
does a part of that).

>
>
>     I guess json too (but both XML and JSON are too generic to my taste).
>
>
> Why should JSON be unsafe? Parsing JSON should be pretty easy, so
> hopefully most parsers would be safe.
I think the danger lies beyond parsers.
In XML, you would have XInclude which can be used in many tools to
include content from outside.
I believe I have seen JSON syntaxes that had external references as part
of their specs but I can't remember which now.
As long these formats are copied as is and parsed blindly the risk of
external inclusion remains.

However, it is true that I do not know of applications that receive
application/xml or text/json without being web-aware or even developer
aware... I am not sure what to suggest here.
(sniffing xml or json in the plain text is commonly done in many apps is
actually much worse in terms o security).
>
>
>     For the unsafe formats, the warning could say that the
>     UA-implementors should only support the flavour if they have a
>     method to make this content safe so that local applications (which
>     do not expect untrusted content) receive content they can trust
>     when pasting. Methods to make the content safe include the
>     following: transcoding a picture, inlining all external entities
>     for html, xml, mathml, or rtf).
>
>
> On Windows I believe images are transcoded to and from DIB - device
> independent bitmap format anyway. Is there any equivalent graphics
> interchange format on other platforms? Does mandating such transcoding
> help guarantee against payloads that might trigger vulnerabilities in
> target software?
All platforms I know of have some sort of transcoding of pictures (in
Macs it is PDF as the central format).
I think this is a very safe mechanism to rely on.
> I expect it adds a significant hurdle against exploits, but I'd like
> input from Daniel Cheng and perhaps from people who have worked on
> image decoders..
> -Hallvord

paul


## Re: lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • August 28, 2015 • Permalink

On 28/08/2015 16:05, Frédéric Wang wrote:
> Dear all,
>
> It seems that lmoustache/rmoustache have been used as MathML stretchy operators for a long time. For example, itex2MML provides the \lmoustache & \rmoustache commands to generate these delimiters:
>
> https://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html#itex2MMLDelim
>
> and Gecko has entries for U+23B0 and U+23B1:
>
> https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathfont.properties?offset=300#1137
>
> However, the MathML Operator dictionary does not contain any mention of lmoustache/rmoustache:
>
> http://www.w3.org/TR/MathML3/appendixc.html
>
> Should they be added to the official MathML dictionary or are they excluded on purpose?
>
> Frédéric
>

I'm fairly sure they were not excluded on purpose.

{ and } have

<operator-dictionary priority="20" form="prefix"
symmetric="true" fence="true" stretchy="true" lspace="0" rspace="0"/>

<operator-dictionary priority="20" form="postfix"
symmetric="true" fence="true" stretchy="true" lspace="0" rspace="0"/>

so I suspect exactly the same entries could be added to [lr]moustache?

David
[speaking personally, not a WG decision]

________________________________

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________


## Re: Fwd: [Moderator Action] RE: Active lobbying: Math

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • August 28, 2015 • Permalink

+1 to Bill's response in general. To add to that.

> What can be added to CSS that would clean up both the style and markup?

This is difficult to answer because the MathML spec implements a ton of
layout features and they are not necessarily organized in a CSS-compatible
way (or even CSS compatible). When I wrote "it's possible today", I did not
mean it is not one big ugly hack. It's not as bad as PDFjs output but maybe
not by far ;-) I would compare it to doing flexboxy things without flexbox
(or really: doing 10 flexboxy things wrapped inside each other without
having any of them available).

> What parts of that could actually be useful in other contexts?

Off the top of my head: Improved sub/superscripts and better glyph control
would be great for typography in general. Multiscripts are common in many
scientific notations, I was talking to Dave about possible connections
between munderover and Ruby, also, this wcig thread
<http://discourse.wicg.io/t/position-an-element-relatively-to-another-element-from-anywhere-in-the-dom/968>
connects,
MathML needs more advanced borders (for menclose and elementary math
notation, but I'm crazy and would even add stretchy characters here),
mtable is in parts more advanced than html table (in-table alignments etc).

Again, this is just shooting from the hip -- I think we would need a more
serious effort to really dissect this question.

Peter.

On Tue, Aug 25, 2015 at 8:04 PM, Bill Kasdorf <bkasdorf@apexcovantage.com>
wrote:

> Re Robin's:
> >• What can be added to CSS that would clean up both the style and markup?
> What parts of that could actually be useful in other contexts?
>
> I think this is absolutely key to making progress on this. What this means
> is thinking about the things that need to be done for math in a more
> problem").
>
> I'm certainly not saying this would get us good, complete MathML
> implementation, but it might help get some progress.
>
> Off the top of my head, I can immediately see some general issues that
> could be abstracted (admittedly, these might be seen as just as seldom
> needed as math, but here goes). Plus apologies if we _already_ have these
> solutions; I am not intimately familiar with CSS. These are the kinds of
> things that I naively think already _must_ be handled by CSS and then am
> surprised to see there are problems.
>
> --Marking points at the phrase level at which other successive things
> (usually "the next line" but not always) that follow vertically must align
> horizontally. (The fuzzy nontechnical language is deliberate.) Being an
> English major, I immediately think of poetry; this is a huge issue in drama
> and poetry. But because those are just as arcane as math, I would point out
> that as a typographer this comes up all the time. I am quite sure that is
> already on Dave Cramer's list of to-be-worked-on use cases for CSS; and I
> would guess it's fundamental to bidi and vertical reading; I'm just
> pointing out that it is a basic feature of math that actually has lots of
> analogs outside of math. Most general: "if the line runs over, indent the
> remainder to align with this otherwise arbitrary point." Happens all the
> time. Quite sure this is not news to anybody.
>
> --Building up of big things from small components, especially vertically.
> Example from math: bracket that keeps growing until it is told to end. You
> want to wind up with one big thing but when you start you don't know how
> big the thing is. Related to but not the same as stretching. Because the
> solution in math is commonly assembling "segments" (usually three different
> kinds, a top one, middle ones, and an end one), we get into the next point:
>
> --And I'm sure I don't have to mention all the Unicode issues. You can't
> spit without hitting a Unicode issue in math. ;-) Also see fonts, and
> glyphs. Certainly a general issue that happens to be fundamental and
> issue. . . .
>
> Just some thoughts from a not-as-technical-as-the-rest-of-you guy. I just
> mainly want to point out that the idea of looking at what aspects of MathML
> have wider relevance might get us somewhere. Maybe even the realization
> that _we're already working on_ some of the things MathML needs.
>
> --Bill Kasdorf
>
>
>
> -----Original Message-----
> From: Robin Berjon [mailto:robin@w3.org]
> Sent: Tuesday, August 25, 2015 5:21 AM
> To: Peter Krautzberger; W3C Digital Publishing IG
> Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math
>
> On 24/08/2015 21:47 , Peter Krautzberger wrote:
> > I think the main problem is that nobody really knows what it would
> > technically require to implement good math layout in browser engines
> > or what it would take to implement good MathML support.
>
> Nobody might be stretching it, but it's certainly a very small group.
>
> > * In my experience, both browser vendors, publisher, and third party
> > vendors have surprisingly little knowledge of
> >    * MathML as a markup language
> >    * math layout in general
> >    * MathML layout specifically
> >    * math layout using OWP tech
> >    * math accessibility using OWP tech
>
> Part of the problem there is that you don't just easily fall into MathML
> in an incremental manner, say by first trying to tweak the rendering of
> something perhaps even as trivial as <var>x</var> and then building up from
> there. The first step is relatively steep compared to many other parts of
> the platform.
>
> > * The ARIA spec has a massive hole where mathematics should be.
>
> Asking naïvely: is there any reason not to start fixing this right now?
>
> > * Neither browsers nor publishers are active in the MathWG (ok, maybe
> > 1 exception).
> >
> > * The MathML spec needs some work in an HTML5 context
> >    * MathML has been "out of sync" (for lack of a better term) with
> > HTML/CSS/SVG for a while
> >    * MathML duplicates HTML/CSS features (sometimes the features are
> > not compatible though never critically so imho)
> >    * MathML hides quite a few complex layout features behind math
> > syntax, complicating the implementation of both
> >    * ContentMathML has failed outside of CAS.
> >
> > Another key problem is: MathML is neither necessary nor sufficient for
> > math layout on the web. Nowadays, HTML/CSS implementations are good
> > enough for (high quality) math/MathML layout. I'm not speaking of
> > client-side JS-driven rendering but of (server-side) HTML+CSS
> > generation that looks the same on all recent browsers.
>
> That sounds like a great opportunity and a good starting point to rethink
> MathML.
>
> Starting from HTML+CSS code that's ugly and poorly accessible, but at
> least sports high-quality layout:
>
>    • What can be added to CSS that would clean up both the style and
> markup? What parts of that could actually be useful in other context?
>
>    • What can be done to make it properly accessible, ideally built-in
> rather than bolt-on?
>
>    • What could be added to HTML to make the markup simpler and more
> semantic, possibly by importing some elements from MathML more or less
> directly, without requiring them to be in a MathML context but without
> duplicating HTML functionality?
>
> Extensible Web Manifesto spirit would surely help.
>
> And I'm sure the WICG could be a great place to entertain
> (non-monolithic) new ideas and hash them out with support from browser
> vendors.
>
> > Personally, I don't think MathML will be implemented in browsers
> > (though I'd be extremely happy to be wrong here and will support any
> > effort in this group). I do think there are more realistic alternative
> > goals such as improving CSS implementations incrementally and
> > developing standards for exposing underlying data such as MathML to
> tools such as AT.
>
> +1
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>


## lmoustache/rmoustache as stretchy delimiters

Source: www-math@w3.org Mail Archives • Frédéric Wang (fred.wang@free.fr) • August 28, 2015 • Permalink

Dear all,

It seems that lmoustache/rmoustache have been used as MathML stretchy operators for a long time. For example, itex2MML provides the \lmoustache & \rmoustache commands to generate these delimiters:

https://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html#itex2MMLDelim

and Gecko has entries for U+23B0 and U+23B1:

https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathfont.properties?offset=300#1137

However, the MathML Operator dictionary does not contain any mention of lmoustache/rmoustache:

http://www.w3.org/TR/MathML3/appendixc.html

Should they be added to the official MathML dictionary or are they excluded on purpose?

Frédéric


## Re: Clipboard API: remove dangerous formats from mandatory data types

Source: public-webapps@w3.org Mail Archives • Hallvord Reiar Michaelsen Steen (hsteen@mozilla.com) • August 27, 2015 • Permalink

On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht <paul@hoplahup.net> wrote:

> Hallvord,
>
> do you not want to split the writable types list in safe and non-safe ones
> and let browsers how they deal with unsafe ones?
>

No, absolutely not. If we leave such things up to the browser we end up
with implementations that do wildly different things and web developers
suffering new levels of incompatibility pain.

> Here's an idea:
>
> html, xml, and picture formats should be in the unsafe ones.
>

If we can help it, HTML should not be unsafe. It's the web's primary
format, and if we class it as unsafe we basically prohibit scripts from
being able to export formatted text to the clipboard.

I do however know it takes a bit of a leap of faith to believe that it's
safe enough, given that HTML parsing was a bit of a dark art for many
years. Today we can at least hope a lot of software that consumes HTML has
been updated to use HTML5 algorithms.

> I guess json too (but both XML and JSON are too generic to my taste).
>

Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
most parsers would be safe.

> For the unsafe formats, the warning could say that the UA-implementors
> should only support the flavour if they have a method to make this content
> safe so that local applications (which do not expect untrusted content)
> receive content they can trust when pasting. Methods to make the content
> safe include the following: transcoding a picture, inlining all external
> entities for html, xml, mathml, or rtf).
>

On Windows I believe images are transcoded to and from DIB - device
independent bitmap format anyway. Is there any equivalent graphics
interchange format on other platforms? Does mandating such transcoding help
guarantee against payloads that might trigger vulnerabilities in target
software? I expect it adds a significant hurdle against exploits, but I'd
like input from Daniel Cheng and perhaps from people who have worked on
image decoders..
-Hallvord


## RE: Fwd: [Moderator Action] RE: Active lobbying: Math

Source: public-digipub-ig@w3.org Mail Archives • Bill Kasdorf (bkasdorf@apexcovantage.com) • August 25, 2015 • Permalink

Re Robin's:
>• What can be added to CSS that would clean up both the style and markup? What parts of that could actually be useful in other contexts?

I think this is absolutely key to making progress on this. What this means is thinking about the things that need to be done for math in a more abstract way (e.g., "this is not about the math, it's about this layout problem").

I'm certainly not saying this would get us good, complete MathML implementation, but it might help get some progress.

Off the top of my head, I can immediately see some general issues that could be abstracted (admittedly, these might be seen as just as seldom needed as math, but here goes). Plus apologies if we _already_ have these solutions; I am not intimately familiar with CSS. These are the kinds of things that I naively think already _must_ be handled by CSS and then am surprised to see there are problems.

--Marking points at the phrase level at which other successive things (usually "the next line" but not always) that follow vertically must align horizontally. (The fuzzy nontechnical language is deliberate.) Being an English major, I immediately think of poetry; this is a huge issue in drama and poetry. But because those are just as arcane as math, I would point out that as a typographer this comes up all the time. I am quite sure that is already on Dave Cramer's list of to-be-worked-on use cases for CSS; and I would guess it's fundamental to bidi and vertical reading; I'm just pointing out that it is a basic feature of math that actually has lots of analogs outside of math. Most general: "if the line runs over, indent the remainder to align with this otherwise arbitrary point." Happens all the time. Quite sure this is not news to anybody.

--Building up of big things from small components, especially vertically. Example from math: bracket that keeps growing until it is told to end. You want to wind up with one big thing but when you start you don't know how big the thing is. Related to but not the same as stretching. Because the solution in math is commonly assembling "segments" (usually three different kinds, a top one, middle ones, and an end one), we get into the next point:

--And I'm sure I don't have to mention all the Unicode issues. You can't spit without hitting a Unicode issue in math. ;-) Also see fonts, and glyphs. Certainly a general issue that happens to be fundamental and pervasive in math. Many many many people in the world care about this issue. . . .

Just some thoughts from a not-as-technical-as-the-rest-of-you guy. I just mainly want to point out that the idea of looking at what aspects of MathML have wider relevance might get us somewhere. Maybe even the realization that _we're already working on_ some of the things MathML needs.

--Bill Kasdorf

-----Original Message-----
From: Robin Berjon [mailto:robin@w3.org]
Sent: Tuesday, August 25, 2015 5:21 AM
To: Peter Krautzberger; W3C Digital Publishing IG
Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math

On 24/08/2015 21:47 , Peter Krautzberger wrote:
> I think the main problem is that nobody really knows what it would
> technically require to implement good math layout in browser engines
> or what it would take to implement good MathML support.

Nobody might be stretching it, but it's certainly a very small group.

> * In my experience, both browser vendors, publisher, and third party
> vendors have surprisingly little knowledge of
>    * MathML as a markup language
>    * math layout in general
>    * MathML layout specifically
>    * math layout using OWP tech
>    * math accessibility using OWP tech

Part of the problem there is that you don't just easily fall into MathML in an incremental manner, say by first trying to tweak the rendering of something perhaps even as trivial as <var>x</var> and then building up from there. The first step is relatively steep compared to many other parts of the platform.

> * The ARIA spec has a massive hole where mathematics should be.

Asking naïvely: is there any reason not to start fixing this right now?

> * Neither browsers nor publishers are active in the MathWG (ok, maybe
> 1 exception).
>
> * The MathML spec needs some work in an HTML5 context
>    * MathML has been "out of sync" (for lack of a better term) with
> HTML/CSS/SVG for a while
>    * MathML duplicates HTML/CSS features (sometimes the features are
> not compatible though never critically so imho)
>    * MathML hides quite a few complex layout features behind math
> syntax, complicating the implementation of both
>    * ContentMathML has failed outside of CAS.
>
> Another key problem is: MathML is neither necessary nor sufficient for
> math layout on the web. Nowadays, HTML/CSS implementations are good
> enough for (high quality) math/MathML layout. I'm not speaking of
> client-side JS-driven rendering but of (server-side) HTML+CSS
> generation that looks the same on all recent browsers.

That sounds like a great opportunity and a good starting point to rethink MathML.

Starting from HTML+CSS code that's ugly and poorly accessible, but at least sports high-quality layout:

• What can be added to CSS that would clean up both the style and markup? What parts of that could actually be useful in other context?

• What can be done to make it properly accessible, ideally built-in rather than bolt-on?

• What could be added to HTML to make the markup simpler and more semantic, possibly by importing some elements from MathML more or less directly, without requiring them to be in a MathML context but without duplicating HTML functionality?

I'm repeating both myself and others, but going about this with an Extensible Web Manifesto spirit would surely help.

And I'm sure the WICG could be a great place to entertain
(non-monolithic) new ideas and hash them out with support from browser vendors.

> Personally, I don't think MathML will be implemented in browsers
> (though I'd be extremely happy to be wrong here and will support any
> effort in this group). I do think there are more realistic alternative
> goals such as improving CSS implementations incrementally and
> developing standards for exposing underlying data such as MathML to tools such as AT.

+1

--
Robin Berjon - http://berjon.com/ - @robinberjon



## Re: [Moderator Action] RE: Active lobbying: Math

Source: public-digipub-ig@w3.org Mail Archives • Richard Schwerdtfeger (schwer@us.ibm.com) • August 25, 2015 • Permalink


Robin,

ARIA 1.0 was done to address the accessibility of Rich Internet
Application. Although we are working on a 1.1 to address gaps for that type
of content in 1.0, we now have an extension process. We have expanded to
create modules for book digital publishing semantics and also graphics. So,
if you look at the creation off multiple semantic taxonomies we have only
scratched the surface. Math is an obvious essential next step for ARIA.
Unfortunately, our charter is being held in limbo right now by some AC
members. This is also holding up ARIA extensions for web components. I hope
it gets resolved soon. The extension process was put in place so that work
on new modules could start without making the ARIA working group main body
a bottle neck to innovation in new taxonomies like Math.

If we are to do an ARIA module for Math it would require a joint task force
between the new ARIA working group and I think the Math WG with additional
invited experts of course. We would need MathJax people to participate or
even lead the effort. Other than having the new charter approved and
committed people I don't see why this work could not start.

I would argue that the accessibility of digital math is one of the most
important things we should be doing at W3C. It just has not gotten the due
has proven to grow math comprehension for all users by roughly 10 percent.

Rich

> On Aug 25, 2015, at 4:22 AM, Robin Berjon <robin@w3.org> wrote:
>
> On 24/08/2015 21:47 , Peter Krautzberger wrote:
> > I think the main problem is that nobody really knows what it would
> > technically require to implement good math layout in browser engines or
> > what it would take to implement good MathML support.
>
> Nobody might be stretching it, but it's certainly a very small group.
>
> > * In my experience, both browser vendors, publisher, and third party
> > vendors have surprisingly little knowledge of
> >    * MathML as a markup language
> >    * math layout in general
> >    * MathML layout specifically
> >    * math layout using OWP tech
> >    * math accessibility using OWP tech
>
> Part of the problem there is that you don't just easily fall into MathML
> in an incremental manner, say by first trying to tweak the rendering of
> something perhaps even as trivial as <var>x</var> and then building up
> from there. The first step is relatively steep compared to many other
> parts of the platform.
>
> > * The ARIA spec has a massive hole where mathematics should be.
>
> Asking naïvely: is there any reason not to start fixing this right now?
>
> > * Neither browsers nor publishers are active in the MathWG (ok, maybe 1
> > exception).
> >
> > * The MathML spec needs some work in an HTML5 context
> >    * MathML has been "out of sync" (for lack of a better term) with
> > HTML/CSS/SVG for a while
> >    * MathML duplicates HTML/CSS features (sometimes the features are
not
> > compatible though never critically so imho)
> >    * MathML hides quite a few complex layout features behind math
> > syntax, complicating the implementation of both
> >    * ContentMathML has failed outside of CAS.
> >
> > Another key problem is: MathML is neither necessary nor sufficient for
> > math layout on the web. Nowadays, HTML/CSS implementations are good
> > enough for (high quality) math/MathML layout. I'm not speaking of
> > client-side JS-driven rendering but of (server-side) HTML+CSS
generation
> > that looks the same on all recent browsers.
>
> That sounds like a great opportunity and a good starting point to
> rethink MathML.
>
> Starting from HTML+CSS code that's ugly and poorly accessible, but at
> least sports high-quality layout:
>
>    • What can be added to CSS that would clean up both the style and
> markup? What parts of that could actually be useful in other context?
>
>    • What can be done to make it properly accessible, ideally built-in
> rather than bolt-on?
>
>    • What could be added to HTML to make the markup simpler and more
> semantic, possibly by importing some elements from MathML more or less
> directly, without requiring them to be in a MathML context but without
> duplicating HTML functionality?
>
> Extensible Web Manifesto spirit would surely help.
>
> And I'm sure the WICG could be a great place to entertain
> (non-monolithic) new ideas and hash them out with support from browser
> vendors.
>
> > Personally, I don't think MathML will be implemented in browsers
(though
> > I'd be extremely happy to be wrong here and will support any effort in
> > this group). I do think there are more realistic alternative goals such
> > as improving CSS implementations incrementally and developing standards
> > for exposing underlying data such as MathML to tools such as AT.
>
> +1
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>


## Re: Fwd: [Moderator Action] RE: Active lobbying: Math

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • August 25, 2015 • Permalink

Re Robin.

> Asking naïvely: is there any reason not to start fixing this right now?

Community interest. Also, all other challenges in terms of math AT.

>  • What can be added to CSS that would clean up both the style and
markup? What parts of that could actually be useful in other context?
>  • What can be done to make it properly accessible, ideally built-in
rather than bolt-on?
>  • What could be added to HTML to make the markup simpler and more
semantic, possibly by importing some elements from MathML more or less
directly, without requiring them to be in a MathML context but without
duplicating HTML functionality?

I have a solution but it does not fit into the margin of this book.

Extensible Web Manifesto spirit would surely help.
>And I'm sure the WICG could be a great place to entertain
(non-monolithic) new ideas and hash them out with support from browser
vendors.

I think it's a bit early for that. It would also require quite a few
additional resources to pursue that path (at least from our perspective).

Peter.

On Tue, Aug 25, 2015 at 11:42 AM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

> Re Doug.
>
>
> > I think we could really benefit from taking a look at _why_ browser
> vendors aren't implementing MathML, learning those lessons, and making a
> new version of MathML that's easier to implement and maintain, easier to
> author, easier to style, and is better integrated into HTML5.
>
> +1 (but it's a rather tall order ;-) )
>
> > I've voiced this opinion to Peter before. I don't think we differ much,
>
> +1.
>
>
> Re Rich
>
> > What I have heard from some browser vendors is that there is just not
> enough MathML content out there and it is difficult to justify the
> performance hit.
>
> Performance is definitely a problem even for browser implementations. But
> it's hard to say if that's just for lack for interest from browser vendors.
> For example, earlier this year we had an edge case where MathJax
> outperformed native Firefox support (by a margin); this was quickly
> resolved once we got the attention of Rob O'Callahan at Mozilla.
>
> Re Rob.
>
> > The FXTF (a joint task force of SVG and CSS) might be a good model here.
>
> +1. One difference is that browser vendors were actually interested in
> implementing SVG features; I don't see that for math layout. Still,
> reactions from Houdini leave me mildly hopeful.
>
> > The FXTF split out things like filters, transforms, animation into
> their own modules. The effect is doubly beneficial: it is easier to focus
> on implementing smaller features and the user base for a feature that works
> in broader HTML+CSS contexts and use cases is much larger than that for
> just SVG.
>
> I'm not too sure about that. It was actually a very small math layout
> feature that triggered the removal of MathML from Chrome. (The Chrome team
> convinced itself that stretchy characters are somehow fundamentally
> incompatible with CSS layout.)
>
> Peter.
>
> On Tue, Aug 25, 2015 at 11:07 AM, Robin Berjon <robin@w3.org> wrote:
>
>> On 24/08/2015 23:43 , Doug Schepers wrote:
>>
>>> I think we could really benefit from taking a look at _why_ browser
>>> vendors aren't implementing MathML
>>>
>>
>> I won't claim that it's the final word from browser vendors, but this was
>> discussed extensively at Balisage last year. MathML suffers from the
>> combination of being a pretty large chunk with a relatively small community.
>>
>> learning those lessons, and making a new version of MathML that's
>>> easier to implement and maintain, easier to author, easier to style,
>>> and is better integrated into HTML5.
>>>
>>
>> The FXTF (a joint task force of SVG and CSS) might be a good model here.
>> SVG was also designed largely separately from HTML and CSS, and the FXTF
>> has helped line things up so that the same tech could be used by both.
>>
>> A key point there was splitting things up. Implementing all of SVG at
>> once is pretty daunting. The FXTF split out things like filters,
>> transforms, animation into their own modules. The effect is doubly
>> beneficial: it is easier to focus on implementing smaller features and the
>> user base for a feature that works in broader HTML+CSS contexts and use
>> cases is much larger than that for just SVG.
>>
>> --
>> Robin Berjon - http://berjon.com/ - @robinberjon
>>
>
>


## Re: Fwd: [Moderator Action] RE: Active lobbying: Math

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • August 25, 2015 • Permalink

Re Doug.

> I think we could really benefit from taking a look at _why_ browser
vendors aren't implementing MathML, learning those lessons, and making a
new version of MathML that's easier to implement and maintain, easier to
author, easier to style, and is better integrated into HTML5.

+1 (but it's a rather tall order ;-) )

> I've voiced this opinion to Peter before. I don't think we differ much,

+1.

Re Rich

> What I have heard from some browser vendors is that there is just not
enough MathML content out there and it is difficult to justify the
performance hit.

Performance is definitely a problem even for browser implementations. But
it's hard to say if that's just for lack for interest from browser vendors.
For example, earlier this year we had an edge case where MathJax
outperformed native Firefox support (by a margin); this was quickly
resolved once we got the attention of Rob O'Callahan at Mozilla.

Re Rob.

> The FXTF (a joint task force of SVG and CSS) might be a good model here.

+1. One difference is that browser vendors were actually interested in
implementing SVG features; I don't see that for math layout. Still,
reactions from Houdini leave me mildly hopeful.

> The FXTF split out things like filters, transforms, animation into their
own modules. The effect is doubly beneficial: it is easier to focus on
implementing smaller features and the user base for a feature that works in
broader HTML+CSS contexts and use cases is much larger than that for just
SVG.

I'm not too sure about that. It was actually a very small math layout
feature that triggered the removal of MathML from Chrome. (The Chrome team
convinced itself that stretchy characters are somehow fundamentally
incompatible with CSS layout.)

Peter.

On Tue, Aug 25, 2015 at 11:07 AM, Robin Berjon <robin@w3.org> wrote:

> On 24/08/2015 23:43 , Doug Schepers wrote:
>
>> I think we could really benefit from taking a look at _why_ browser
>> vendors aren't implementing MathML
>>
>
> I won't claim that it's the final word from browser vendors, but this was
> discussed extensively at Balisage last year. MathML suffers from the
> combination of being a pretty large chunk with a relatively small community.
>
> learning those lessons, and making a new version of MathML that's
>> easier to implement and maintain, easier to author, easier to style,
>> and is better integrated into HTML5.
>>
>
> The FXTF (a joint task force of SVG and CSS) might be a good model here.
> SVG was also designed largely separately from HTML and CSS, and the FXTF
> has helped line things up so that the same tech could be used by both.
>
> A key point there was splitting things up. Implementing all of SVG at once
> is pretty daunting. The FXTF split out things like filters, transforms,
> animation into their own modules. The effect is doubly beneficial: it is
> easier to focus on implementing smaller features and the user base for a
> feature that works in broader HTML+CSS contexts and use cases is much
> larger than that for just SVG.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>


## Re: Fwd: [Moderator Action] RE: Active lobbying: Math

Source: public-digipub-ig@w3.org Mail Archives • Robin Berjon (robin@w3.org) • August 25, 2015 • Permalink

On 24/08/2015 21:47 , Peter Krautzberger wrote:
> I think the main problem is that nobody really knows what it would
> technically require to implement good math layout in browser engines or
> what it would take to implement good MathML support.

Nobody might be stretching it, but it's certainly a very small group.

> * In my experience, both browser vendors, publisher, and third party
> vendors have surprisingly little knowledge of
>    * MathML as a markup language
>    * math layout in general
>    * MathML layout specifically
>    * math layout using OWP tech
>    * math accessibility using OWP tech

Part of the problem there is that you don't just easily fall into MathML
in an incremental manner, say by first trying to tweak the rendering of
something perhaps even as trivial as <var>x</var> and then building up
from there. The first step is relatively steep compared to many other
parts of the platform.

> * The ARIA spec has a massive hole where mathematics should be.

Asking naïvely: is there any reason not to start fixing this right now?

> * Neither browsers nor publishers are active in the MathWG (ok, maybe 1
> exception).
>
> * The MathML spec needs some work in an HTML5 context
>    * MathML has been "out of sync" (for lack of a better term) with
> HTML/CSS/SVG for a while
>    * MathML duplicates HTML/CSS features (sometimes the features are not
> compatible though never critically so imho)
>    * MathML hides quite a few complex layout features behind math
> syntax, complicating the implementation of both
>    * ContentMathML has failed outside of CAS.
>
> Another key problem is: MathML is neither necessary nor sufficient for
> math layout on the web. Nowadays, HTML/CSS implementations are good
> enough for (high quality) math/MathML layout. I'm not speaking of
> client-side JS-driven rendering but of (server-side) HTML+CSS generation
> that looks the same on all recent browsers.

That sounds like a great opportunity and a good starting point to
rethink MathML.

Starting from HTML+CSS code that's ugly and poorly accessible, but at
least sports high-quality layout:

• What can be added to CSS that would clean up both the style and
markup? What parts of that could actually be useful in other context?

• What can be done to make it properly accessible, ideally built-in
rather than bolt-on?

• What could be added to HTML to make the markup simpler and more
semantic, possibly by importing some elements from MathML more or less
directly, without requiring them to be in a MathML context but without
duplicating HTML functionality?

Extensible Web Manifesto spirit would surely help.

And I'm sure the WICG could be a great place to entertain
(non-monolithic) new ideas and hash them out with support from browser
vendors.

> Personally, I don't think MathML will be implemented in browsers (though
> I'd be extremely happy to be wrong here and will support any effort in
> this group). I do think there are more realistic alternative goals such
> as improving CSS implementations incrementally and developing standards
> for exposing underlying data such as MathML to tools such as AT.

+1

--
Robin Berjon - http://berjon.com/ - @robinberjon


## Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.