From: Ian Hickson <ian@hixie.ch>

Date: Mon, 19 Jun 2006 07:20:25 +0000 (UTC)

Message-ID: <Pine.LNX.4.62.0606190621480.4826@dhalsim.dreamhost.com>

Date: Mon, 19 Jun 2006 07:20:25 +0000 (UTC)

Message-ID: <Pine.LNX.4.62.0606190621480.4826@dhalsim.dreamhost.com>

On Sun, 18 Jun 2006, White Lynx wrote: > > 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. Sorry, I wasn't clear. I meant going the Microformats *process*, not necessarily "writing style sheet for microformat". It can be based on XML if that is what the Microformats process shows is best. The point is to show the maturity of your proposal before it is put into HTML, because of the next point: > > 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? ;) 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. > 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. Naturally, I agree that things could be better -- and indeed a number of solutions have been developed to address this (at huge cost to the industry, I should point out). It is not clear to me that your draft proposal is better than these existing solutions, and it isn't clear to me that it is a good idea to throw out those solutions. > > 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. > > 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? We haven't specced out such a solution yet. I was just pointing out that the solution of putting MathML into HTML5 was not incompatible with the requirements of HTML5 working in IE6. > > 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. The difference is that HTML5-with-MathML and XHTML5-with-MathML would have the identical same DOM, same rendering, same everything. Only the serialisation is different. It actually would be true MathML, just with a (slightly) different syntax. A LaTeX-to-XHTML convertor would not have that property. In any case this is a straw man; as I pointed out, it is no longer clear that the requirement in question stands. > 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. > Mathematicians are kindly asked to use microformats, SVG or whatever > else they find appropriate. Mathematicians have asked me to put MathML in HTML5. > 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. Math is no different in this than any other feature. We have to be pragmatic here. Your claim that your proposal is adequate for rendering maths is unsubstantiated; I have suggested a process by which you could show that it is true. The same process is being required of at least two other features (namely, how to encode personal data into HTML documents and how to encode event data into HTML documents), both of which have demand that FAR outstrips the demand for mathematical markup. 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. 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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'Received on Monday, 19 June 2006 00:20:25 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 13 April 2015 23:08:27 UTC
*