- From: Dave Barton <dbarton@mathscribe.com>
- Date: Fri, 8 Feb 2013 12:06:03 -0800
- To: www-math@w3.org
- Message-Id: <EE106B53-3755-4C2D-A99C-C182B12B6D57@mathscribe.com>
I agree with all this. Here's how I see it: HTML has had text, images, and links since basically the beginning, so they're supported everywhere. If you want to add them to a web page, e-mail message, blog post, help page, wiki article, etc., they pretty much just work. The same now goes for tables, form elements, basic css, javascript, etc. Browser vendors now have a lot of developers working on things like CSS 3 modules, WebRTC, integration with mobile hardware, etc. There are also slightly older features like <canvas>. These newer things that aren't supported everywhere yet are often imitated to varying extents by javascript libraries, also known as "polyfills", "shims", or "shivs". (There are so many synonyms because it's such an important and common tool.) An early common example was excanvas, for imitating <canvas> on old IE. Meanwhile, some kind of <math> element has been around since the beginning, but has never really been fully supported. The excellent MathJax library does a lot of things. Like other polyfills, it's fine in itself for some purposes, and it's way better than nothing for all purposes, but it's definitely not the same as native browser support. We're hearing a lot about it because it's the only organized and actively funded <math> support today. Without getting sidetracked with MathJax details, the question is whether browsers should support a <math> tag natively, sooner rather than later. For instance, no one is suggesting that all browser vendors support music notation in their core engines. But mathematics is fundamental and extremely important, the basis of half of education and all of science and technology. Without it we wouldn't have modern life, and if (when) we make it easier to use it and grow it (through new research), the benefits to humanity will be enormous. This is why, as Paul points out, standards bodies such as HTML5 and EPUB3 have definitively answered this question. Math support, through MathML, is required. It's worth it; it's been approved; let's just do it. But what is the cost? The answer is that a fraction of a developer on each of the major browser engines - webkit, mozilla, trident/IE, and maybe Opera - would do it, far less than is being spent on other HTML5 technologies. This is the price to have formulas and equations (and ultimately many mathematical tools using them) "just work" on everything - digital textbooks, help sites like stack overflow, social sites like google+ or facebook, online tutoring, online journals, etc., etc. This is what I think we should pitch to everyone. If you think this is worth making happen now, instead of waiting another 15 years (seriously), please discuss and support this effort. For google+ users, I urge you to share either or both of these, or create your own post: https://plus.google.com/u/0/107847268022850354754/posts/Y3rNXYvFMaC https://plus.google.com/u/0/104139857168801904129/posts - the Feb 7 (yesterday) post If someone would write something on facebook, we could like or share that as well. Finally, please go to http://code.google.com/p/chromium/issues/detail?id=152430 and star it (in the upper left corner) if you haven't already. SIncerely, Dave Barton On Feb 8, 2013, at 9:26 AM, Paul Topping wrote: > I agree with all of this but it prompts me to make some additional points: > > While we might feel that we are “at the beginning of mathematics use on the web”, such words are not so great when making a campaign for MathML support as they imply that the revolution has yet to happen. It is the kind of thing that people say when they hope something will happen. As I argued earlier in this thread, it has already happened. MathML is in use in many places and is the de facto standard for representing mathematics. > > One way this kind of thinking can be used is to remind people that HTML5 is a standard that every browser maker has embraced and it is at the heart of EPUB3 ebook standards. Both of these standards are committed to by various communities and represent decisions that no one is going to go back on. Both standards include MathML. So any browser that doesn’t implement it eventually is not going to be fully HTML5-compliant. I mean this in a practical sense, not in the sense that a standards lawyer might mean it. If a browser says that it does HTML5, then that sets up expectations. As evidence, we see that many people thought that when browsers came out with HTML5 support that that automatically included MathML support since the standard implies that. They are a bit surprised to learn that browsers’ HTML5 implementations are not yet complete. We should use this in our arguments. Why don’t browser makers put effort into adding MathML support since they are committed to doing so and will have to do it eventually? > > MathML is an internal technology. Someday the only people that will know the term are programmers. People who work with mathematics on computers will only know see functionality that does the job, not its underlying standards. Right now we have to use the term “MathML” explicitly because it is all we have. But when talking to the communities that stand to benefit from this technology, such as education and accessibility, we should bear in mind that they are not interested in implementing standards but in benefitting from the technologies they enable. Choose your words carefully or risk sounding like a geek trying to push his/her favorite technology.
Received on Friday, 8 February 2013 20:06:34 UTC