[whatwg] Mathematics in HTML5

Michel Fortin wrote:
> What Juan propose, about adding a limited number of elements to HTML  
> for maths, actually makes sense to me, especially if you can get not- 
> too-bad results with CSS. HTML is designed to be easy to learn and  
> write; if we had a markup like that for mathematics which integrates  
> easily in HTML it'd be much more used than MathML, I'm sure.
One may argue that ISO 12083 was simple, easy to learn and easy to use
but still unpopular in math community, however today when web standards
are much more widely used, having simple mathematical markup similar to ISO 12083 
would be much more useful.
> But I think it would be better to develop that as a microformat[1]  
> first, then, once it works and is well defined, see if the WhatWG is  
> interested in integrating the microformat into HTML5 by giving it  
> specific elements and attributes.
On technical level I don't see the difference between developing microformat
and XML application, it is just a matter of notations.

Henri Sivonen wrote:
> I said that math needs to integrate with the surrounding prose. I did  
> not say that MathML is integrated right. The point was mainly that  
> there needs to be an XML syntax rendered by the same engine as the  
> prose--or at minimum the renderers need to communicate the baseline  
> and line breaking--and rendering math as a replaced element (possibly  
> using a totally non-XML syntax) is not good enough.
Completely agree.

>> Moreover, the MAIDEN markup can be transformed to TeX for printing  
>> via TeX
>> engines whereas better CSS-based printed engines are not ready.
> I found the XSLT program but are there examples of results on the Web?
Here is example: http://geocities.com/chavchan/tex
(uploaded today). Also the purpose was not prining quality (that can be achived in XML + CSS framework using Prince formatter), but to make LaTeX versions of XML articles suitable for submission to journals that as you know do not accept XML.


James Graham wrote:
> The problem is that it's not nearly so easy to do as he suggests. 
In any case it is worth to do.
> Look 
> at the test page - some of the rendering is awful (the radical signs in 
> particular stand out here). 
Don't like default style sheet? Write better one ;)

> And, despite being sold as a simpler 
> solution than a MathML implementation, it works in about 1% of UAs (by 
> number of users) compared to > 95% that have a story for native or 
> plugin-based MathML. 
I know many people that would be very glad if MSIE's share would be below 1% (we have appropriate XSLT style sheet for MSIE)
and 95% of users would have browser with MathML support (native or plugin installed).

> The language that they have used is also overly 
> simplistic. For example one would expect most text in a formula to be in 
> italics except where actual words were being used in which case the text 
> should be roman. So you need an additional element to distinguish text 
> from ordinary numbers. 
You don't need additional element. For those interested in shaping, there are appropriate 
characters in Unicode plane 1:
	http://www.unicode.org/reports/tr25/

I think the following could be technically feasible:
>   1) Author writes iTeX code as the text content of an <f> element  
> for inline formulae (and <df> for display formulae; two elements to  
> cut down on verbosity of attributes).
>   2) The browser takes the textContent of the <f> element and the  
> computed style for the list of fonts, the text color and the font size.
>   3) The browser feeds this data to a sandboxed, pruned and heavily  
> macro-deprived pdfLaTeX engine that renders the formula using the  
> font properties as if the formula was a $...$ formula on an infinite  
> line. (This means that line breaks cannot occur in formulae. Consider  
> this a good enough approach for feasibility.)
>   4) The pdfLaTeX engine hands back a PDF with a bounding box  
> indicating the bounds of the rendering and the position of the baseline.
>   5) The browser's CSS formatter replaces the box of the <f> element  
> with a replaced element box of the size of the PDF bounding box and  
> aligns the baseline of the replacement box with the baseline of the  
> surrounding CSS line box.
>   6) When it is time to draw, the browser draws the drawing  
> operations encapsulated in the PDF into its underlying vector  
> graphics pipeline.
> 
> Obviously, architecturally this would be a departure from DOM and  
> CSS, but it could work. And because I guess the implementation would  
> take more than a couple of days, I am not volunteering to prototype  
> this. :-)

W3C already done excellent work to take mathematics outside XML + CSS framework,
it is not necessary to make further steps in that direction. 

Anne van Kesteren wrote:
> As far as I know, working for Opera, we never made an official  
> statement regarding MathML. I tried looking one up:
>   http://www.google.com/search?q=site%3Aopera.com+mathml
> ... didn't work out. Then again, I'm also unaware of an "Opera browser  
> developers site" :-)
Juan probably meant Mark Schenk's article from my.opera.com developers corner
	http://my.opera.com/community/dev/articles/20030519/
But it is not necessary to be developer in order to understand
that implementing CSS incompatible stuff in CSS rendering engine is not a big pleasure.

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Received on Friday, 2 June 2006 02:06:07 UTC