# 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: Arabic operators U+1EEF0 and U+1EEF1

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

Thanks. I'm not familiar with these Arabic notations so I can not really
help with the operator properties to apply.

Le 08/02/2016 18:33, David Carlisle a écrit :
>
> OK I've done
>
>
>
> David

--
Frédéric Wang



## mathvariant attribute and isolated Arabic mathematical characters

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

Dear all,

Unicode contains some "ARABIC MATHEMATICAL" characters in the range
1EE00-1EE1F corresponding to the "isolated" forms in plane 0. The MathML
specification does not explicitly mention these characters and there is
no "isolated" mathvariant value. So it seems that they should just be
ignored for the mathvariant implementation (and this is indeed what
Gecko does). However:

1) In https://www.w3.org/TR/arabic-math/#N10951 it seems that the
initial intention was to make mathvariant="normal" force the isolated
form for Arabic characters.

2) The file unicode.xml from http://www.w3.org/TR/xml-entity-names/
contains some mapping <surrogate mathvariant="isolated">

Could you please clarify if there is some relation between the
mathvariant attribute and these isolated Arabic mathematical characters?

Thanks,

--
Frédéric Wang



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

Source: public-webapps@w3.org Mail Archives • Hallvord Reiar Michaelsen Steen (hsteen@mozilla.com) • February 09, 2016 • Permalink

> 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

I'm trying to handle this question on another E-mail thread so please

>> JSON: nope, there's no such thing as "external inclusion" in JSON, and
>> there never will be.

> You can certainly exchange a Bookmark-list over json (e.g.
> http://kb.mozillazine.org/Bookmarks)... that would be a simple example of
> some JSON whose URLs you should not "GET" without some concerns (e.g.
> localhost servers).

But JSON as such has no concept of "URL" or a "URL" data type. To a
JSON implementation it's just a string, and I don't see any step of a
clipboard roundtrip doing anything magic to figure out what strings
are URLs or trying to process them :).

> Similarly XInclude-enabled XMLs or even other remote-including-XMLs (e.g.
> through DTD) should ask the users, deny, or inline.

Do you think we should not mandate support for writing XML to the
clipboard from JS, then?
Is this also a problem for MathML?

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

To make sure we understand each other: what you're saying here is that
if I do this in a JavaScript:

document.oncopy = function(e){
e.clipboardData.setData('text/html', '<img
src="https://mozilla.org/images/logo.gif">');
e.preventDefault();
}

the data that actually ends up being written to the clipboard will be

<img src="data:image/gif;base64,[Mozilla's logo data: encoded]">

I think that would be rather surprising behaviour, and would create
some attack scenarios if the attacker can predict the URLs of images
with private data inside them. On pasting they would then be data:
URLs without a concept of origin, the UA would no longer be able to
rely on mechanisms like CORS and/or session data to determine if it's
OK to show the image. If that image would be painted on a CANVAS after
pasting, the image data would now be accessible to JS without
tainting..

Is this really what you propose? :)

> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> data). There's no transcoding or similar.
>
> Please share the test, this is exactly the kind of things we need around to
> see how crooked one could touch upon.

I was playing around with the code the reporter of
https://bugzilla.mozilla.org/show_bug.cgi?id=860857 submitted - here's
an online version modified to also put image/tiff on the clipboard:
https://jsfiddle.net/gk3vm5L8/1/ (apparently this test was derived

>> So, the question (for recap) is: would it be OK to let JS write binary
>> data labelled as an image type if the browser was required to
>> transcode it to TIFF or DIB and only update the clipboard if such
>> transcoding succeeded?

> My answer is definitely yes as we should*assume that image transcoders
> should remove the dangers of flawed parsers as they could happen otherwise
> in other situations (e.g. in doing screenshots).

'image/jpeg') by mandating transcoding? :)
Is the current Safari Mac behaviour a problem or is it safe enough to spec?
-Hallvord


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

Source: public-webapps@w3.org Mail Archives • Paul Libbrecht (paul@hoplahup.net) • February 08, 2016 • Permalink

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

cool!
>> 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 think the proposed solution may be worse for privacy than the
> original problem: images you would "inline" might have sensitive data
> in them.. AFAIK it's not common to do any image inlining or URL
> mangling when pasting HTML copied from another site, is it?

