[whatwg] Mathematics in HTML5

James Graham wrote:
>
> Except that XML will not work with HTML4.

XML => SVG therefore

"Except that SVG will not work with HTML4."

[http://www.carto.net/papers/svg/samples/svg_html.shtml]

[http://www.december.com/html/tech/svg.html]

[http://www.december.com/html/demo/hellosvg.html]

> One of the big difficulties
> with MathML is that XML is /too hard/ for authors.
> That's why WHATWG has
>  spent so much effort designing a backwards-compatible HTML parsing
> algorithm with predefined error handling - because authors cannot
> migrate to XML based solutions.

That is not the main reason of lack of popularity of MathML. Forcing
authoring of MathML in HTML will continue with current unpleasant
situation for mathematical and scientific content.

>> However it matters for usability, readability and authoring purposes.
>
> Indeed. If you require documents to be well formed XML authors will not
> use your technology.

How authors could avoid well-formed MathML fragments when authoring from
HTML? Would <none> be valid code in HTML5 or still XML rules matter and
authors will be write <none/> with independence of host language?

>> So sending us to microformats.org is basically saying that it is not
>> worth to allocate separate element names for maths.
>
> At this point I would certainly agree with that sentiment, at least at
> present. I would certainly change my mind in the future, if you could
> demonstrate high quality typesetting of mathematics with a range broad
> enough to satisfy professional mathematicians.

This is odd.

1) It has been proven that via Standard CSS 2.1 not designed for math one
can render math better than browsers with native support (as Firefox 1.0)
and infinitely better than MSIE, Safari, and Opera (rendering natively
zero mathml).

2) Mathematics is not a niche exclusive for professional mathematicians.
That is reason of the lack of popularity of TeX and amstex. In chemistry,
most part of the comunity does not use TeX or LaTeX, and even physical
chemists usually do not work with TeX for typesseting of mathematical
formulae. Most of scientists in biology, geology, environmental sciences,
enginnering, feel confortable with MSWord typesseting.

3) HTML was designed for high-quality typesetting of nothing: text, math,
chemistry, graphics, etc. The web is not about high quality typesetting is
about electronic communication and dinamical content. MathML and OpenMath
were not designed for high-quality typesetting.

Not even XML or SGML were designed for high-quality typesetting (XSL-FO
even is not designed for that). Usual practice in MathML for instance is
previous transformation to TeX before printing.

>
> That's not a convincing case for putting everything in HTML5 today -
> it's much easier to pick up new ideas later once they have some proven
> success than it is to drop stillborn markup which was believed to be
> good at the time but failed to solve real world problems. A microformat
> for HTML 4 (and even your own XML dialect in its own namespace for
> XHTML) seem like the ideal solution as it allows you to develop a
> standard but does not add dozens elements from an unproven technology to
>  HTML 5.

This philosophy was not applied to the rest of HTML5 spec, no?


Ian Hickson wrote:
>
> On Sun, 18 Jun 2006, White Lynx wrote:
>
>> Do you pay any fee for registered element names? ;)
>
> Yes.
>
> It takes a couple of engineers to implement a new tag, typically, and
> probably on average takes them about a week (forty hours). (Some tags
> take  months and many engineers, some take minutes for one engineer.) It
> takes  about a week also for a QA person to write tests for a new
> element, then  another week or two over the next few years to handle
> bugs in that element  (again, on average). Let's say a hundred hours.
> Documentation probably  takes about three days (twenty four hours).
>
> So that's an average time of 204 man-hours per browser. There are at
> least  ten browsers in active development, probably more. So that's 2040
> hours.
>
> It takes about ten to twenty hours for a spec editor to write the spec,
> plus an hour for people to review it. Let's be pessimistic and say that
> a  hundred people review the spec (for something like HTML, it's
> probably in  the thousands really). That's a total time of about 115
> man-hours for the  spec.
>
> It probably takes a dozen people about an hour each to report on the new
>  element, plus about another dozen people about an hour to write a
> tutorial  for the feature, assuming it's a simple feature. 24 man-hours.
>
> Finally, it takes Web developers a few minutes to read about the tag and
>  see if they care or not. Assuming that they don't care (if they do,
> it'll  take them much longer), it probably takes an average of one
> minute per  developer to read the spec or article about the feature.
> Let's assume that  sixty thousand developers look at the feature. That's
> 1000 man-hours.
>
> Assuming that the people involved value their time at an average of $10
> per hour, that's 3179 man-hours at $10 each, so $31,790 per element
> name.
>
> These are of course back-of-the-envelope calculations. But hopefully my
> point is clear: we have to be confident that a tag name is worth it
> before  adding it to the spec.

Strange calculations. Take a few dozens of enginners and programmers and
ask they:

What do you prefer to implement tomorrow in your favourite browser?

