Re: [mediaqueries] MathML

On 02/10/2016 22:47 , Florian Rivoal wrote:
> - A variant of the MQ was proposed. It would instead mean that MathML
> was supported AND that the user expressed explicit preference for
> MathML content (via a setting of some kind). This would be useful in
> an accessibility context for users who know the strengths and
> limitations of their environment, and based on that make a judgment
> call that a MathML rendition would serve them best. While this MQ
> wouldn't be wrong or harmful, it doesn't really change the fact that
> MathML is not great for accessibility and that there are better
> alternatives, and that implementations and integration with screen
> readers are not great either, so it would not be terribly useful.

Just as a data point: we actually do ship MathML to the client but we do
so in such a way that irrespective of browser support the actual MathML
is always positioned off-screen and an SVG rendering of it is shown
instead. The DOM is basically:

span[role="math"]
  math --> this is made _visually_ invisible
  svg --> this contains the pretties

The reason we do this is because the content may get long-term archived,
and in that case we want to maintain semantics as much as possible (even
if it's Presentation MML, it tells you more than just some squiggles).
I'm not saying this is particularly original, I just want to ground the
discussion.

Based on such markup, we could very easily use an MQ to switch between
the two. We would, however, *not* make use of a media query. Using a MQ
has two modes of failure:

  1) Browsers only report support when their support is perfect: you
never get any support.
  2) Browser report support when it's roughly there: you have an
unreliable predictor.

Note that we've been there, with `hasFeature()`. I know that some
resurrection of that idea is happening with `@supports`, but I remain
suspicious. I think that feature querying can work when it is very
granular, but the bigger what is being queried is the more room for
interpretation and the less useful it is.

The notion of having a MQ somehow responding to a user preference to get
MathML instead of alternatives is IMHO possibly worse. If I'm a MathML
fanatic I might turn it on and deprive myself of some beautiful SVG
squiggles. Conversely, if I'm a normal person or a mathematician I might
benefit from getting MathML instead of the horrendously pixellated, tiny
GIFs that publishers seem to insist are the thing to do but I have
likely never heard of MathML let alone of an option to prefer it.


If I had a wish my preferred option would be to have the ability to mark
up alternatives in HTML, a bit like <switch> but *without* the built-in
behaviour:

<alternative>
  <variant><math>...</math></variant>
  <variant><svg>...</svg></variant>
  <variant><img></variant>
  <variant>some long textual description</variant>
</alternative>

As an author I could specify my preferred option (perhaps just through
order) but the browser could override me ("nope I don't understand that
well enough", "my user actually prefers that one") and could afford
users the option of switching between representations.

That would match my publishing needs far better (and as a user I would
also love the option to switch to text in many cases). I do however
realise that this is a much more involved change.

-- 
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•

Received on Tuesday, 4 October 2016 13:26:00 UTC