W3C home > Mailing lists > Public > uri@w3.org > April 2014

RE: math: URI scheme and protocol handler

From: Michael Wojcik <Michael.Wojcik@microfocus.com>
Date: Mon, 28 Apr 2014 13:50:05 +0000
To: "uri@w3.org" <uri@w3.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C180880101ED496D@Rock-Exchange1.microfocus.com>
[Ugh - HTML email, which Outlook is unable to correctly reply to except by top-posting.]

Quoting mike amundsen:

                the best place for this is as an element: <mathspeak>

Are you proposing a new HTML5 element? A new MathML element?

                An alternative ... would be to use the "rel" attribute

With either a new element or a new token for the value of the rel attribute, user agents (browsers) have to be updated to recognize an extension to some markup language. How is that different from updating user agents to provide additional handling for MathML to enable text-to-speech?

For that matter, how is adding a new URI scheme (which user agents will have to recognize to make it usable) any different from simply having them recognize when a MathML assistive-technology application is available? OK, Gerado's page notes that some browsers support extending their set of URI-scheme handlers; but then many browsers support plug-ins, so it's six-of-one.

And if we introduce a new URI scheme, or rel-attribute value, or (worst of all) HTML element for the fairly specific task of rendering mathematical equations as speech, that looks like a slippery slope into all sorts of special-purpose extensions. If there's an opportunity to solve a general problem rather than a specific one I'd prefer to see it taken.

If we're talking about accessibility and assistive technologies, then CSS strikes me as a more plausible place to extend a specification, since a number of accessibility issues are handled there, for example with media types.

In short, I don't see how any of the proposals in this thread except the use of a data-scheme URI provides a general and properly-scoped solution.

Michael Wojcik
Technology Specialist, Micro Focus

From: mike amundsen [mailto:mamund@yahoo.com]
Sent: Monday, 28 April, 2014 03:09
To: Gerardo Capiel
Cc: uri@w3.org
Subject: Re: math: URI scheme and protocol handler

This is a great idea -- and the protocol element of URIs is not the correct vector for executing it.

IMO, the best place for this is as an element: <mathspeak>....</mathspeak>.

An alternative (atho more complex) would be to use the "rel" attribute of an HTML link: <a rel="mathspeak">...</a>

Just as "rel='stylesheet'" has a special meaning in browsers, rel="mathspeak" can be used as the launch for a browser plug-in that knows how to process math expressions. Another reason to use rel="mathspeak" (and not the protocol element of a link) is that the href value *could* be used to point to an external address that knows how to process "mathspeak" strings. IOW, you can support "mathspeak" speech internally (with a plug-in) or, if no plug-in is available, use the href to point to an available processor.


skype: mca.amundsen




On Mon, Apr 28, 2014 at 2:55 AM, Gerardo Capiel <gerardoc@benetech.org<mailto:gerardoc@benetech.org>> wrote:
I created a short YouTube video to demonstrate why a protocol handler with a math: URI scheme can provide an alternative and simple user experience for a blind or vision impaired user for exploring mathematical expressions.  In the video, 1) we turn on VoiceOver (the OS X screen reader / assistive technology), 2) we navigate a page that contains text and a mathematical expression, 3) we decide that we want to use another application other than Safari to explore and understand the math expression and click on the math expression which has an anchor tag around it (e.g., <a href="math:<math>something</math>">), 4) the operating system launches the application registered to handle math: protocol requests, 5) the application provides tools for exploring the math, 6) after using the application, the user quits the application and seamlessly returns back to the web browser where they left off.


I hope this helps to illustrate why a protocol handler provides a more seamless experience with the current state of browser implementations than a media type could today.


Gerardo Capiel
VP of Engineering

650-644-3405<tel:650-644-3405> - Twitter: @gcapiel<http://twitter.com/gcapiel> - GPG: 0x859F11C4
Fork, Code, Do Social Good: http://benetech.github.com/

Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam.

This message has been scanned for malware by Websense. www.websense.com
Received on Monday, 28 April 2014 13:50:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:16 UTC