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

## MathJax v2.7 now available

Source: MathJax • October 14, 2016 • Permalink

After a very smooth beta run, we’re happy to officially release MathJax v2.7.

## New in MathJax v2.7

MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes. In addition, this release adds several new features as an opt-in. The following are some of the highlights:

1. CommonHTML output improvements Several important bugs in the layout model have been fixed, in particular tabular layout is now much more robust.
2. Accessibility extensions. After the completion of the MathJax Accessibility Extensions, we are integrating the lightweight opt-in into the MathJax core. This allows readers to opt into the following features via the MathJax Menu:
• Responsive Equations. An innovative responsive rendering of mathematical content through collapsing and exploration of subexpressions.
• Universal aural Rendering. An aural rendering tool providing on-the-fly speech-text for mathematical content and its subexpressions using various rule sets.
• Full Exploration. A fully accessible exploration tool, allowing for meaningful exploration of mathematical content including multiple highlighting features and synchronized aural rendering.
• For detailed information check the accessibility extensions’ release announcement.
3. Opt-in for mhchem v3 The mhchem extension in the core now provides a configuration option to switch to mchhem v3. This new version was (re-)written by Martin Hensel, author of the original $\rm \LaTeX$ package, and greatly revises and extends it. This new extension is also available directly through the MathJax Third Party Extension repository
4. Simplified opt-in for third party extensions MathJax v2.7 configures the [Contrib] path variable to the URL of the third party extension repository on the MathJax CDN. This simplifies loading contributed extensions.
5. Third Party Extension Updates Our Third Party Extension repository as seen some great additions recently. The MathJax team is grateful for these contributions from the community!

For details on all bug fixes, please see below.

### Changes to the combined configuration files

If you are using a combined configuration, please note that we added the the accessibility menu extension to all combined configuration files. This extension will always load from cdn.mathjax.org/mathjax/contrib. If you are hosting your own copy of MathJax and if your users will not be able to access cdn.mathjax.org, then you should disable the [Contrib] path by adding noContrib to the query string, e.g., MathJax.js?config=...&noContrib to avoid unnecessary failed requests.

## Release on the MathJax CDN

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

Version 2.7 is available on the CDN at

http://cdn.mathjax.org/mathjax/2.7-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.7. 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.7-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.6 you can switch to mathjax/2.6-latest.

Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.

The MathJax Team.

## New in MathJax v2.7

MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes, in particular to the CommonHTML output. In addition, this release adds several new features as an opt-in. The following are some of the highlights.

## Features

• Common HTML output improvements Several important bugs in the layout model have been fixed, in particular tabular layout is now much more robust.
• Accessibility improvements. After the completion of the MathJax Accessibility Extensions, we are integrating the opt-in for the MathJax menu into the core distribution. We are grateful to the web accessibility community for their guidance, support, and feedback in our efforts towards making MathJax completely accessible to all users. This allows end-users to opt into the following features via the MathJax Menu:
• Responsive Equations. An innovative responsive rendering of mathematical content through collapsing and exploration of subexpressions.
• Universal aural Rendering. An aural rendering tool providing on-the-fly speech-text for mathematical content and its subexpressions using various rule sets.
• Full Exploration. A fully accessible exploration tool, allowing for meaningful exploration of mathematical content including multiple highlighting features and synchronized aural rendering.
• For more information check the release announcement and the dedicated repository at mathjax/mathjax-a11y.

For a detailed listing please check the release milestone.

## Accessibility

• mathajx-dev/#20 Add the Menu extension from the MathJax Accessibility tools to all combined configuration files.
• #1465 CHTML and HTML-CSS output: do not add role=math by default.
• #1483 Catch IE8 errors with inserting MathML from AssistiveMML extension.
• #1513 Disable the AssistiveMML extension when the output renderer is PlainSource.

## Interface

• #1463 Reset message strings for messageStyle=simple for each typeset.

## HTML/SVG/nativeMML display

• #1454 SVG output: Use full location URL for xlink references in SVG <use> elements.
• #1457 Common-HTML output: Fix problem with characters from Unicode Plane 1 not being mapped to the MathJax fonts properly
• #1458 SVG output: Fix problem with container width when math is scaled.
• #1459 CommonHTML output: Improve getNode() to fix processing errors when line-breaking.
• #1460 HTML-CSS output: Adjust position of rule for square root when it is made via createRule().
• #1461 HTML-CSS output: Make sure 0 remains 0 when rounding to pixels (plus a bit).
• #1462 CommonHTML output: Bubble percentage widths up while line breaking.
• #1475 PreviewHTML: Avoid error when \overset or \underset is empty.
• #1479 All outputs: Properly determine (shrink-wrapping) container widths.
• #1503 CommonHTML output: Handle adjusting table cell heights properly.
• #1507 SVG output: Remove invalid src attribute from <mglyph> output.
• #1510 CommonHTML output: Prevent CSS bleed-through for box-sizing.
• #1512 CommonHTML output: make <mglyph> scale image size by hand.
• #1530 All outputs: Fix problem with Safari inserting line breaks before in-line math.
• #1533 CommonHTML output: improve aligning labels with their table rows.
• #1534 CommonHTML output: ensure output stays a table-cell when focused.
• #1538 All outputs: Don’t let preview width interfere with the determination of the container width.
• #1542 CommonHTML output: improve stretching <mover> in <mtd> elements.
• #1547 HTML-CSS output: improve line breaks within fractions.
• #1549 All outputs: Improve determination of line-breaking parent element.
• #1550 CommonHTML output: Improve vector arrow positioning.
• #1552 All outputs: Handle href correctly when line breaking.
• #1574 HTML-CSS and SVG output: Use currentColor for <menclose> with no mathcolor.
• #1595 CommonHTML output: Properly scale elements with font-family specified.

## TeX emulation

• #1455 Fix TeX.Environment() to use the correct end environment.
• #1464 Make sure resetEquationNumbers is always defined.
• #1484 Mark accented operators as not having movable limits.
• #1485 Allow line breaks within TeXAtom elements
• #1508 Surround \middle with OPEN and CLOSE TeXAtoms to match TeX spacing
• #1509 Make delimiters (in particular arrows) symmetric for \left and \right.
• #1514 Don’t unwrap rows when creating fenced elements.
• #1523 Don’t copy environment into array environments.
• #1537 mhchem: add config parameter to select mhchem v3.0.
• #1596 Prevent \require{mhchem} to override one already loaded.
• #1551 Allow <wbr> in TeX code.
• #1565 Handle \+SPACE in macro definitions.
• #1569 Treat control sequences as a unit when matching a macro template.
• #1587 Make sure trimSpaces() doesn’t remove tailing space in \+SPACE.
• #1602 Handle \ref properly when there is a <base> tag.

## MathML

• #1505 Handle rowlines="" and rowlines=" " like rowlines="none".
• #1511 Don’t convert attribute to boolean unless the default is a boolean.
• #1526 Make minus in <mn> produce U+2212 rather than U+002D.
• #1567 Fix spacing for initial fraction in exponent position.

## Fonts

