- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Mon, 29 May 2006 22:56:16 +0300
Hello! First of all, I'd like to make it clear I am not an expert, not even a user, of MathML, (La)TeX(ML) nor of other math-related technologies. However, I am a daily user of Mathematica application for pure presentational purposes (I need to write mathematical documents with nicely rendered fractions, radicals, whatever). I am also a web developer with a keen interest for web standads and semantical markup (I know xHTML, CSS, JS, DOM, RSS, Atom, etc). Therefore, please bare with me. Thanks. I haven't joined the discussion until now because I was too busy. Yes, MathML is not perfect, and for that matter neither HTML is. From the perspective of a "presentational MathML" user I can say I'd be very interested in being able to save my documents as MathML or any other standards-based format implemented in current major and serious user agents (Opera and Gecko - I myself don't consider IE serious). I am currently using only Mathematica Notebook documents because MathML is not supported by Opera and Gecko's support is not something I consider awesome. I personally don't even care about the fact MathML code is inefficient since I am not even going to manually write that code. I am not saying this is not a problem, yes it is, but not from my POV. If I'd like to manually write math code I'd use LaTeX. The point I am trying to make is HTML tables are highly inefficient, and might I add, stupidly used, for designing layouts. Against all this, they are used for years already by developers. Why? If they'd write the code manually, they'd hate using tables. Same goes for MathML and other markup languages (like SVG). A different take: Good-enough implementations for MathML would probably make-up for some of the bad things in MathML. If implementors can reach an agreement together, they could even break the current MathML. If their new ideas would prove good, then be sure the W3C will include those changes. I find interesting the fact XmlHttpRequest is now being defined in a new working draft specification by W3C. It was first implemented by IE. Also, <canvas> which was first implemented by Safari is now getting more and more attention. Why not do the same with math-related markup languages? Implementors should do whatever it takes to get things done, to get things working, if the W3C is refusing to do that. Another different take: If LaTeX is considered to be the best available language for writing mathematical scientific documents, and the best for printing too... why not have user agents implement it? Le Fri, 26 May 2006 16:58:41 +0300, <juanrgonzaleza at canonicalscience.com> a ?crit: > I have read with great interest this program and I would recommend > reconsideration of the role of mathematical markup in HTML5. But I would > first explain a my position. Initially, I began believing that web > authoring was "save as" command in Mword. Next I begin to work with a > real > HTML tool and discovered the XML world just next. Same here, more or less. > I see with terror how people has been > criticizing "old" table-layout gigantic pages filled with presentational > <center>, <b>, and <font> whereas now it is "in" to server to clients a > giant SVG archive with lot of presentational tags simulating tables, > paragraphs... > > More headaches became from the XHTML part, specially incompatibilities > with browsers and search engines, the nightmare of MIMEs, and others. > Finally I abandoned... I'm glad now authors are no longer using presentational HTML tags (such as font, b, i, tables, etc). As for SVG, this is an entirely different story. > But biggest error was try to use MathML. MathML is full of incorrect > design options and technical holes! Even some MathML author recognizes > that content MathML was not "well thought" due to lack of agreement on > the > committee. You entirely dislike MathML. What do you think of OpenMath? Make your own proposal. Which is the currently available standard you'd like implemented? None? I'd be interested of your Canon (Markup Language). > 1) Insanely complicated and inefficient. In some cases, I have computed > 15 > times more bandwidth and server storage when using MathML than > alternatives. Bandwidth is becoming more and more less of a problem. Hard disk space is not close to a problem, since it's cheap and everybody who's serious about working with lots of data has terabytes storage. I myself have close to a TB, and I am not doing anything too special. Thing is, are we going to stop using HTML because it's not good enough? No. As for alternatives to MathML, be sure they've got their set of weaknesses. MathML shouldn't be trashed just because some people don't like it. The specification didn't just reach recommendation suddenly, without receiving any positive appreciation and implementations. > The points "Users should not be exposed to authoring errors" and > "Device-specific profiling should be avoided" are also violated by > MathML. > For example, rendering of MathML in Firefox is based in specific fonts > may > be downloaded and installed. This has been disapproved. One of problems > with this approach is that once new STIX fonts available I can use them > in > HTML, also in CSS rendering of math, but I cannot use them in firefox, > since MathML module would be rewritten, and the full engine recompiled, > obligating to users to download and install new versions of browser for > new fonts!!! IMHO, a good implementation for any math-related web technology must not ask the user to download fonts, to install some plugin or anything similar. I do not like Gecko for the fact it asks me to download mathematical fonts. It should just do as Opera does with their voice interactivity module: it asks for permission to download the required files for that specific functionality. It does automatically download and install everything required. Same should be done by Gecko. > 7) The possibility for automated searches of math continues being largely > a myth. I can search E=mc2 in Google today when formula is encoded in > HTML > 4 and it works reasonably well, but how would I search the formula in a > MathML search engine? Your site mentions Dr. Michael Kohlhase. In regards to semantic search engines I'd like to show you something very specific: Math WebSearch - A semantic search engine http://search.mathweb.org/ http://kwarc.eecs.iu-bremen.de/software/mmlsearch/ I'm not sure if searching math is entirely a myth. This is a recent guided research project done by a student of Dr. Kohlhase. > ************************************** > Proposals (from less to more radical): > > A) Eliminate next text from specification > > "Authors are encouraged to use MathML for marking up mathematics" > > because authors would use more concise powerful and solid markup for > mathematics. I don't agree because authors would just use images with no alternate text or... they'd even give up adding math to their page. If they don't, they'll find a way to use a WYSIWYG editor to generate the borked HTML code that looks "perfect" in IE & FF. > B) Add special math attribute can be used in structural markup. For > example math="num" would be equivalent to class="num", but using math= > specific attribute. You can also use the class attribute for other tasks. > This could be solved if space attributes (2.2.7) are implemented. I don't like this either. I'd suggest creating a microformat defining a profile which assigns meanings to various well-thought class names. This would be backwards compatible and could aid with using CSS for styling in browsers with no support for the microformat. http://whatwg.org/specs/web-apps/current-work/#profile This woould be similar to what George is doing now with CSS, but with the added bonus of support from the user agent which can help with advanced things not possible right now only with CSS. > C) A more complete approach is providing a set of structural and/or > semantic tags for usage with HTML5. Mathematics is a field which is very complex and you cannot dream of a simple solution for displaying advanced scientific documents. -- http://www.robodesign.ro ROBO Design - We bring you the future
Received on Monday, 29 May 2006 12:56:16 UTC