Re: Math on the web without MathML

> > The problem with xml-stylesheet is that it will interfere with native
> > implementations, plugins and even UserJS and spoil rendering of MathML
> > in those UAs that are MathML aware,
> 
> well it interferes in the sense that it always activates, but it doesn't
> need to break native rendering. pmathml.xsl just passes everything
> through if running in mozilla for example, so you get mozilla's native
> rendering.

It was designed not to spoil rendering in Mozilla, but it is unlikely to
take into account future browsers. For example in Opera with UserJS you get either
XSLT processing error or some other not really pleasant result of interaction between 
UserJS trying to render MathML and author XSLT trying to provide fallback rendering. 
Tomorrow the same problem will affect Safari.


> the third method of configuring the server
> to serve different versions to different browsers

For example can you distinguish Opera, Opera with appropraite UserJS, Opera with TechExplorer plugin
on server side? You can't as usually MathML support or lack of such is not advertized in 
UA string and/or http header.


> 
> > Existing niche in XML + CSS framework does not need to be standardized
> > in order to work, it exists canonically).
> It only works canonically as far as rendering in a CSS engine goes. That
> was my point, you lose the benefits of using an agreed more widely
> implemented markup. MathML is usable in many places where css is not:
> maple, mathematica, openoffice (MS Word2007 as far as I understand,
> although I haven't been able to verify that).

XSL and DSSSL are another almost canonical options. CSS is more important for web, and in the same time
it imposes some restriction on markup (in XSL and DSSSL you have ability to transform markup
so they don't impose heavy requirements on markup) this is why special attention is payed 
to compatibility with CSS, and being compatible with CSS does not imply that other options does not exist. For XML MAIDEN native support is probably not an option as it is experimental 
markup that we don't plan to standardize, however in general native support could be one of the 
options (in addition to CSS, XSL and DSSSL approaches) for similar markup languages (for instance HTML5 math proposal, if it would not be rejected). In any case we are not responsible for faults on standards side and nor we are obliged to pay price for other's faults just because they were standardized.

> The CSS1 spec came out at the end of 1996, the MathML spec near
> the beginning of 1998;

They were prepared by the same organization (CSS2 was avilable in 1998 and provided the same functionality as we have today, MathML2 came out in 2001). In any case if W3C managed to allocate time to develop XHTML 1.1 Ruby module and CSS3 Ruby module are expected to complement each other, why you can't do the same with math markup and CSS and/or XSL counter parts? Is Ruby used in couple of countries is more important then math used around the world? Or is having control over positioning of Ruby annotations is more important then having control over rendering of math expressions?

Ruby may not be the right example in the sense that it introduces too many ad hoc properties and
as a result it is the only XHTML module which is not implemented in browsers, but it is good example in sense that it illustrates how (in theory) things are expected to work.

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

Received on Friday, 14 July 2006 16:21:40 UTC