• #1521 STIX fonts: Make left arrow use combining left arrow for accents.
• #1092 STIX fonts: Make U+222B (integral) stretchy.
• #1154 STIX fonts: Remap | to variant form (with descender) and map variant to original form.
• #1175 Use U+007C and U+2016 for delimiters rather than U+2223 and U+2225.
• #1421 MathJax TeX fonts: Fix SVG font data for stretchy characters.
• #1418 Alias U+2206 to U+0394 and remove incorrect U+2206 from SVG font files.
• #1187 Make height and depth of minus match that of plus (needed for TeX-layout super/subscript algorithm to work properly), and adjust for that when it is used as an extender in stretchy characters.
• #1546 MathJax TeX fonts: Add stretchy data for U+20D7.

## Localization

• #1604 Updated locales thanks to the contributors at Translatewiki.net; activate locale for Zazaki.

## APIs

• #1504 Make getJaxForMath() work even during chunking.
• #1522 Add Third Party Extensions Repository to the Ajax paths as [Contrib].
• #1525 Allow MathJax root to be configured.

## Misc.

• #1456 Prevent removal of DOM elements while MathJax is running from stopping processing, or to leaving duplicate math in place.
• #1524 Prevent pre-processors from adding duplicate preview elements.
• #1554 Safe extension: Add filtering of CSS styles like padding, margin.
• #1590 Set previews to have display:none.
• #1591 Change rev= to V= in cache breaking code.

## Release Notes for Safari Technology Preview 11

Source: WebKit • Jon Davis • October 11, 2016 • Permalink

Safari Technology Preview Release 11 is now available for download for both macOS Sierra betas and OS X El Capitan. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 203771–204289.

### JavaScript

• Updated behavior for a class that extends null to follow ECMAScript 2016 specifications (r204058)
• Made the second argument for Function.prototype.apply allow null, undefined or array-like data (r203790)

### Web APIs

• Add support for DOMTokenList.replace() (r204161)
• Add support for Element.getAttributeNames() (r203852)
• Made the first parameter mandatory for canvas.getContext() and probablySupportsContext() (r203845)
• Made the first two parameters madatory for window.postMessage() (r203846)
• Made the first parameter mandatory for Document.execCommand() and queryCommand*() (r203784)
• Made the first parameter mandatory for HTMLMediaElement.canPlayType() (r203806)
• Made the first parameter mandatory for indexed property getters (r203788)
• Made the first parameter mandatory for Range.createContextualFragment() (r203796)
• Made the first parameter mandatory for setTimeout() and setInterval() (r203805)
• Made the first parameter mandatory for SVGDocument.createEvent() (r203821)
• Made the parameter mandatory for a named property getter (r203797)
• Made the parameter mandatory for table.deleteRow() and body.deleteRow() (r203840)
• Made the parameter mandatory for tr.deleteCell() (r203833)
• Made the parameters mandatory for CanvasGradient.addColorStop() (r203820)
• Made the parameters mandatory for DOMParser.parseFromString() (r203800)
• Made the parameters mandatory for Event.initEvent() (r203848)
• Made the parameters mandatory for insertAdjacentText() and insertAdjacentHTML() (r203803)
• Enabled strict type checking for nullable attribute setters for wrapper types (r203949)
• Enabled strict type checking for operations’ nullable parameters for wrapper types (r203941)

### ApplePay

• Stopped accepting the deprecated requiredShippingAddressFields and requiredBillingAddressFields properties (r203789)

### Web Inspector

• Improved the appearance of the Timeline tab when editing the enabled timelines (r204125)
• Changed the Jump to Line keyboard shortcut to Control-G (⌃G) (r204099)
• Fixed the grid column resizing element positions (r203991)
• Added waterfall view to the Network tab and Network Timeline (r203843)
• Fixed positioning of popovers when the window resizes (r204264)
• Fixed popover drawing (r204136)
• Polished UI for the Edit Breakpoint, Open Quickly, and Goto Line dialogs (r204152, r204124)
• Update the Visual Styles Sidebar to use a one column layout when narrow (r203807)
• Fixed the behavior of Home and End keys to match system behavior (r203804)

### CSS

• Aligned the CSS supports rule with the specification (r203782)
• Addressed incorrect results for the color-gamut media query (r203903)

### Rendering

• Fixed performance issues with <marquee> with the truespeed attribute (r204197)

### Media

• Fixed captions not rendering in the PiP window for a hidden video element (r203799)
• Addressed media controls not displaying for some autoplaying videos at certain browser dimensions (r203928)
• Fixed media stream video element to show black when all video tracks disabled (r203826)

### Accessibility

• Added localizable strings when inserting list types (r203801)
• Improved the accessibility of media controls (r203913)

### Content Blockers

• Enabled Content Blockers to block WebSocket connections (r204127)

## Release Notes for Safari Technology Preview 12

Source: WebKit • Jon Davis • October 11, 2016 • Permalink

Safari Technology Preview Release 12 is now available for download for both macOS Sierra betas and OS X El Capitan. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204289–204876.

This release of Safari Technology Preview will be the last that will install and run on OS X El Capitan 10.11.4 and 10.11.5. To continue testing or living on the latest enhancements to WebKit, please upgrade to OS X El Capitan 10.11.6 or the macOS Sierra betas.

### JavaScript

• Added checks for TypedArray.prototype.slice to ensure the source and destination have not been detached (r204868)
• Added exception handling for const variables used in a for-in or for-of loop (r204586)
• Improved the performance of Array.prototype.map when used with Arrays (r204488)
• Implemented Object.entries and Object.values from the ES2017 specifications (r204419, r204358)
• Changed the line, column and sourceURL properties of Error to be configurable and writable (r204663)

### Web APIs

• Fetch API is enabled by default (r204705)
• Updated Resource Timing implementation (r204736, r204641, r204429)
• Aligned Range.surroundContents() with the latest DOM specification (r204390)
• Added support for HTMLAreaElement.toString() (r204871)
• Changed the prefix properties of Attr and Element to be read-only (r204648)
• Changed <command> to an HTMLUnknownElement and <basefont> to an HTMLElement (r204647)
• Moved the prefix, namespaceURI, and localName attributes from Node to Attr and Element (r204624)
• Aligned text encoding labels with the Encoding specification (r204605)
• Added Animatable, AnimationEffect, KeyframeEffect and Animation interfaces for Web Animations (r204594)
• Aligned isDefaultNamespace(), lookupPrefix(), and lookupNamespaceURI() with the specification (r204536)
• Changed querySelector() and querySelectorAll() to always throw a SyntaxError when failing to parse a selector string (r204522)
• Moved embeds, plugins, and scripts attributes from HTMLDocument to Document (r204450)
• Moved the compatMode and designMode properties from HTMLDocument to Document (r204451, r204449)
• Updated getElementsByTagName() to take a qualified name parameter (r204441)
• Exposed crypto.getRandomValues to Web Workers (r204481)
• Added application/vnd.api+json as a valid JSON MIME-type (r204437)

### Web Inspector

