Re: SVG and MathML in text/html

On Tue, 11 Mar 2008, Sam Ruby wrote:
> 
> The thread started promising with a specific set of use cases and 
> technical requirements provided by you.  I made a suggestion that we 
> factor in what we know about MS IE.  What would be required for fleshing 
> out that set of technical requirements to make it suitable for input to 
> the editors?

The main thing I would like to see is the use cases themselves fleshed 
out.


> I continue to believe that the use cases are broad enough that, once 
> addressed, we will be able to determine how (or if) additional 
> vocabularies could be handled.  If I'm wrong, and we can't, we still 
> have something useful.  If I'm right, but there are no additional 
> vocabularies, we still have something useful.

Right now the use cases I've seen described are actually pretty limited in 
scope. A few people have suggested some, mainly Henri. His were basically 
(summarising from [1]):

 * Convert LaTeX to text/html faithfully without bitmapping.

 * Hand-writing HTML with inlined vector graphics fragments from Inkscape.

 * Mirror the Flash workflow but with HTML and open standards.

 * Publish maths using XML-unaware PHP.

[1] http://lists.w3.org/Archives/Public/public-html/2008Mar/0039.html


These translate into these requirements:

 * Embed typographically faithful mathematics in text/html.
    - Do not require page-fatal error handling for errors in the maths.

 * Add vector graphics markup and related APIs to text/html.
    - Ensure all the graphics standards are open.
    - Allow copy/paste from vector graphics programs today.

These requirements can be solved in ways that really have nothing to do 
with namespace syntax.

For example, the first could be solved by a careful introduction of a 
subset of MathML into the text/html parser spec, with defined handling of 
implied elements so that, e.g., <mrow> elements can be omitted in the same 
way that <tbody> elements can be omitted, and end tags could all be made 
optional without loss of precision.

It could _also_ be handled by just having a <latex> element that takes 
embedded LaTeX and renders it inline.

Similarly, the second requirement could be handled by a careful listing of 
some SVG elements and how to handle them, with custom error handling to 
handle common problems. It could also be handled by a careful study of the 
output from widespread vector graphics programs to make the parser handle 
the syntax that they require us to support. Maybe we can even solve it 
without using SVG at all, but by supporting the output of some common 
graphics program directly, after specifying it.


My point is not to support any of the above suggestions. My point is that 
there are use cases other than Henri's. For example, while writing this 
e-mail, Henri suggested another use case would be the ability to 
individually style subparts of math expressions. This would, given the Web 
platform, imply using some sort of DOM along with CSS, which precludes 
using LaTeX directly.


What would be most useful at this point is more discussion on the use 
cases. That is, what workflows do people want to see enabled? What is it 
you want to do that you can't do today?

As a general rule I recommend avoiding referring to specific technologies 
in such use cases. For example, "I want to embed well-formed XML in 
text/html" is not a use case. "I want to be able to guarantee that my 
text/html markup will render unless it has no syntax errors" is a use case 
(though a mighty odd one). "I want to be able to copy and paste markup 
from text/html documents to and from my data store, which is currently 
using SVG, MathML, and XHTML2" is a valid use case (though it might 
require changes to XML, rather than to HTML).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 11 March 2008 20:24:35 UTC