Re: [mediaqueries] MathML

> On Oct 4, 2016, at 22:25, Robin Berjon <robin@berjon.com> wrote:
> 
> 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.

This completely matches with what Peter had been saying. Thanks for providing a datapoint.


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

I think the CSS one has a half-way decent chance of being a good idea,
but that is for reasons specific to CSS that don't generalise well:
 - It has an extremely fine granularity
 - Nowadays, for CSS, browsers are decent at waiting until features are quite reliable before shipping them.

The proposed MathMQ is not at all in that situation.


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

Interesting (and completely out of scope for the CSSWG:). How would you
deal with not showing all alternatives in UAs that are not aware of this new element,
without asking the author to hard-code in their stylesheet or markup which variant
should be display:none?

 - Florian

Received on Tuesday, 4 October 2016 14:34:08 UTC