• Added a visual editor for the spring() timing-function (r204775)
• Fixed an issue where “NaN x NaN” was shown for invisible elements in the Styles → Computed → Box Model section (r204759)
• Set Open Resource Dialog to jump to the last line when the specified line number (“:n”) is more than the total line count of the resource (r204755)
• Added an icon for selectors that only affect pseudo-elements (r204754)
• Fixed DOM nodes shifting when hovering over them in the Console (r204520)
• Fixed the alignment of the Close button of the selected item in the Network tab (r204491)
• Changed the Visual Styles Sidebar behavior for SVGs to show SVG specific sections (r204758)
• Changed the Visual Styles Sidebar TextContent section to only be visible for a pseudo-element (r204757)
• Escaped Text → Content in the Visual Styles Sidebar (r204510)
• Addressed status icons flickering from rapid updates in the Visual Styles Sidebar (r204562)
• Fixed the placement of Error and Warning icons in the Visual Styles Sidebar (r204490)
• Fixed a hang when using Command-Shift-O (⌘⇧O) when the loaded web page has frames (r204428)
• Enabled editing node attributes, content, and styles for shadow DOM nodes (r204370)
• Improved the display of large numbers in the console log counter on the dashboard (r204642)
• Improved the display of large class lists and made the quick-toggle easier to discover (r204496)

### MathML

• Improved the extraction of operator and token elements’ characters (r204830)
• Introduced a MathMLRowElement class for mrow-like elements (r204779)
• Introduced a MathMLAnnotationElement class for the <annotation> and <annotation-xml> elements (r204692)

### CSS

• Enabled the :host pseudo-class to style elements in the shadow tree (r204724)
• Corrected the namespace prefix handling in front of element name CSS selectors (r204591)

### Rendering

• Fixed SVG clip-path to work on a root SVG element (r204872)
• Fixed ctx.drawImage to clip the source rectangle if it is outside the source image (r204517)

### Accessibility

• Labelled audio description tracks correctly to prevent user confusion (r204601)
• Added a percentage value description for the media control’s timeline slider (r204361)

### Security

• Improved URLParser parsing IPv4 addresses and URLs without credentials (r204701, r204544)
• Added support to handle cross-origin redirect requests while in CORS mode (r204693, r204795)
• Corrected the Upgrade-Insecure-Request state handling between navigations (r204521)
• Added a sandbox for the Adobe Flash Player ESR plug-in used in enterprise environments (r204461)
• Changed instantiation of WebKit plug-ins to happen at layout time, instead of at style resolution time (r204320)

## Release Notes for Safari Technology Preview 13

Source: WebKit • Jon Davis • October 11, 2016 • Permalink

Safari Technology Preview Release 13 is now available for download for both macOS Sierra betas and OS X El Capitan 10.11.6. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204876–205519.

### Fetch API

• Added support for BufferSource bodies (r205115)
• Fixed blob resource handling to raise a network error when the URL is not found (r205190)
• Set the blob type correctly for an empty body (r205250)
• Set the blob type from Response/Request contentType header (r205076)
• Made the body mix-in text() decode data as UTF–8 (r205188)
• Enabled the Fetch API to load the data URL in same-origin mode (r205265)
• Prevented any body for opaque responses (r205082)
• Changed opaqueredirect responses to have their URL set to the original URL (r205081)
• Prevented setting bodyUsed when request construction fails (r205253)
• Set Response bodyUsed to check for its body-disturbed state (r205251)
• Changed response cloning to use structureClone when teeing a Response stream (r205117)
• Aligned the internal structure of ReadableStream with the specifications (r205289)
• Aligned data:// URL behavior of XHR to match specifications (r205113)

### Custom Elements

• Added adopted callback for custom elements on appendChild() (r205085)
• Enabled reaction callbacks for adopted custom elements (r205060)
• Updated the semantics of :defined to re-align with specification changes (r205416)
• Added validations for a synchronously constructed custom element (r205386)
• Added support for the whenDefined() method on the CustomElementRegistry (r205315)
• Added a CustomElementRegistry check for reentrancy (r205261)

### JavaScript

• Enabled assignments in for…in head in non-strict mode (r204895)
• Changed newPromiseCapabilities to check that the given argument is a constructor (r205027)
• Fixed toString() to return the correct tag when called on proxy objects (r205023)

### Web APIs

• Added event support for <link preload> (r205269)
• Implemented x, y and ScrollToOptions arguments for Element.scroll(), Element.scrollTo(), and Element.scrollBy() (r205505)
• Updated location.toString to make it enumerable (r204953)
• Updated location.toString in Web Workers to make it enumerable (r204954)
• Changed Object.preventExtensions(window) to throw a TypeError exception (r205404)
• Aligned coords and srcset attribute parsing with the HTML specification (r205030, r205515)
• Added support for CanvasRenderingContext2D.prototype.resetTransform (r204878)
• Aligned cross-origin Object.getOwnPropertyNames() with the HTML specification (r205409)

### Web Inspector

• Added IndexedDB Database, ObjectStore, and Index data to the details sidebar (r205043)
• Added support for Shift-Command-D (⇧⌘D) to switch to the last used dock configuration (r205413)
• Added support for Shift-Tab (⇧⇥) to un-indent the selected line (r204924)
• Changed Command-D (⌘D) to select the next occurrence instead of deleting the line (r205414)
• Added a visual indicator for shadow content in the DOM tree (r205322)
• Allowed hiding of CSS variables in the Computed styles panel (r205518)
• Fixed an issue that prevented using an Undo action in the breakpoint editor (r205499)
• Prevented the resource content view from showing “CR” characters (r205517)
• Fixed an issue preventing re-inspecting the page after a Web Inspector process crash (r205370)
• Improved the minification detection heuristic for small resources (r205314)
• Fixed an issue causing network record bars to be positioned on unexpected rows (r205349)
• Provided a way to clear an IndexedDB object store (r205041)
• Improved the debugger popover to pretty print functions (r205223)
• Corrected unexpected cursor changes while dragging ruler handle in the rendering frames timeline (r204940)
• Corrected the display of a plain text XHR response with responseType="blob" (r205268)

### CSS

• Implemented CSS.escape according to the CSSOM specification (r204952)
• Improved CSS stylesheet checks to ensure clean stylesheets are accessible from JavaScript (r205455)
• Improved :enabled and :disabled selectors to only match elements that can be disabled (r205050)

### Rendering

• Fixed scrollbars for a <table> with overflow content inside <div align="right"> (r205489)
• Added support for non-BMP MathML operators U+1EEF0 and U+1EEF1 (r205111)
• Fixed getting font bounding rect for MathML (r205031)

### Security

• Changed the Image Loader to set the fetch mode according its crossOrigin attribute (r205134)
• Added a SecurityError when trying to access cross-origin Location properties (r205026)
• Updated Object.defineProperty() and Object.preventExtensions() to throw an error for a cross-origin Window or Location object (r205358, r205359)
• Updated Object.setPrototypeOf() to throw an error and return null when used on a cross-origin Window or Location object (r205205, r205258)

### Plugins

• Replaced YouTube.com Flash embeds with HTML5 equivalents on macOS (r205274)

## RE: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Bill Kasdorf (bkasdorf@apexcovantage.com) • October 06, 2016 • Permalink

Sorry for the tardy response, Liam.

Fundamentally, this issue isn't about "working in ebook readers" in the sense of rendering the math.

From the accessibility point of view, and specifically in the context of EPUBs, we are really looking for a solution where the pre-rendered equation (an image, typically rendered by a workflow from MathML upstream, ideally SVG) is what is displayed visually. We need that EPUB to be able to also _contain_ the MathML without triggering an RS to try to render it instead of the image; the publisher (now) wants to prioritize the image for visual rendering. Instead, that MathML needs to be available to AT.