It's the way it currently works on FF apparently (tested MacOSX 10.11
and Windows 7) and on Safari: all images are converted to data-urls.
I don't really see why it would be worse.
Would sensitive data be something such as the metadata? That could
certainly be stripped by transcoding.
>>> 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.
>
> XML: good point.
> JSON: nope, there's no such thing as "external inclusion" in JSON, and
> there never will be.
You can certainly exchange a Bookmark-list over json (e.g.
http://kb.mozillazine.org/Bookmarks)... that would be a simple example
of some JSON whose URLs you should not "GET" without some concerns (e.g.
localhost servers).
Similarly XInclude-enabled XMLs or even other remote-including-XMLs
(e.g. through DTD) should ask the users, deny, or inline.
>>> 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've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> data). There's no transcoding or similar.
Please share the test, this is exactly the kind of things we need around
to see how crooked one could touch upon.
E.g. MS Office documents nowadays display a "kind" of mistrust so the
user can bless if macros should be run. This kind of mistrust is
probably the future.
However, going as far as refusing any picture you
right-click-copy-picture from a web-browser because it is unsafe is far
from being what the users expect nowadays.
>> 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..
>
> I'd still like Daniel Cheng to chime in again if he has time :)
> So, the question (for recap) is: would it be OK to let JS write binary
> data labelled as an image type if the browser was required to
> transcode it to TIFF or DIB and only update the clipboard if such
> transcoding succeeded?
My answer is definitely yes as we should*assume that image transcoders
should remove the dangers of flawed parsers as they could happen
otherwise in other situations (e.g. in doing screenshots).
> (Obviously we also need the reverse mechanism - on paste, if there's
> TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
yes

Paul


## Re: Arabic operators U+1EEF0 and U+1EEF1

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • February 08, 2016 • Permalink

On 08/02/2016 15:37, Frédéric WANG wrote:
> Dear all,
>
> The MathML recommendation refers to
> http://www.unicode.org/charts/PDF/U1EE00.pdf which contains two Arabic
> operators (U+1EEF0 and U+1EEF1). Note that these operators are stretchy.
>
> They are not mentioned on
> https://www.w3.org/Math/draft-spec/appendixc.html. Actually, the
> unicode.xml file from https://www.w3.org/TR/xml-entity-names/ does not
> have any operator-dictionary or unicode-math entry either.
>
> https://github.com/wspr/unicode-math/pull/320
> https://github.com/khaledhosny/xits-math/issues/45
> https://bugzilla.mozilla.org/show_bug.cgi?id=1246657
> https://bugs.webkit.org/show_bug.cgi?id=153984
>

OK I've done

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: Arabic operators U+1EEF0 and U+1EEF1

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • February 08, 2016 • Permalink

On 08/02/2016 15:37, Frédéric WANG wrote:
> Dear all,
>
> The MathML recommendation refers to
> http://www.unicode.org/charts/PDF/U1EE00.pdf which contains two Arabic
> operators (U+1EEF0 and U+1EEF1). Note that these operators are stretchy.
>
> They are not mentioned on
> https://www.w3.org/Math/draft-spec/appendixc.html. Actually, the
> unicode.xml file from https://www.w3.org/TR/xml-entity-names/ does not
> have any operator-dictionary or unicode-math entry either.
>
> https://github.com/wspr/unicode-math/pull/320
> https://github.com/khaledhosny/xits-math/issues/45
> https://bugzilla.mozilla.org/show_bug.cgi?id=1246657
> https://bugs.webkit.org/show_bug.cgi?id=153984
>

Thanks for the reminder, I saw Khaled's pull request to unicode-math
last year and remember thinking at the time that unicode.xml would need
updating to match.

I can add the latex name information to match unicode-math and a
operator-dictionary stretchy=true
entry but if any of the other operator-dictionary fields should have
values I'd need some help with what the values should be!

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.

________________________________


## Arabic operators U+1EEF0 and U+1EEF1

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

Dear all,

The MathML recommendation refers to
http://www.unicode.org/charts/PDF/U1EE00.pdf which contains two Arabic
operators (U+1EEF0 and U+1EEF1). Note that these operators are stretchy.

They are not mentioned on
https://www.w3.org/Math/draft-spec/appendixc.html. Actually, the
unicode.xml file from https://www.w3.org/TR/xml-entity-names/ does not
have any operator-dictionary or unicode-math entry either.

https://github.com/wspr/unicode-math/pull/320
https://github.com/khaledhosny/xits-math/issues/45
https://bugzilla.mozilla.org/show_bug.cgi?id=1246657
https://bugs.webkit.org/show_bug.cgi?id=153984

--
Frédéric Wang



## SimpleTeX4ht

Source: Ask.com News Search for "mathml" • February 04, 2016 • Permalink

 ZDNet - Found Feb. 4, 2016 LaTeX files to HTML, XHTML, OpenDocument (.odt which is the native format of OpenOffice.org), MathML, DocBook or Text Encoding Initiative (TEI). Tech Tip: Moving Files to a Mac From a PC - New York Times FastFox Text Expander - ZDNet Moving Files to a Mac From a PC - New York Times Sequel Pro - ZDNet Explore All Huffington Post

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

Source: public-webapps@w3.org Mail Archives • Hallvord Reiar Michaelsen Steen (hsteen@mozilla.com) • February 04, 2016 • Permalink

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

On Sat, Aug 29, 2015 at 3:16 PM, Paul Libbrecht <paul@hoplahup.net> wrote:

> 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 think the proposed solution may be worse for privacy than the
original problem: images you would "inline" might have sensitive data
in them.. AFAIK it's not common to do any image inlining or URL
mangling when pasting HTML copied from another site, is it?

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

XML: good point.
JSON: nope, there's no such thing as "external inclusion" in JSON, and
there never will be.

>> 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've just done a small test in Safari on Mac. It allows writing a
random string to the clipboard and labelling it image/tiff (and
data). There's no transcoding or similar.

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

I'd still like Daniel Cheng to chime in again if he has time :)
So, the question (for recap) is: would it be OK to let JS write binary
data labelled as an image type if the browser was required to
transcode it to TIFF or DIB and only update the clipboard if such
transcoding succeeded?

(Obviously we also need the reverse mechanism - on paste, if there's
TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
-Hallvord


## HighWire continues as MathJax Supporter

Source: MathJax • February 03, 2016 • Permalink

The HighWire Open Platform provides innovative technology solutions to influential societies, university presses, and independent publishing organizations, assisting in the digital dissemination and readability of some of the most high-impact journals, books, and other scholarly materials on the net.

“Celebrating 20 years of service, HighWire Press, Inc. is excited to once again be a supporter of the initiatives behind the development of MathJax’s open source platform for display of mathematics,” said Christopher Abbott, Director, Content Service, HighWire Press. “The HighWire Open Platform is designed to work well with standards such as MathML. We’re proud to be part of the solution.”

“HighWire has been providing both support and important feedback for our development at MathJax”, comments Peter Krautzberger, MathJax manager. “Dedicated sponsors such as HighWire enable us at MathJax to deliver the most reliable, high-quality solution for math and science on the web.”

We look forward to continuing the collaboration with HighWire and welcome their ongoing support for the MathJax project.

## MS SharePoint Server 2016 Support & Enhanced Footnote Handling & ...

Source: Ask.com News Search for "mathml" • February 02, 2016 • Permalink

 Programmers' Heaven - Found Feb. 2, 2016 • MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved...

## OASIS DITA 1.3 Standard Approved for Authoring and Publishing

Source: Ask.com News Search for "mathml" • February 01, 2016 • Permalink

 Channel 8 Eyewitness News - Found Feb. 1, 2016 ... new features, introduced in DITA 1.3, such as troubleshooting topic type, keyscopes, branch filtering, MathML domain, XML mention domain and... OASIS DITA 1.3 Standard Approved for Authoring and Publishing - WVNS OASIS DITA 1.3 Standard Approved for Authoring and Publishing - KHQ Right Now OASIS DITA 1.3 Standard Approved for Authoring and Publishing - IT Business Net OASIS DITA 1.3 Standard Approved for Authoring and Publishing - Minyanville Explore All

## MS SharePoint Server 2016 Support & Enhanced Footnote Handling & ...

Source: Ask.com News Search for "mathml" • January 30, 2016 • Permalink

 PR.com - Found Jan. 30, 2016 • MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved...

## Re: Apple's feedback for custom elements

Source: public-webapps@w3.org Mail Archives • Olli Pettay (olli@pettay.fi) • January 24, 2016 • Permalink

Random comments inline (other people from Mozilla may have different opinions)

On 01/24/2016 10:01 AM, Ryosuke Niwa wrote:
>
>
> Hi all,
>
> Here's WebKit team's feedback for custom elements.
>
>
> == Constructor vs createdCallback ==
> We would like to use constructor instead of created callback.

>
> == Symbol-named properties for lifecycle hooks ==
> After thorough consideration, we no longer think using symbols for callback names is a good idea.  The problem of name conflicts with an existing
> library seems theoretical at best, and library and framework authors shouldn't be using names such as "attributeChanged" for other purposes than as
> for the designated purpose of custom elements API.
>
> In addition, forcing authors write [Element.attributeChanged]() instead of attributeChanged() in this one API is inconsistent with the rest of Web
> API.
>
Personally I agree.

>
> == Calling attributeChanged for all attributes on creation ==
> We think invoking attributeChanged for each attribute during creation will help mitigating the difference between the upgrade case and a direct
> creation inside author script.
>
> https://github.com/w3c/webcomponents/issues/364
>
Fine to me. This is also close to what XTF had. (It had also a pre-callback, willSet/RemoveAttribute [1], but we can live without those at least in v1)

>
> == Lifecycle callback timing ==
> We're fine with end-of-nano-task timing due to the implementation difficulty of going fully sync and async model doesn’t meet author’s expectation.
>

>
> == Consistency problem ==
> This is a problem but we think calling constructor before attributes and children are added during parsing is a good enough mitigation strategy.
It is possible that we'll need beginAddingChildren()/doneAddingChildren() for the parsing case later, but not for v1.
I wonder if all the engines can easily have end-of-nanotask right after main-thread part of parser has created the DOM element and before any
attributes/children are set.
IIRC Gecko should be fine these days.

> == Attached/detached vs. inserted/removed hooks ==
> Elements that define things or get used by other elements should probably do their work when they’re inserted into a document.  e.g. HTMLBaseElement
> needs to modify the base URL of a document when it gets inserted. To support this use case, we need callbacks when an element is inserted into a
>
> Once we have added such insertedIntoDocument/removedFromDocument callbacks, attached/detached seems rather arbitrary and unnecessary as the author can
> easily check the existence of the browsing context via document.defaultView.
>
> We would not like to add generic callbacks (inserted/removed) for every insertion and removal due to performance reasons.
>
> https://github.com/w3c/webcomponents/issues/362
I'd prefer getting more consistent parentChainChanged(oldSubtreeRoot, newSubtreeRoot) callback or some such. That wouldn't depend on is-in-document
state. Adding parentChainChanged later if there is already insertedIntoDocument/removedFromDocument would just duplicate some of the behavior.

Something to consider, borrowed from XTF, should custom element implementation tell to browser engine which notifications it is interested in?
That way performance considerations are partially moved from browser engine to the custom element author.

> == Style attribute spamming ==
> Since keeping the old value is inherently expensive, we think we should mitigate this issue by adding an attribute filtering.  We think having this
> callback is important because responding to attribute change was the primary motivation for keeping the end-of-a-nano-task timing for lifecycle callbacks.
>
> https://github.com/w3c/webcomponents/issues/350
attribute filter sounds good. Especially if it is consistent with MutationObserver.

> == childrenChanged callback ==
> Given the consistency problem, it might be good idea to add childrenChanged callback to encourage authors to respond to this event instead of
> relying on children being present if we decided to go with non-synchronous construction/upgrading model.
>
> On the other hand, many built-in elements that rely on children such as textarea tends to respond to all children at once.  So attaching mutation
> observer and doing the work lazily might be an acceptable workflow.
So would childrenChanged be called after parser has added all the child nodes? Or just at random time, or for each child nodes separately?

This is a case where beginAddingChildren()/doneAddingChildren() would be needed, but for now, childrenChanged is probably ok.

>
>
> We should do top-down in both parsing and upgrading since parser needs to do it top-down.

>
>
>
> == What happens when a custom element is adopted to another document? ==
> Since a given custom element may not exist in a new document, retaining the prototype, etc... from the original document makes sense.  In addition,
> WebKit and Blink already exhibit this behavior so we don’t think it poses a major combat issue.
(can't recall all the details. Would need to re-read the relevant spec bugs.)

>
>
> == Inheritance from subclasses of HTMLElement such as HTMLInputElement ==
> We strongly oppose to adding this feature at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
Sounds good

>
>
> == Inheritance from SVGElement/MathMLElement ==
> We don't want to allow custom SVG and MathML elements at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
ditto

>
>
> - R. Niwa
>

-Olli

[1] http://mxr.mozilla.org/seamonkey/source/content/xtf/public/nsIXTFElement.idl#127


## The CSS WG published Candidate Recommendations of CSS Fragme…

Source: Ask.com News Search for "mathml" • January 18, 2016 • Permalink

 W3C - Found Jan. 18, 2016 Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java.

## EditiX

Source: Ask.com News Search for "mathml" • January 15, 2016 • Permalink

 ZDNet - Found Jan. 15, 2016 EditiX includes default templates with XML, DTD, XHTML, XSLT, XSD, XML RelaxNG, SVG, MathML and XML FO. Jaksta Media Recorder - ZDNet MixPad Multitrack Recorder - ZDNet Balsamiq Mockups - ZDNet Mail Archiver X - ZDNet Explore All

## The CSS WG published a Candidate Recommendation of CSS Fragm…

Source: Ask.com News Search for "mathml" • January 14, 2016 • Permalink

 W3C - Found Jan. 14, 2016 Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java.

## Re: CSS Priorities / character alignment (Was: Meeting Minutes, 2016-01-11)

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • January 13, 2016 • Permalink

I'm not sure if it's interesting or already known but
https://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.3.5.5.10
describes the algorithm specified by the MathML spec for its in-table
alignment markup. Though, as far as I know, no web-based MathML renderer
implements malign groups.

https://drafts.csswg.org/css-text-4/#character-alignment; the example's
pseudo-rendering does not correspond to the table markup; it confused
people I had sent it to.

Peter.

On Wed, Jan 13, 2016 at 8:13 AM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On Jan 13, 2016, at 15:01, Ivan Herman <ivan@w3.org> wrote:
> >
> > Minutes are available here:
> >
> > http://www.w3.org/2016/01/11-dpub-minutes.html
>
> Hi all,
>
> Sorry for missing the meeting, it was a holiday in Japan (but I should
> have sent regrets nonetheless).
>
> I just wanted to briefly react to the discussion about the CSS Priorities
> Document,
> and confirm that there is a meeting of the CSSWG from February 1 to 3,
> that I am going to it, and that I am happy to push for discussions on
> DPUB-IG topics such as character alignment in tables, but also that
> it will be difficult for me to do so if I don't have a corpus of examples,
> especially examples that could inform the discussion about the issues
> raised by Dbaron in the spec (
> https://drafts.csswg.org/css-text-4/#character-alignment).
>
>
>  - Florian
>


## The CSS Working Group, in cooperation with John Allsopp (Web…

Source: Ask.com News Search for "mathml" • January 12, 2016 • Permalink

 W3C - Found Jan. 12, 2016 Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java.

## MathJax v2.6 now available

Source: MathJax • December 30, 2015 • Permalink

After a smooth beta run, we’re happy to officially release MathJax v2.6. This release focused on two main features:

1. Completing the CommonHTML output, a faster HTML output that can be generated on both client and server.

2. Accessibility improvements in the form of

• an extension to expose MathJax’s internal MathML to screenreaders
• making the MathJax Menu accessible.

The v2.6 release also includes over 30 bug fixes to increase the quality and stability of MathJax (see below for details).

MathJax v2.6 is available on the CDN, and for download from GitHub; see the documentation for details.

Version 2.6 is available on the CDN at

http://cdn.mathjax.org/mathjax/2.6-latest/MathJax.js

and starting today the files at the

http://cdn.mathjax.org/mathjax/latest/MathJax.js

address will be switched over the v2.6. If you are using the mathjax/latest address you might get a mixture of files in your browser cache, and so may need to clear your browser cache and for some browsers (e.g., Chrome) restart your browser in order to get a consistent version of all files.

If you are a page author and concerned about this, you can change (temporarily) to the mathjax/2.6-latest URL instead of mathjax/latest since that is a new address that will not have any cached older versions to worry about. You can switch back to mathjax/latest in a few days when the new version has migrated to all the locations in the cloud. If you want to keep using Mathjax v2.5 you can switch to mathjax/2.5-latest.

See http://docs.mathjax.org/en/v2.6-latest/whats-new-2.6.html for details about the changes in v2.6. We anticipate a smooth upgrade from v2.5 to v2.6, but as always, let us know on the bug tracker if you experience problems with this new version of MathJax.

### Changes to the default MathJax “TeX” fonts

We have updated our default MathJax “TeX” fonts to improve the CommonHTML output and simplify its layout process. If you have previously installed a copy of the MathJax TeX fonts to your local system, please update that copy to ensure correct rendering in the CommonHTML output.

You can check this using the embedded page below (external link) which will detect whether you need to update installed MathJax “TeX” fonts installed.

See the Pen MathJax Font Check by MathJax (@mathjax) on CodePen.

Note: Other applications may have installed the MathJax “TeX” fonts for you.

Note: The changes to the MathJax “TeX” fonts are backward compatible to previous versions of MathJax so you can install them without worrying about sites using older MathJax versions. Of course you do not need to install the fonts as MathJax can automatically load webfonts instead.

### Changes to the combined configuration files

If you are using a combined configuration, please note the following:

1. We have added several new combined configuration files. In particular, you can use the new CommonHTML output by choosing a combined configuration ending on _CHTML.

2. The new AssitiveMML.js extension is included in these configurations. If you want to de-activate it, add, e.g., the following to your page before MathJax.js is loaded.

Thank you for your continued support.

The MathJax Team.

## New in MathJax v2.6

MathJax v2.6 includes a number of new features, as well a more than 30 important bug fixes. The following are some of the highlights.

### Features

• Improved CommonHTML output. The CommonHTML output now provides the same layout quality and MathML support as the HTML-CSS and SVG output. It is on average 40% faster than the other outputs and the markup it produces are identical on all browsers and thus can also be pre-generated on the server via MathJax-node. The fast preview mechanism introduced in v2.5 continues to develop as a separate output as PreviewHTML <configure-PreviewHTML> and the fast-preview <configure-fast-preview> extension.
• Accessibility improvements. We thank the AT community for their guidance, support, and feedback in our efforts towards making MathJax completely accessible to all users.

• Screenreader compatibility. The new AssistiveMML extension enables compatibility with most MathML-capable screenreaders by inserting visually-hidden MathML alongside MathJax’s visual output. See screenreader support <screenreader-support> for details on the expected behavior as well as background on the limitations due to lack of web standards and browser/OS technology.

* Accesssible UI. We have improved the accessibility of the MathJax menu to enable assistive technology users to easily access its features, cf. MathJax UI <mathjax-ui-a11y>.

• PlainSource Output. The new PlainSource output will revert the rendering back to the input format; in the case of MathML, the output will prefer TeX and AsciiMath from <annotation-xml> elements. This helps with accessibility and copy&paste of document fragments.
• Semi-slim MathJax repository for bower. You can now use bower install components/MathJax to install a fork of MathJax without PNG fonts. Many thanks to @minrk from the IPython/Jupyter team and to the team at components!
• MathJax via npm. You can now use npm install mathjax to install a copy of MathJax without PNG fonts.
• Deprecated: MMLorHTML extension. We have deprecated the MMLorHTML extension. For a detailed guide on configuring MathJax to choose different outputs on different browsers, please see Automatic Selection of the Output Processor <automatic-output-switch> for more information.

Numerous bugs and issues have also been resolved; for a detailed listing please check the release milestone.

#### Interface

• #939 Make MathJax contextual menu properly accessible.
• #1210 Update MathZoom.js: global border-box support. Special thanks to @CalebKester
• #1273 Improve handling of hash in URL.

#### HTML/SVG/nativeMML display

• #1095 HTML-CSS output: prevent collapse of table borders.
• #596 SVG Output: Fix overlapping equation labels in SVG output
• #994 SVG Output: Change default blacker setting to 1.
• #995 SVG output: fix baseline alignment issues.
• #995 SVG output: fix failure to scale all but the first glyph in a fraction when useFontCache=false.
• #1035 PreviewHTML output: fix fractions formatting in WebKit and IE.
• #1233 SVG output: make maligngroup and malignmark produce no output.
• #1282 HTML-CSS output: reduce “bumpiness” of focus outline.
• #1314 HTML-CSS output: prevent clipping of extremely long strings.
• #1316 SVG output: preserve non-breaking space in mtext elements.
• #1332 HTML-CSS output: fix width calculations for mrows with embellished operators that could stretch but don’t actually.

#### TeX emulation

• #567 Add macro for overparen and underparen to provide stretchy arcs above/below
• #956 Simplify the mhchem extension to use multiscripts, cf. #1072.
• #1028 Fix spacing in \alignedat.
• #1194 Fix problem where automatic numbering affects \binom and friends.
• #1199 Fix problem with dot delimiter not being recognized as a delimiter.
• #1224 Handle braces properly in text mode when looking for matching math delimiters.
• #1225 Fix \operatorname not ignoring \limits that follow immediately after.
• #1229 Fix wrong spacing of trailing binary operators.
• #1272 Fix spacing of \eqnarray environment.
• #1295 Handle scriptlevel set on arrays via an mstyle node (affects \smallmatrix).
• #1312 Improve heuristics for adding U+2061 (invisible function application).

#### Asciimath

• asciimath/#31 Add support for overparen, underparen to produce mover and munder constructs.
• asciimath/#35 Add support for bowtie, ltimes and rtimes.
• asciimath/#40 Improve parsing of brackets within brackets.
• asciimath/#43 Improve detection of non-matrices.

#### MathML

• #1072 Right-justify prescripts in mmultiscript elements (after clarification in MathML 3 editors’ draft); cf. #956.
• #1089 Fix toMathML from changing <maligngroup> to <malign>
• #1188 Fix mmultiscripts with odd number of post-scripts not rendering correctly.
• #1231 Fix [itex] element not being treated as an <mrow> for embellished operator spacing.
• #1233 Make <maligngroup> and <malignmark> be self-closing in MathML input.
• #1238 Fix Content MathML extension not handling namespace prefixes.
• #1257 Improve mml3.js: better RTL support in HTML-CSS; improved IE/Edge compatibility.
• #1323 Content-mathml extension: improve handling of empty Presentation MathML nodes.

#### Fonts

• #928 Add data for stretchy U+2322 (FROWN), U+2323 (SMILE), and also U+2312 (ARC) to be aliases for the top and bottom parentheses. This enables stretchy constructions; cf. also #567.
• #1211 Fix web font detection for Gyre-Pagella etc. in IE10+.
• #1251 Fix primes in STIX-web font being too small in SVG output.

#### Localization

• #1248 Updated locales thanks to the contributors at Translatewiki.net; activate locales for Bulgarian, Sicilian, Lithuanian, and Laki.

#### APIs

• #1216 Add debugging tips to console output.

#### Misc.

• #1074 Fix regression in v2.5 regarding MathPlayer on IE9.
• #1036 Improve CDN rollover behavior.
• #1085 Fix detection of Windows Phone mobile IE.
• #1155 Work around websites using user agent filtering
• #1173 Avoid warning message in debug mode.
• #1208 Fix CHTML preview from setting chunking parameters even when disabled.
• #1214 semi-slim official MathJax repository for bower; use bower install components/MathJax for a copy without PNG fonts. Special thanks to @minrk from the IPython/Jupyter team and to the team at components!
• #1254 Improve examples in /test: add viewport meta tags, improve dynamic examples.
• #1328 Add package.json for publishing on npm, excluding PNG fonts.

## 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.