a) Dozen or so of simple elements as <frac>, <num>, <op> with default
rendering already specified via CSS 2.1 (therefore one simply copy and
paste CSS fragment for the layour engine and adds a bit of finetuning to
the whole code) and a bunch of very simple new attributes such as role and
others, reusing all available code and experience on CSS, HTML, WSparsers,
and DOM or

Implementation of future Math-CSS module improving rendering.

b) Implementation of thousands of p-MathML + c-MathML + OpenMath
extensions (two latter needed for accesibility issues, but uneeded in
George approach because the special aural design)

Implementation of new WS model, implementation of new parser mode (e.g.
collapsing certain <mrow> nodes).

More implementation of MathML-DOM. More implementation of MathML-style
attributes and <mstyle> element.

More implementation of font metrics for CM. Would need of further
implementation for each collection of fonts! For example you would update
the rendering engine for the future STIXs.

Implementation of future MathML-CSS special module doing deprecated most
of p-MathML code implemented today. Do not forget that pure p-MathML is
harmful and contrary to web design of HTML.

Implementation of special add-ons to XSL-FO for math (since p-MathML does
not correctly integrate with XSL-FO).

More implementation of a new syntax (Ian?s one) more implementation of a
new parsing mode (Ian?s proposal) backward incompatible with HTML, XML,
and MathML.

>
>> Is lack of mathematical markup in HTML good enough for mathematicians
>> and scientists?
>
> Apparently, GIF images for equations are "good enough", yes, otherwise
> people wouldn't be using HTML for mathematical subjects, which they are.

Then why <canvas>?

>
>> > 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 [...]
>
> I was asked for examples of what your proposal couldn't do. I was just
> providing examples. I'm glad you agree that your solution can't do
> everything that MathML (for instance) can do.

I have rencently provided examples that MathML cannot do even in theory.
Moreover, in practice situation for MathML is still poor. I provided many
examples of realistic MathML code is being served in the internet that is
best rendered (both aural and visually) when one relies on George
proposal. I am preparing a serie of docs for canonical science today,
including snapshoots of incorrect "stretchy glyphs" from MathML browser.

A pair of extensions to CSS and good unicode fonts (becoming) and I
believe CSS approach would not has competitor.

>
> The difference is that HTML5-with-MathML and XHTML5-with-MathML would
> have  the identical same DOM, same rendering, same everything.

Same inaccesibility, same incorrect structures are being spreaded over the
net, same limitations to scripts structures, same CSS and DOM
incompatibility, incorrect visual rendering in some cases, same incorrect
printing, same verbosity and redundancy of code, same special parsing,
same WS rules.

And if following your proposal one would add new parsing rules and a
different WS model is incompatible with MathML one.

> Only the
> serialisation is different. It actually would be true MathML, just with
> a  (slightly) different syntax.

Except that your proposal is not MathML compatible because your <mrow>,
for instance, is not MathML <mrow>. Somewhat as

This is a line

This is another

One find in some forum boards is not html

<p>This is a line</p>
<p>This is another</p>

A similar sintaxis -CanonMath- your one was rudely rejected by MathML
authors as Carlisle and others, even when my approach worked in current
MathML browsers with zero hours per enginner (only XSLT support was
needed).

>> In other words math proposal is rejected, mathematics in HTML is
>> blocked  one more time.
>
> I have suggested a process by which you could prove your proposal would
> work. That is hardly a rejection.
>

Some people can read between lines.

>> Mathematicians are kindly asked to use microformats, SVG or whatever
>> else they find appropriate.
>
> Mathematicians have asked me to put MathML in HTML5.

Most of people is rejecting MathML. Many mathematicians are not finding
MathML interesting enough for "updating", somewhat as TeX users are
ignoring XSL-FO for printing.

Moreover, here many people agreed with George proposal and several wait
for this kind of approach in final draft. They ask you for not put MathML.

What is more, outside from the mathematical community, CSS and DOM
developers probably would say you NO for MathML.

> You will note that I have not put MathML into HTML5 either. I would like
> a  better idea of whether that approach would work too, before following
> up  on it.

That is great! Different proposals would compete in equality of
oportunities and people would choose the best one: cheap but powerful
enough.

> The same applies to any proposal; MathML has at least a
> proven implementation that shows that it can be implemented (to at
> least the same  degree as HTML itself), and that shows that it can be
> done within DOM- and  CSS-based browsers.

In rigor also TeX can be implemented in a browser (IBM did) but was not
really working and that kind of approach was abandoned for online math.
MathML also has been (at least partially) implemented in a single browser
but is not working and in next decade probably we remember that browser
with native MathML support like today we remember the old IBM browser with
native TeX support.


Juan R.

Center for CANONICAL |SCIENCE)

Received on Monday, 19 June 2006 07:25:10 UTC