Nobody thinks this is the ideal or ultimate solution. What we need is something that works right now (or soon) while MathML rendering in browsers and EPUB RSs is still so unreliable, so that publishers can safely stick that MathML in the EPUB and know that it will just get used for AT, without the RS trying to render it and failing. Otherwise they simply omit or comment out the MathML, which makes it unavailable to AT.

--Bill

-----Original Message-----
From: Liam R. E. Quin [mailto:liam@w3.org]
Sent: Wednesday, October 05, 2016 7:52 PM
To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger; public-digipub-ig@w3.org
Subject: Re: The MQ (or not) issue; what we are seeking

On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
> What we need is an interim solution that will make it safe for
> publishers to deliver the MathML along with the image that they want
> displayed visually. For now.
Does this have to work in ebook readers (which might or might not support JavaScript) as well as in Web browsers?

Liam

>


## Re: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • October 06, 2016 • Permalink

While that may be true that JS wasn’t permitted in EPUB 2 readers, the main point here is that publishers won’t put JS inside their EPUB files because certain distribution chains flat out reject any JS for just that point of potential security issues.  The reading system may or may not be able to support JS, which is why the default presentation must be an image with alt text, and only systems which understand MathML “could” expose the MathML to assistive technologies, if the user chooses to do so.  But ideally that mathML would be hidden visually but accessible to AT and the visual Image still present for low vision users and sighted assistants / teachers helping the reader navigate the MathML with AT.

Now there could be some older reading systems that may not honor the request to have the MathML offscreen/hidden and “could” display the presentational MathML visually in addition to the static image of the mathML, and this although undesired is something that we may just have to live with and make note of when testing on various reading systems.

The IDPF’s EPUB 3.1 Accessibility Task Force would like to have one or more examples of possible ways to "have our cake and eat it too”, which we will add to our EPUB 3.1 Accessibility Techniques document where we will list the pros and cons to each approach after testing the various options on as many reading systems we can.  Then leave it up to the publisher to decide which implementation they choose based on what their target markets are the results from our testing.

We would love as Florian has asked for some real examples that we can test against.

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org
Skype: charles_lapierre
Phone: 650-600-3301

> On Oct 6, 2016, at 4:44 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> Unfortunately, not.  Since JS wasn’t permitted in an EPUB 2 reader, there are many of those out there that do not even have a JS engine included.
>
> Leonard
>
> On 10/6/16, 1:07 AM, "Paul Topping" <pault@dessci.com> wrote:
>
>    When it is suggested that there are ebook readers that don't support JavaScript, what is meant is that they don't support JS embedded in the ebook content itself. Am I correct? AFAIK, virtually all ebook readers are browser engine-based and use JS code in their implementation. They just don't want content to contain JS as it is a potential security risk. I only point this out in case it makes a difference in this MQ discussion.
>
>    Paul
>
>> -----Original Message-----
>> From: George Kerscher [mailto:kerscher@montana.com]
>> Sent: Wednesday, October 05, 2016 6:44 PM
>> To: 'Liam R. E. Quin' <liam@w3.org>; 'Bill Kasdorf'
>> 'Siegman, Tzviya - Hoboken' <tsiegman@wiley.com>; Peter Krautzberger
>> <peter.krautzberger@mathjax.org>; public-digipub-ig@w3.org
>> Subject: RE: The MQ (or not) issue; what we are seeking
>>
>> You ask: "Does this have to work in ebook readers (which might or might not
>> support JavaScript) as well as in Web browsers?"
>>
>> George responds: Yes, the publishers want to distribute their content into all
>> markets. The visual presentation is essential, and people using access
>> technology need to get at the semantically rich information.
>>
>> Best
>> George
>>
>>
>>
>> -----Original Message-----
>> From: Liam R. E. Quin [mailto:liam@w3.org]
>> Sent: Wednesday, October 05, 2016 5:52 PM
>> To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger;
>> public-digipub-ig@w3.org
>> Subject: Re: The MQ (or not) issue; what we are seeking
>>
>> On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
>>> What we need is an interim solution that will make it safe for
>>> publishers to deliver the MathML along with the image that they want
>>> displayed visually. For now.
>> support JavaScript) as well as in Web browsers?
>>
>> Liam
>>
>>>
>>
>>
>>
>
>
>



## Re: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Leonard Rosenthol (lrosenth@adobe.com) • October 06, 2016 • Permalink

Unfortunately, not.  Since JS wasn’t permitted in an EPUB 2 reader, there are many of those out there that do not even have a JS engine included.

Leonard

On 10/6/16, 1:07 AM, "Paul Topping" <pault@dessci.com> wrote:

When it is suggested that there are ebook readers that don't support JavaScript, what is meant is that they don't support JS embedded in the ebook content itself. Am I correct? AFAIK, virtually all ebook readers are browser engine-based and use JS code in their implementation. They just don't want content to contain JS as it is a potential security risk. I only point this out in case it makes a difference in this MQ discussion.

Paul

> -----Original Message-----
> From: George Kerscher [mailto:kerscher@montana.com]
> Sent: Wednesday, October 05, 2016 6:44 PM
> To: 'Liam R. E. Quin' <liam@w3.org>; 'Bill Kasdorf'
> 'Siegman, Tzviya - Hoboken' <tsiegman@wiley.com>; Peter Krautzberger
> <peter.krautzberger@mathjax.org>; public-digipub-ig@w3.org
> Subject: RE: The MQ (or not) issue; what we are seeking
>
> You ask: "Does this have to work in ebook readers (which might or might not
> support JavaScript) as well as in Web browsers?"
>
> George responds: Yes, the publishers want to distribute their content into all
> markets. The visual presentation is essential, and people using access
> technology need to get at the semantically rich information.
>
> Best
> George
>
>
>
> -----Original Message-----
> From: Liam R. E. Quin [mailto:liam@w3.org]
> Sent: Wednesday, October 05, 2016 5:52 PM
> To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger;
> public-digipub-ig@w3.org
> Subject: Re: The MQ (or not) issue; what we are seeking
>
> On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
> > What we need is an interim solution that will make it safe for
> > publishers to deliver the MathML along with the image that they want
> > displayed visually. For now.
> support JavaScript) as well as in Web browsers?
>
> Liam
>
> >
>
>
>



## Re: [mediaqueries] MathML

Source: www-style@w3.org Mail Archives • Christoph Päper (christoph.paeper@crissov.de) • October 06, 2016 • Permalink

Florian Rivoal <florian@rivoal.net>:
>
> - Even though MathML is markup, and therefore more amenable to support by screenreaders than plain images, it is not actually a good format for accessibility purposes, and screen reader integration is not that good either. Alternatives such as HTML or SVG representations of the content with sufficient ARIA annotations can give better results.

That’s assuming presentation MathML, I guess, and “plain images” are bitmap formats.

> - While a number of publishers do express the desire to use MathML in production and would welcome the help of such an MQ for doing that, most of those who have actually tried to use MathML in production give up after testing shows that neither the presentation nor the accessibility is up to their expectations, and therefore go back to publishing math in some other form (images, svg…).

I would much prefer if image formats, SVG in particular, would be able to embed or link to the source code used to generate them and if source formats, e.g. MathML, could embed or link to a fallback/preview rendition of their content. It seems that would match existing workflows in publishing quite well.

<svg>
<source>
<math alternative="formula.png">
<source href="formula.tex" />
[/itex]
</source>
</svg>

