- From: <juanrgonzaleza@canonicalscience.com>
- Date: Mon, 19 Jun 2006 07:25:10 -0700 (PDT)

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