(I should add, for the benefit of any Microsoft coders out there: if you don't get support MathML and SVG in IE right soon you'll end up displaying GIFS and loading klunky Adobemedia plugins when the rest of the world is dragging and dropping formulas and vectors, not to mention serving all this stuff inline
)
Should I get worried? Well, I know all this stuff, so no. Also, it is still easy to get started. You don't have to know HTTP to know HTML, which is the substrate upon which the rest is built.
Also, I would add that we've got these things for a reason: having played around with REST XML APIs + JavaScripting XSLT + CSS + XHTML, I have to say that this is a sweet combo that makes me emit an evil laugh everytime I do something ridiculously complex in ten lines of JavaScript.
Anyway, this leads me to the conclusion that a) dumping XML on the client for transformation is not intrinsically wrong, b) JSON-RPC is nice, c) passing HTML clips via XMLHttpRequest is not an ideal situation but works.
Also, despite me not working on Gradient for ages, I still believe that the web is missing a real-time control channel and the ability for clients to communicate more-or-less directly with each other, and that XMPP is the solution to that.
What's changed is that Firefox 1.5 supports SVG now... I'm thinking of digging up the old and obsolete JiM or fiddling with Mozchat and seeing if I can wire either of them directly into the DOM.
Posts
4 comments:
The idea that SVG and MathML support is lower class in IE because it comes in the form of a plugin is bogus. For example, SVG support in Mozilla is current well behind that of Adobe's plugin. So much so that Mozilla has seen fit to supply an "SVG Switcher" to allow users a choice of SVG engines.
IMHO, all software (commercial and open source) that can be made extensible should be made extensible. We embrace competition at the app level -- why not at the lower level of MathML and SVG engines?
Browser plugins have gotten a bad name because of the limitations of the old Netscape plugin model. This was a technical problem that could have been easily addressed and would have been if not for the browser wars.
BTW, our MathPlayer plugin for IE does a really good job of displaying MathML. Unlike Mozilla's builtin MathML support, it handles Content MathML and it interfaces with screen readers used by the visually disabled to actually speak the math.
Hi, thanks for commenting.
Firstly, I agree that all software should be extensible. My favourite examples are Firefox, Emacs, and Eclipse, although I can imagine that MS Office and IE also qualify.
Also, I took a look at MathPlayer and it does seem like a very nice plugin, kudos - I didn't have to install any extra fonts, as with FF.
As for plugin-based support for new markup dialects being lower-class, I should probably clarify what I meant. I wasn't referring to the quality of the spec implementation - as the FF SVG support shows - but to the market-share aspect, i.e plugins will never saturate the market unless they come installed with the browser like Flash. Until MathML and SVG get that level of support that they won't become ubiquitous.
What I meant to say is that this is more likely to happen when support is build directly into the browser instead of added on using a plugin.
- Ian
Actually, MathPlayer's installation added some fonts to your system. I believe the only reason Mozilla doesn't do this is that it made their browser download bigger than they wanted. Perhaps if MathML USE does really become ubiquitous they will reconsider. Same for Microsoft licensing our MathPlayer. In fact, they have licensed it to distribute with some content, as have a few other organizations.
For Mozilla it might also be a question of licensing. If the fonts (from an MIT website IIRC) come under a lilcense that's incompatible with the MPL/GPL/LGPL, they'd have to be distributed differently.
Post a Comment