Alternatively, (presentation) MathML could be treated like an image by HTML and CSS (e.g. within content). For alternative and fallback content, the web platform tried <object> and server-side content negotiation already. Still, I don’t see why Mediaqueries should be involved at all, unless its purpose is now seen as full-scale client-side content negotiation.


## Re: [mediaqueries] MathML

Source: www-style@w3.org Mail Archives • Giuseppe Bilotta (giuseppe.bilotta@gmail.com) • October 06, 2016 • Permalink

On Thu, Oct 6, 2016 at 5:19 AM, Florian Rivoal <florian@rivoal.net> wrote:
>
>> On Oct 6, 2016, at 04:49, Paul Topping <pault@dessci.com> wrote:
>>
>> So it looks like MathML will lose yet another battle. I'm sure it will survive this ding like it has all the others.
>
> I don't think that is true.
>
> We are not saying that we refuse to help MathML. We are saying that a MathML MQ would not help MathML, and therefore is not worth doing.
>
> I have heard:
>
> - We'd like a MathML MQ, because it would help
>
> - It would not help, here is why
>
> I have not heard:
>
> - Yes it would help, **here is how**

As an amateur content author that uses MathML and would rather see
native implementations of it in all browsers (however incomplete they
might be initially), and as someone that agrees with the conclusions
if not the spirit of the post linked at the beginning of this thread
about why a MathML media query would be useless, I can think of at
least one case where a (boolean: supported/not supported) MathML media
query would be at least of some use: to allow content authors to
provide fallback CSS-only support for at least a limited subset of
Presentational MathML.

In other words, content providers could have:

@import css-only-presentational-mathml.css (mathml: false);

or similar, and the imported CSS would have the necessary rules to lay
out MahML objects with at least a modicum of credibility (IIRC,
Opera/Presto did just that internally, in fact, and a similar CSS-only
solution was proposed as a fallback in Chromium when support for
MathML was ripped out). Such a solution would be considerably more
still provide acceptable, if not satisfactory, results.

So there _is_ actually a (reasonable, as unsatisfactory as it might
be) use case for a MathML media query, although honestly rather than a
media query I see it more as a possible extension to @supports.

Of course I'd rather have user agents actually support MathML.

--
Giuseppe "Oblomov" Bilotta


## RE: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Paul Topping (pault@dessci.com) • October 06, 2016 • Permalink

When it is suggested that there are ebook readers that don't support JavaScript, what is meant is that they don't support JS embedded in the ebook content itself. Am I correct? AFAIK, virtually all ebook readers are browser engine-based and use JS code in their implementation. They just don't want content to contain JS as it is a potential security risk. I only point this out in case it makes a difference in this MQ discussion.

Paul

> -----Original Message-----
> From: George Kerscher [mailto:kerscher@montana.com]
> Sent: Wednesday, October 05, 2016 6:44 PM
> To: 'Liam R. E. Quin' <liam@w3.org>; 'Bill Kasdorf'
> 'Siegman, Tzviya - Hoboken' <tsiegman@wiley.com>; Peter Krautzberger
> <peter.krautzberger@mathjax.org>; public-digipub-ig@w3.org
> Subject: RE: The MQ (or not) issue; what we are seeking
>
> You ask: "Does this have to work in ebook readers (which might or might not
> support JavaScript) as well as in Web browsers?"
>
> George responds: Yes, the publishers want to distribute their content into all
> markets. The visual presentation is essential, and people using access
> technology need to get at the semantically rich information.
>
> Best
> George
>
>
>
> -----Original Message-----
> From: Liam R. E. Quin [mailto:liam@w3.org]
> Sent: Wednesday, October 05, 2016 5:52 PM
> To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger;
> public-digipub-ig@w3.org
> Subject: Re: The MQ (or not) issue; what we are seeking
>
> On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
> > What we need is an interim solution that will make it safe for
> > publishers to deliver the MathML along with the image that they want
> > displayed visually. For now.
> support JavaScript) as well as in Web browsers?
>
> Liam
>
> >
>
>
>



## Re: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Florian Rivoal (florian@rivoal.net) • October 06, 2016 • Permalink

In order to convince people who are not convinced, can Peter or Robin give a concrete example (i.e. a link to a web page or an epub that works) that demonstrate the techniques they say are available today that give both good visual rendering and good accessibility?

I think that would be a useful addition to the discussion, because it would give a clear target to beat. If someone could come up with a way to do the same example in a better way using the MQ, then we'd have strong justifications for having the MQ. If not, we'd have good evidence for supporting the rejection of the MQ.

(writing up the MQ version of the example while the MQ does not exist is not a problem. Just write the document twice, with the only differences being things that can be toggled based on a media query, and ask readers to load the right document in the right environment, based on a manual evaluation of what the MQ would do).

- Florian

> On Oct 6, 2016, at 10:43, George Kerscher <kerscher@montana.com> wrote:
>
> You ask: "Does this have to work in ebook readers (which might or might not support JavaScript) as well as in Web browsers?"
>
> George responds: Yes, the publishers want to distribute their content into all markets. The visual presentation is essential, and people using access technology need to get at the semantically rich information.
>
> Best
> George
>
>
>
> -----Original Message-----
> From: Liam R. E. Quin [mailto:liam@w3.org]
> Sent: Wednesday, October 05, 2016 5:52 PM
> To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger; public-digipub-ig@w3.org
> Subject: Re: The MQ (or not) issue; what we are seeking
>
> On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
>> What we need is an interim solution that will make it safe for
>> publishers to deliver the MathML along with the image that they want
>> displayed visually. For now.
> support JavaScript) as well as in Web browsers?
>
> Liam
>
>>
>
>
>
>


## Re: [mediaqueries] MathML

Source: www-style@w3.org Mail Archives • Florian Rivoal (florian@rivoal.net) • October 06, 2016 • Permalink


> On Oct 6, 2016, at 04:49, Paul Topping <pault@dessci.com> wrote:
>
> So it looks like MathML will lose yet another battle. I'm sure it will survive this ding like it has all the others.

I don't think that is true.

We are not saying that we refuse to help MathML. We are saying that a MathML MQ would not help MathML, and therefore is not worth doing.

I have heard:

- We'd like a MathML MQ, because it would help

- It would not help, here is why

I have not heard:

- Yes it would help, **here is how**

Statements that it is important to support MathML will not lead to progress in this discussion unless they come with an explanation of *how* this Media Query would help.

If you want this MQ, I suggest trying to frame an explanation along these lines:

1) Here's the best we can do about including math in an ePub / web page today, without the MQ

<insert concrete example with code sample or high level description of the code>

2) Here is what we could do if we had the MathML MQ

<insert concrete example with code sample or high level description of the code>

3) here is how 2) is better than 1) for users A B and C in environment X Y or Z

alternative 3) here is how it is just as good for users, but simpler for authors

If we had that, people could argue about whether 1 is indeed the best we can do, and whether 2 is indeed an improvement over it. If we ended up agreeing, you'd get the MQ. If we ended up disproving it, we'd all have learned about the current best way to do math on the web, and could document that.

- Florian


## RE: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • George Kerscher (kerscher@montana.com) • October 06, 2016 • Permalink

You ask: "Does this have to work in ebook readers (which might or might not support JavaScript) as well as in Web browsers?"

George responds: Yes, the publishers want to distribute their content into all markets. The visual presentation is essential, and people using access technology need to get at the semantically rich information.

