[whatwg] Mathematics in HTML5

Ian Hickson wrote:
> Certainly. The question is how. There have been several proposals. My 
> recommendation to those who think it is possible to re-use CSS to get an 
> acceptable level of Math support would be to go through the Microformats 
> process to prove the case.

What is the difference between writing style sheet for microformat and
writing style sheet for XML based markup? There is no difference.

> It doesn't make sense to bless a dozen new tags (or more) to be in the 
> HTML namespace (and thus with us for all time!) 

Do you pay any fee for registered element names? ;)

> without first proving that 
> yes, that approach is good enough for mathematicians and scientists.

Is lack of mathematical markup in HTML good enough for mathematicians and scientists?
After many years there is no consensus in math community on issues whether
ISO 12083 is good enough, whether MathML is good enough, whether LaTeX is good enough
for web, whether SGML/DSSSL approach was good enough etc. 

> Stretchy glyphs are one example. You can do basic maths with CSS, sure. 
> It's the high-end typography that's the problem.

Yes, but when "p" element was included in HTML no one claimed that it is useless
or wrong just beacuse browsers did not support (and do not support today) hyphenation.
Structural markup is not responsible for typographical issues. We use HTML without
automated hyphenation, vertical text, ruby, combining diacritical marks, advanced text
justification, multicolumn printing, automated page numbering, automated resolution
of cross references and many other for some subtle and for some people important 
typographical features. What if before standardizing HTML one would wait until all
this issues would be perfectly addressed? We would have no HTML at all. Inspite of
the lack of typographical quality HTML played important role in organizing data and
providing structural markup, without this we would have just bunch of PDF files instead
of current web. Situation on math part is very similar, some people claim that 
markup is useless because some subtle typographical feature is missing 
(again, markup is not responsible for formatting quality), we have no structural 
markup, scientific web is turned into bunch of PDF, PS, DJVU, DVI and other format
that miss structural level, data is not organized.

> Note that the proposal to have Math in HTML in a way that can be rendered 
> using CSS is also a kind of presentational Math and not a pure-semantic 
> Math, so arguing that we shouldn't use p-MathML because it isn't semantic 
> would not be consistent with arguing we should be purely CSS-compatible.

Agree. Current proposal (like ISO 12083, AAP Math DTD, LaTeX) just captures
basic structure of math formulae in the way suitable for further formatting, processing etc.
It is about organizing and structuring formulae rather then encoding meaning which
is separate task that would be handled through content oriented attributes 
(approptriate semantic vocabulary will be developed separately from current proposal,
as it is complex issue that is orthogonal to current markup and is not relevan for
rendering mathematics in browsers).

> Given that <canvas> has been implemented in IE6, I have no worries that an 
> HTML-based Math markup language based on MathML (and creating a MathML 
> DOM) could be implemented in IE6 as well, if someone wanted to do so.

Thus no one wanted to do so?

> > simply by moving to XHTML) IN A GRADUAL FASHION."
> This was written when my opinion was still that we should be moving to 
> XHTML. I'm not actually sure we want to do that at all these days; most 
> Web developers seem to agree (there's almost no XHTML on the Web).
> However, integrating MathML into text/html would make this imminently 
> possible, since it would allow one to write a text/html-to-XML converter 
> that actually took HTML5 markup with Maths, and turned it into native 
> XHTML with MathML, etc.

If this is called gradual transition then in the same manner you can gradually
switch from LaTeX, ISO 12083 amnd anything else to XHTML. Just write convertor.

> > That's a really particular use case which is hardly representative of 
> > the web as a whole. As sad as it is, 99.9% of authors have no use for 
> > maths (otherwise all these problems would have been solved long ago). 
> > Maths is certainly less of a core feature for most authors than vector 
> > graphics and WHATWG aren't trying to re-implement SVG despite the fact 
> > that it too has no obvious IE6 compatibility story, poor CSS integration 
> > and various other problems.
> > 
> > Nowhere in the WHATWG document does it say that they're going to try and 
> > fix everything. You have to choose your battles and, personally, I agree 
> > with the idea that, if the proponents of CSS-based maths want to work in 
> > the structure of the WHATWG, they should demonstrate the feasibility of 
> > their approach using a microformat. Given the constraints under which 
> > they have chosen to operate it should be possible to do this without any 
> > difficulties. The microformat based approach has several advantages too, 
> > e.g. instant implementation in existing HTML4 UAs (a new markup language 
> > would require changes to the parser). This should allow the language to 
> > evolve as it encounters real-world needs so, if and when it is formally 
> > standardized, it will be a better product than typically results from an 
> > standardization-before-implementation approach.
> As usual, James has managed to express himself much better than I can. I 
> completely agree with what he writes above.

In other words math proposal is rejected, mathematics in HTML is blocked one more time. 
Mathematicians are kindly asked to use microformats, SVG or whatever else they find appropriate. 
As we see lack of browser side support is not the reason for lack of mathematical markup in HTML,
as even something that can be rendered in browsers via CSS is rejected. Many thanks.

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

Powered by Outblaze

Received on Sunday, 18 June 2006 01:40:51 UTC