RE: [mediaqueries] MathML

Sounds like MQs are currently really only about display properties. It is a shame because obviously the idea of telling the server about the client so it can return the right content is a much more generally applicable concept. Is there no effort to make MQs more general or, perhaps, some other kind of query in the web standard world that would allow the UA to pass non-display properties to the server?

Semantic markup items (dates, events, street addresses, phone numbers, etc.) are probably handled by the server by returning all data associated with the item, independent of the client, and let the UA simply do whatever it wants. There is no standard mechanism whereby the client tells the server what is needed and the server customizes the reply accordingly. Too bad.

If this is all reasonable (a big if), then it means that the server should always return MathML for equations, along with any other data it has on them, without regard to client properties (display or otherwise), and let the UA decide what to do with the data. The UA will consider client properties, of course.

Paul

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Tuesday, October 04, 2016 1:19 PM
> To: Paul Topping <pault@dessci.com>
> Cc: Avneesh Singh <avneesh.sg@gmail.com>; Florian Rivoal
> <florian@rivoal.net>; 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 Tue, Oct 4, 2016 at 11:36 AM, Paul Topping <pault@dessci.com> wrote:
> > Except when the person using the UA needs math accessibility.
> Accessibility requires that the rendering be customized for the individual. The
> text to be spoken for a mathematical expression is different for a student
> learning math than for a scientist who already understands the math. This is
> mostly easily achieved via client-side implementation, though it is technically
> feasible to implement such a feature at the server with perhaps degradation
> in quality and higher latency. Since the user has to navigate around the math,
> latency is a particular issue. For practical reasons, delivering MathML to the
> UA works best. Finally, this is a classic chicken-and-egg problem. Publishers
> want to deliver MathML but, as most are in education, they also have to
> serve all users and can't usually dictate the user's browser.
> 
> As I stated in my earlier message, using MathML for a11y only is
> already possible, and can be done without having to care about the
> UA's support for displaying MathML.  (You simply visually hide it, so
> that whether or not it's rendered isn't detectable.)  There are many
> ways to render the MathML to a different display format - HTML, SVG,
> raster image - some of which can offer good a11y interaction for
> sighted users too.
> 
> And again, per the discussion that Florian outlined at the top of this
> thread, and I offered further details of, "publishers want to deliver
> MathML" does *not* appear to be a universal sentiment, at all.  They
> want good-looking equations and accessibility. MathML *theoretically*
> provides both of them in a single package, but in practice it often
> fails at the first (or at least requires extensive testing across all
> the target UAs), and it's possible to use MathML merely as an
> authoring format, rendering to a different display format and then
> including the MathML in a hidden fashion for a11y, thus achieving
> publisher goals without requiring an additional MQ.
> 
> On Tue, Oct 4, 2016 at 12:57 PM, Joe Trenton <joe.trenton.iiii@gmail.com>
> wrote:
> > Are high-quality applications out there that produce SVG out of MathML?
> 
> Yes; MathJax in particular gives pretty great results. (And once
> you've generated it in MathJax, you can be sure that it'll display
> correctly across browsers, as SVG rendering is predictable. Or MathJax
> can output to HTML, or <canvas> for a raster image.)
> 
> ~TJ

Received on Tuesday, 4 October 2016 22:08:21 UTC