Best
George

-----Original Message-----
From: Liam R. E. Quin [mailto:liam@w3.org]
Sent: Wednesday, October 05, 2016 5:52 PM
To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger; public-digipub-ig@w3.org
Subject: Re: The MQ (or not) issue; what we are seeking

On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
> What we need is an interim solution that will make it safe for
> publishers to deliver the MathML along with the image that they want
> displayed visually. For now.
support JavaScript) as well as in Web browsers?

Liam

>


## Re: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Liam R. E. Quin (liam@w3.org) • October 05, 2016 • Permalink

On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
> What we need is an interim solution that will make it safe for
> publishers to deliver the MathML along with the image that they want
> displayed visually. For now.
Does this have to work in ebook readers (which might or might not
support JavaScript) as well as in Web browsers?

Liam

>


## Fonts at the Web Engines Hackfest 2016

Last week I travelled to Galicia for one of the regular gatherings organized by Igalia. It was a great pleasure to meet again all the Igalians and friends. Moreover, this time was a bit special since we celebrated our 15th anniversary :-)

Photo by Alberto Garcia licensed under CC BY-SA 2.0.

I also attended the third edition of the Web Engines Hackfest, sponsored by Igalia, Collabora and Mozilla. This year, we had various participants from the Web Platform including folks from Apple, Collabora, Google, Igalia, Huawei, Mozilla or Red Hat. For my first hackfest as an Igalian, I invited some experts on fonts & math rendering to collaborate on OpenType MATH support HarfBuzz and its use in math rendering engines. In this blog post, I am going to focus on the work I have made with Behdad Esfahbod and Khaled Hosny. I think it was again a great and productive hackfest and I am looking forward to attending the next edition!

## OpenType MATH in HarfBuzz

Photo by @webengineshackfest licensed under CC BY-SA 2.0.

Behdad gave a talk with a nice overview of the work accomplished in HarfBuzz during ten years. One thing appearing recently in HarfBuzz is the need for APIs to parse OpenType tables on all platforms. As part of my job at Igalia, I had started to experiment adding support for the MATH table some months ago and it was nice to have Behdad finally available to review, fix and improve commits.

When I talked to Mozilla employee Karl Tomlinson, it became apparent that the simple shaping API for stretchy operators proposed in my blog post would not cover all the special cases currently implemented in Gecko. Moreover, this shaping API is also very similar to another one existing in HarfBuzz for non-math script so we would have to decide the best way to share the logic.

As a consequence, we decided for now to focus on providing an API to access all the data of the MATH table. After the Web Engines Hackfest, such a math API is now integrated into the development repository of HarfBuzz and will available in version 1.3.3 :-)

## MathML in Web Rendering Engines

Currently, several math rendering engines have their own code to parse the data of the OpenType MATH table. But many of them actually use HarfBuzz for normal text shaping and hence could just rely on the new math API the math rendering too. Before the hackfest, Khaled already had tested my work-in-progress branch with libmathview and I had done the same for Igalia’s Chromium MathML branch.

MathML test for OpenType MATH Fraction parameters in Gecko, Blink and WebKit.

Once the new API landed into HarfBuzz, Khaled was also able to use it for the XeTeX typesetting system. I also started to experiment this for Gecko and WebKit. This seems to work pretty well and we get consistent results for Gecko, Blink and WebKit! Some random thoughts:

• The math data is exposed through a hb_font_t which contains the text size. This means that the various values are now directly resolved and returned as a fixed-point number which should allow to avoid rounding errors we may currently have in Gecko or WebKit when multiplying by float factors.
• HarfBuzz has some magic to automatically handle invalid offsets and sizes that greatly simplifies the code, compared to what exist in Gecko and WebKit.
• Contrary to Gecko’s implementation, HarfBuzz does not cache the latest result for glyph-specific data. Maybe we want to keep that?
• The WebKit changes were tested on the GTK port, where HarfBuzz is enabled. Other ports may still need to use the existing parsing code from the WebKit tree. Perhaps Apple should consider adding support for the OpenType MATH table to CoreText?

## Brotli/WOFF2/OTS libraries

Photo by @webengineshackfest licensed under CC BY-SA 2.0.

We also updated the copies of WOFF2 and OTS libraries in WebKit and Gecko respectively. This improves one requirement from the WOFF2 specification and allows to pass the corresponding conformance test.

Gecko, WebKit and Chromium bundle their own copy of the Brotli, WOFF2 or OTS libraries in their source repositories. However:

• We have to use more or less automated mechanisms to keep these bundled copies up-to-date. This is especially annoying for Brotli and WOFF2 since they are still in development and we must be sure to always integrate the latest security fixes. Also, we get compiler warnings or coding style errors that do not exist upstream and that must be disabled or patched until they are fixed upstream and imported again.

• This obviously is not an optimal sharing of system library and may increase the size of binaries. Using shared libraries is what maintainers of Linux (or other FLOSS systems) generally ask and this was raised during the WebKitGTK+ session. Similarly, we should really use the system Brotli/WOFF2 bundled in future releases of Apple’s operating systems.

There are several issues that make hard for package maintainers to provide these libraries: no released binaries or release tags, no proper build system to generate shared libraries, use of git submodule to include one library source code into another etc Things have gotten a bit better for Brotli and I was able to tweak the CMake script to produce shared libraries. For WOFF2, issue 40 and issue 49 have been inactive but hopefully these will be addressed in the future…

## RE: [mediaqueries] MathML

Source: www-style@w3.org Mail Archives • Paul Topping (pault@dessci.com) • October 05, 2016 • Permalink

My arguments were not political. I never used the word "deserves" or anything coming close to it. Sounds like you are the one making a political decision and using my position for cover. [Sorry to be so blunt, following your lead]

So it looks like MathML will lose yet another battle. I'm sure it will survive this ding like it has all the others.

Paul

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Wednesday, October 05, 2016 11:49 AM
> To: Paul Topping <pault@dessci.com>
> Cc: Florian Rivoal <florian@rivoal.net>; Avneesh Singh
> <avneesh.sg@gmail.com>; www-style list <www-style@w3.org>; W3C Digital
> Publishing IG <public-digipub-ig@w3.org>; Peter Krautzberger
> <peter.krautzberger@mathjax.org>
> Subject: Re: [mediaqueries] MathML
>
> On Wed, Oct 5, 2016 at 10:45 AM, Paul Topping <pault@dessci.com> wrote:
> >> > Given a suitable definition of "UA implements MathML", there should
> >> > be
> >> no question that it exposes an important UA characteristic. Since
> >> MathML is part of HTML5, it could be argued that it should have an MQ
> >> even if all UAs report no implementation using it.
> >>
> >> There is not MQ for HTML5. There is no MQ for features of HTML5. So
> >> that's not a very good guideline.
> >
> > I wasn't talking about MQ for features of HTML5. Just using MathML's
> presence in the HTML5 spec as an indication that it is significant.  If it can be
> argued that MathML support is a "characteristic of the rendering device", to
> use your phrase, then it is a significant one due to MathML's inclusion in
> HTML5.
>
> (Sorry to be blunt here.) We don't make technical decisions based on political
> reasoning. MathML doesn't get a MQ because it "deserves" it.
> We make MQs when the information they expose has real use-cases for
> authors: where there's some situation where the "default" rendering is
> significantly worse for some reason, and being able to tell when you're in
>
> The original discussion about the math MQ in the CSSWG led us to believe
> that it passed this bar (or was at least close to it; the MQ itself was simple
> enough that it didn't need to clear a very high hurdle).  Later discussion at
> TPAC, which Florian summarized and I added to, has shifted our belief the
> opposite way.  It appears, based on the current information available to us,
> that the above conditions are not met - current rendering techniques
> generate results that are acceptable to page authors regardless of whether
> MathML is natively supported or not, and knowing whether or not it was
> natively supported wouldn't allow authors to significantly improve their page
> rendering.
>
> ~TJ


## Re: [mediaqueries] MathML

Source: www-style@w3.org Mail Archives • Tab Atkins Jr. (jackalmage@gmail.com) • October 05, 2016 • Permalink

On Wed, Oct 5, 2016 at 10:45 AM, Paul Topping <pault@dessci.com> wrote:
>> > Given a suitable definition of "UA implements MathML", there should be
>> no question that it exposes an important UA characteristic. Since MathML is
>> part of HTML5, it could be argued that it should have an MQ even if all UAs
>> report no implementation using it.
>>
>> There is not MQ for HTML5. There is no MQ for features of HTML5. So that's
>> not a very good guideline.
>
> I wasn't talking about MQ for features of HTML5. Just using MathML's presence in the HTML5 spec as an indication that it is significant.  If it can be argued that MathML support is a "characteristic of the rendering device", to use your phrase, then it is a significant one due to MathML's inclusion in HTML5.

(Sorry to be blunt here.) We don't make technical decisions based on
political reasoning. MathML doesn't get a MQ because it "deserves" it.
We make MQs when the information they expose has real use-cases for
authors: where there's some situation where the "default" rendering is
significantly worse for some reason, and being able to tell when
significant benefits.

The original discussion about the math MQ in the CSSWG led us to
believe that it passed this bar (or was at least close to it; the MQ
itself was simple enough that it didn't need to clear a very high
hurdle).  Later discussion at TPAC, which Florian summarized and I
added to, has shifted our belief the opposite way.  It appears, based
on the current information available to us, that the above conditions
are not met - current rendering techniques generate results that are
acceptable to page authors regardless of whether MathML is natively
supported or not, and knowing whether or not it was natively supported
wouldn't allow authors to significantly improve their page rendering.

~TJ


## RE: [mediaqueries] MathML

Source: www-style@w3.org Mail Archives • Paul Topping (pault@dessci.com) • October 05, 2016 • Permalink

> > Given a suitable definition of "UA implements MathML", there should be
> no question that it exposes an important UA characteristic. Since MathML is
> part of HTML5, it could be argued that it should have an MQ even if all UAs
> report no implementation using it.
>
> There is not MQ for HTML5. There is no MQ for features of HTML5. So that's
> not a very good guideline.

I wasn't talking about MQ for features of HTML5. Just using MathML's presence in the HTML5 spec as an indication that it is significant.  If it can be argued that MathML support is a "characteristic of the rendering device", to use your phrase, then it is a significant one due to MathML's inclusion in HTML5.

Paul


## RE: [dpub] agenda 20161003

Source: public-digipub-ig@w3.org Mail Archives • Paul Topping (pault@dessci.com) • October 05, 2016 • Permalink

I don’t think many people misunderstand your position on this, Peter. My feeling, as I’ve previously stated, is that the problem MathML was intended to solve is a hard one. We shouldn’t throw it out just because it has flaws and hasn’t 100% met its goals. Instead, an alternative should be developed. With due respect, what I’ve seen offered so far as an alternative is just a collection of hacks and not a comprehensive solution. As such, I expect it will not achieve its (mostly unstated) goals either and the problem will remain unsolved. Of course, I don’t want to stop anyone from trying to solve the problem. But, until such a solution has been developed and proven to be superior, we shouldn’t tear down our existing solution, MathML. What you say here clearly attempts to kill the competition (MathML) before your solution is even a contender. I understand you want to divert energy away from MathML and toward your solution but, to do so, you need to talk up your solution, not simply tear down MathML.

Paul

From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
Sent: Wednesday, October 05, 2016 8:18 AM
To: Bill Kasdorf <bkasdorf@apexcovantage.com>
Cc: Alan Stearns <stearns@adobe.com>; Siegman, Tzviya - Hoboken <tsiegman@wiley.com>; public-digipub-ig@w3.org
Subject: Re: [dpub] agenda 20161003

Ok, this might be viewed as a rant. But since I've been apparently too subtle about this in the past:

> we do that_ because the value of the MathML in the workflow is unquestionable

I think this is the key error in this argument. In my experience, the value of MathML for the web has been extremely exaggerated, in particular for visual but more importantly for other use cases, especially accessibility.

Personally, I think MathML is a fundamentally flawed standard when it comes to the web. It might be fine for xml document workflows but for the web it's ultimately a bad technology from a lost age called the 90s.

It need not be used and should not be used today.

Regards,
Peter.

On Wed, Oct 5, 2016 at 4:59 PM, Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>> wrote:
I still think we're missing the point of the initial request. And maybe the ensuing discussion reveals that MQ (despite its apparent appealing simplicity as the _interim_ solution we are looking for) is not going to work and we need to come up with another tack that _will work right now_, not a year or two years or a decade from now.

Here's what we need.

--Publisher has MathML.
To recap what I've said a gazillion times, STM publishers generate literally millions of equations as MathML. I wouldn't be surprised if the organization I work for _itself_ produces millions of equations as MathML _every year_. Yes, we have to do some tweaks sometimes to work around things that go wrong, but _we do that_ because the value of the MathML in the workflow is unquestionable. We could not do what we do without it.

--Publisher creates image of equation from MathML.
I am a huge fan of MathJax, and I am thrilled at the developments over the past year, wrt both server-side functionality and accessibility enhancement. Kudos to Peter and co. SVG or HTML+CSS or .jpg, the publisher has controlled "this is what the equation must look like." Visually.

--Publisher puts BOTH the MathML and the image in an EPUB.
Publishers are NOT doing this now because they can't trust that the image will be used when the MathML support is insufficient; they just want to provide the image to be safe. They don't put the MathML in the EPUB because then some reading systems try to use it and mess it up or don't even realize they should use the image.

--Publisher has a way to say "use the image for visual rendering and make the MathML available to AT."
This is what we need RIGHT NOW while the industry struggles to come up with a real solution, which may or may not ultimately involve rendering MathML reliably (though of course remember those millions of equations rendered from MathML that STM publishers find quite acceptable).

We are not looking for an assertion that a reading system will render the MathML perfectly. That may be the reason the appealing MQ assertion won't fly.

What we need is an interim solution that will make it safe for publishers to deliver the MathML along with the image that they want displayed visually. For now.

Bill Kasdorf

VP and Principal Consultant | Apex CoVantage

p:

734-904-6252<tel:734-904-6252>  m:   734-904-6252<tel:734-904-6252>

ISNI: http://isni.org/isni/0000000116490786

ORCiD: https://orcid.org/0000-0001-7002-4786<https://orcid.org/0000-0001-7002-4786?lang=en>

Sent: Wednesday, October 05, 2016 10:25 AM
To: Siegman, Tzviya - Hoboken; Peter Krautzberger; public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>

Subject: Re: [dpub] agenda 20161003

Tzviya,

I thought exactly the same thing when I read it, but Peter had beat me to it. There’s already a long thread discussing this on www-style.

Thanks,

Alan

From: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>
Date: Wednesday, October 5, 2016 at 5:24 AM
To: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>, "public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>" <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: RE: [dpub] agenda 20161003
Resent-From: <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Resent-Date: Wednesday, October 5, 2016 at 5:25 AM

Thanks, Peter. I think it would be helpful to pass this on to the CSS WG.

Tzviya Siegman
Wiley
201-748-6884<tel:201-748-6884>
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
Sent: Sunday, October 02, 2016 10:37 AM
To: public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>
Cc: W3C Digital Publishing IG
Subject: Re: [dpub] agenda 20161003

Regrets from me. It's a public holiday where I live.

But I wrote up my thoughts on the media query at https://www.peterkrautzberger.org/0190/

As I said in the breakout meeting, this is my personal opinion and what I would tell my clients.

Best,
Peter.

On Sep 30, 2016 3:50 PM, "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:

Hi DPUB,

Below is the draft agenda for next week's IG concall, to be held at the usual time and day [0].

Please let us know if you are able to scribe. Please join the call via WebEx [1] and join IRC [13] for live chat & minutes (IRC channel #dpub).

Webex: https://www.w3.org/dpub/IG/wiki/WebEx<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_dpub_IG_wiki_WebEx&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=HDWX517A02R9inge-INWWnkv3kZpEQ_xnLCWv-ZBkN8&e=> (note: you will need a password. Refer to earlier message for pwd or log in to IRC to obtain)

Agenda:

* Approve minutes [2] [3] [4]

* New Meeting time: beginning next week,  10 Oct, Monday. 16:00 UTC/12:00 EDT/18:00 CET

* Post-TPAC Action items: See list below

* Remember to fill out post-TPAC Survey [5]

Post TPAC Action items:

•          WCAG: (@Avneesh/Charles)

o   provide techniques etc from EPUB to AWK and JO by Dec,

o   schedule joint call (chairs can coordinate scheduling)

o   See https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria for info about writing new success criteria and https://github.com/w3c/wcag21/issues/1 for SC template.

•         CSS

o   Provide Dean Jackson with information about why publishers need tables

o   Clarify with Peter K what status of Math MQ is and next steps

o   @dave – look into InDesign hanging punctuation

o   @david_wood: table samples to Dean Jackson

o   @liam – XSL-FO => CSS-FO

•         (P)WP:

o   https://www.w3.org/dpub/IG/track/actions/64 @Tzviya assign Heather’s issues to individuals

o   @Leonard dedupe PWP-UCR

o   @Heather reorg PWP-UCR

o   @brady action 65: split PWP into review chunks

o   Many have been assigned github issues. Please check to see if you’ve been assigned an issue. Pay attention to the issues.

o   Future: look into Object Model for WP

•         POE:

o   Tzviya/BillK to reach out to Journals Publishers re: POE, ODRL mapping

[0] http://www.timeanddate.com/worldclock/fixedtime.html?msg=DPUB+IG+Meeting&iso=20161003T11&p1=43

[1] http://www.w3.org/dpub/IG/wiki/WebEx<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_dpub_IG_wiki_WebEx&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=AWVyHkab-8YSKIFvg5cX199RKBKASxchJoT8vOl6Eds&e=>

[2] https://www.w3.org/2016/09/12-dpub-minutes.html

[3] https://www.w3.org/2016/09/19-dpub-minutes.html

[4] https://www.w3.org/2016/09/20-dpub-minutes.html

[5] https://www.w3.org/2002/09/wbs/35125/tpac2016-feedback/

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

To join this telecon, use the following logistics:

Webex [10]

Join chat and minutes on Zakim

We will also use an IRC channel to minute the discussions:

Available ports (choose one): 6667, 6665, 21 IRC channel: #dpub See how to connect [11] using an IRC client [12] or our web interface [13] User Instructions for Zakim [14] To mute your line press 61#. Unmute is 60#.

To place yourself on the speaker queue ('q+' in irc) press 41# (Handup).

Unqueue ('q-' in irc) is 40#.

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

Digital Publishing Interest Group home page http://www.w3.org/dpub/IG/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_dpub_IG_&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=qizMA2uF3w05lFnio42yhvYTbP3KdqfhoGKdarm9vp8&e=> Digital Publishing Interest Group Wiki

http://www.w3.org/dpub/IG/wiki/Main_Page<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_dpub_IG_wiki_Main-5FPage&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=YIM72-SWeepRM7ccMwTLXXb_ommtJZ_7dywgTAhwh2w&e=>

* Digital Publishing Interest Group Charter http://www.w3.org/2013/02/digpubig.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2013_02_digpubig.html&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=MspFOYljKyd3OvLK4HQ0tSDoyy7deeDPXBsY2eTZ4Bg&e=>

[10] http://www.w3.org/dpub/IG/wiki/WebEx<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_dpub_IG_wiki_WebEx&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=AWVyHkab-8YSKIFvg5cX199RKBKASxchJoT8vOl6Eds&e=>

[11] http://www.w3.org/Project/IRC/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_Project_IRC_&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=nSqDkNODuFfTEvgyvxepXvGUWc5gfHHusclLX-pifqw&e=>

[13] http://www.w3.org/Project/IRC/#Client<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_Project_IRC_-23Client&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=dMrCmw2z6nfp4OehFQaPzST9jcnnQr0vCJKszDMz3yk&e=>

[13] http://irc.w3.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__irc.w3.org_&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=TZckj2m7jaTSnt-0_YfNwbvT9Wr_8945IKVYL7vyACo&e=>

[14] http://www.w3.org/2002/01/UsingZakim<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_2002_01_UsingZakim&d=CwMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=rIuqucla5dlbf2RphNNvB8RvCVimlUMYalDkG5lRDlw&s=evvsspcHumsRw4CWlOs5pGNisePyMksCrMEmpBaJ0ag&e=>

Tzviya Siegman
Wiley
201-748-6884<tel:201-748-6884>
tsiegman@wiley.com<mailto:tsiegman@wiley.com>



## Re: [mediaqueries] MathML

Source: www-style@w3.org Mail Archives • Florian Rivoal (florian@rivoal.net) • October 05, 2016 • Permalink


> On Oct 6, 2016, at 00:55, Paul Topping <pault@dessci.com> wrote:
>
> I'll admit that MathML has some challenges in terms of being well-defined with its implementation in UAs being so variable and the MathML spec so complex and open to interpretation, but I'm sure they can be solved.

Sure, and improving the quality of MathML implementations is likely to improve usage of MathML as a delivery format. I don't think the MQ would.

> Given a suitable definition of "UA implements MathML", there should be no question that it exposes an important UA characteristic. Since MathML is part of HTML5, it could be argued that it should have an MQ even if all UAs report no implementation using it.

There is not MQ for HTML5. There is no MQ for features of HTML5. So that's not a very good guideline.

There are MQs for characteristics of the rendering device (see https://drafts.csswg.org/mediaqueries/). The closest one to a MathML MQ is the 'script' MQ, but this one is different and fairly unique in that it does not need extra granularity on the level of support for the scripting language: if you can run scripts, you can make these tests yourself in the scripts that you can run. The same isn't true of MathML.

- Florian


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