Shelley Powers: Microsoft is asking us to declare our intentions, it’s only fair we ask the same of it. If Microsoft won’t meet us half-way–if the company releases IE8 without support for the HTML5 DOCTYPE or XHTML, and without at least some guarantee as to when we’ll see SVG in IE–then we’ll have our answer. It may not be the answer we want, but it will be the answer we need.

If Microsoft were to declare that the following were to be treated as equivalent, then a lot of the concerns expressed by the web community were to go away:

Support for application/xhtml+xml and SVG, too. The HTML5 DOCTYPE by itself isn’t enough.

I’m also not sure that Chris Wilson wants to continue the rumblings that Microsoft is so small minded and petty that it would fire its standards people just because corporate intranets are hard coded to a crappy browser (IE6).

That’s what I intended by my statement that with an edge mode idea in place, there really is no need for XHTML support to wait. Perhaps I should have been more clear.

and SVG, too

Obviously Jacques would want to see MathML too. Where I may differ with you is that having those markup grammars be made available as a plugin would be sufficient for me.

I’ve found Ruby to be a cryptic language from time to time. Thanks for clarification.

“Obviously Jacques would want to see MathML too.”

I should have added that into my post. Jacques will never forgive me.

“Where I may differ with you is that having those markup grammars be made available as a plugin would be sufficient for me.”

Not enough for me. Silverlight is not ubiquitous enough, like Flash, that we can depend on most people having a plug-in for it installed. Other browsers have built-in support for SVG and they’re not falling through the ground, groaning under the weight of support.

There already are plugins for both SVG and MathML support in Internet Explorer.

Ubiquity of installation is not the issue. If people are sufficiently interested in your content, they’ll install the requisite plugin. (Indeed, I understand that Microsoft bundles the MathPlayer plugin with their Encarta product. So they, at least, understand that there is a market which needs the ability to render MathML.)

As I pointed out in this comment, the issue is mixed-markup. No combination of plugins will be able to render the content on those pages.

That’s the real argument for native support.

But, hey, if we’re going to talk about native support for MathML in IE, we should acknowledge that neither Opera nor WebKit has MathML support, nor any serious plans for obtaining it.

If we’re going to be fair about this, we should be getting on their cases, too.

neither Opera nor WebKit has MathML support, nor any serious plans for obtaining it. If we’re going to be fair about this, we should be getting on their cases, too.

I realize that is but a small gesture, but I went ahead and added myself to the cc list for this bug.

Lots of continued discussion about Internet Explorer and Microsoft’s support of web standards. Sam Ruby continues to finesse his SVG-via-Silverlight solution (improvement: use createElement() and then some XSLT to transform from SVG’s...

But, hey, if we’re going to talk about native support for MathML in IE, we should acknowledge that neither Opera nor WebKit has MathML support, nor any serious plans for obtaining it.

I must be missing something here. Isn’t this the kind of MathML support you are asking for?

I must be missing something here. Isn’t this the kind of MathML support you are asking for?

Actually, no.

Apparently, the Opera plan is to come up with some quixotic "profile" of MathML, whose only rationale is that it can be implemented via a CSS stylesheet.

Compare (just as an example) the profile for multiscripts versus MathML. Among the things unsupported in the Opera “profile” are the symbols for the hypergeometric function, and for the Riemann tensor:

Most of the pages on my blog do not conform to Opera’s profile, nor could they, without eviscerating the meaning of the equations.

Moreover, even the extent to which Opera’s stylesheet does support some subset of MathML is heavily reliant on “extensions”, like allowing SVG background images in CSS. And that has its own issues.

Moreover, even the extent to which Opera’s stylesheet does support some subset of MathML is heavily reliant on “extensions”, like allowing SVG background images in CSS. And that has its own issues.

Actually the only issue there was that older versions of Opera 9.50 allowed script execution in svg:foreignObjects included in a svg background image. That has been fixed (tested in the current weekly build of Opera 9.50 [build 9755], winxp). The “extension” you talk about is actually a rather nice way of using SVG, and has nothing whatsoever to do with MathML itself. The svg as CSS background feature can be used to do some things that are hard to do well with raster images.

Regarding rationale, mathematical formulae participate in normal flow and share quite a few properties with environment. MathML is supposed to be embedded in web pages where formatting is mostly specified in terms of CSS and one has to think about how it is supposed to work in CSS environment (by the way the same profile can work with other style languages, for example it can be transformed to XSL FO if necessary, so it is not that much CSS specific as its name might suggest). In addition, when you are able to reuse style language in math context you don’t need to have separate rendering engine for MathML and you gain extra functionality that otherwise is not present in MathML (automated equation numbering for example).

Regarding mmultiscripts examples, generally speaking I know more languages that does not support mmultiscripts construction then those that do support it. Widespread examples are LaTeX where you need to use special package(s) to be able to mark mmultiscripts in the way you structured them above and ECMA OMML used in M$ Office that has exactly the same limitation as CSS profile. As to particular examples quoted above, first is marginal, I doubt you use it anywhere, at least it is quite difficult to find any examples in mathematics or physics that would require mixing prescripts with tensor indices. Second case is more common of course, but it is doable in basic profile using msubsup schemata.

Regarding SVG, we reuse it only for drawing fences/radicals and it is a temporarily solution that might later be replaced with something else.

Actually the only issue there was that older versions of Opera 9.50 allowed script execution in svg:foreignObjects included in a svg background image.

And that was the only hole which allowed script execution ... right?

In addition, when you are able to reuse style language in math context you don’t need to have separate rendering engine for MathML and you gain extra functionality that otherwise is not present in MathML (automated equation numbering for example).

I’m not sure what is being contrasted here.

Gecko’s MathML rendering is not done in a “separate rendering engine.” Embedded MathML, as rendered in Gecko, is stylable using CSS, manipulable in the DOM, etc.

As to equation numbering. The element envisioned, by the MathML Spec, for carrying equation number is mlabeledtr, which is not supported either by Gecko, or by Opera’s profile. So the method for automatic equation numbering in itex2MML is a bit of a kludge, but is very convenient in practice.

If you’re talking about getting automatic equation numbering via CSS generated-content, I don’t see how that would be useful to anyone.

As to particular examples quoted above, first is marginal, I doubt you use it anywhere, at least it is quite difficult to find any examples in mathematics or physics that would require mixing prescripts with tensor indices.

Huh? The standard symbol for hypergeometric functions is "marginal."?!?!

In real mathematics, mixing prescripts with sub/superscripts is as common as dirt.

Second case is more common of course, but it is doable in basic profile using msubsup schemata.

Could you suggest the markup to be used? Could you say how assistive technology (like MathPlayer’s MathML-to-speech facility) would handle your suggested markup (versus the one using mmultiscripts)?

I assume there should be some difference as you find one approach perfectly usable and another completely useless.

Huh? The standard symbol for hypergeometric functions is "marginal."?!?!

Yep, in the sense that it is not common enough to justify costs of including complicated mmultiscripts construction in CSS profile. And in this respect there is nothing unique in CSS profile, indices in ECMA OMML have exactly the same content model, handling of indices in LaTeX is another relevant example. In any case if there was any layout schemata that had to be simplified to make MathML easier to render with CSS, that was first of all mmultiscripts construction.

In real mathematics, mixing prescripts with sub/superscripts is as common as dirt.

Which maps to 0.01% of existing content or what?

How about an example from chemistry

There is a lot of stuff used in chemistry that is not considered to be in the scope of presentational MathML.

So are commutative diagrams that are ubiquitous in algebra/topology and yet are not covered by presentational MathML and elementary math notations that were not available in MathML 2.0 and are being added only now.

(there are other options too, like using mphantom or mspace instead of Unicode spaces)

Could you say how assistive technology (like MathPlayer’s MathML-to-speech facility)
would handle your suggested markup (versus the one using mmultiscripts)?

You are reallyseriously suggesting using ASCII Art to denote tensors? (That is, rearrange the tensor indices at will, and then use spaces to fake out the appearance of putting them in the right order.)

Of course that won’t work in MathPlayer’s MathML-to-speech, or anything else which assumes any semantics to MathML.

If you’re going to advocate that, why even bother with MathML at all. Let’s just go back to putting up GIF pictures of our equations.

Yep, in the sense that it is not common enough to justify costs of including complicated mmultiscripts construction in CSS profile.

Which is what’s really going on here.

Anything that can’t be faked out using CSS must not be “common enough” to be worried about.

For those trying to follow along, this is the equivalent of Microsoft deciding that Sam’s trick of mapping some subset of SVG to SilverLight is “good enough”, and that anything not covered by Sam’s transformation is not “common enough” to be worth bothering with.

In real mathematics, mixing prescripts with sub/superscripts is as common as dirt.

Which maps to 0.01% of existing content or what?

Pretty much describes all of MathML.

If your position is that Math on the web is sufficiently rare that we should be grateful to Opera for offering any form of MathML support whatsoever, then I don’t see a substantive difference with Micorsoft’s approach to Standards.

And my response is very similar to that of the chorus of responses to Microsoft’s IE8 announcement: don’t expect the MathML generating tools that I am responsible for to start emitting ASCII Art, instead of real MathML. Instead I’m going to recommend that people equip themselves with a browser with real MathML support. (In this case, even IE with the MathPlayer plugin does far, far better than Opera is planning to achieve.)

For those trying to follow along, this is the equivalent of Microsoft deciding that Sam’s trick of mapping some subset of SVG to SilverLight is “good enough”, and that anything not covered by Sam’s transformation is not “common enough” to be worth bothering with.

Thanks for feedback.

Pretty much describes all of MathML.

That is another story. I was thinking about what fraction of math content would need mmultiscripts with both prescripts and sub/superscripts.

Sam’s trick of mapping some subset of SVG to SilverLight

Jacques: I’m not sure that’s a good analogy. I did that exercise to convince myself that Silverlight had an adequate amount of primitives to be able to handle all of SVG. The only reason why that demo is a subset is that once that goal was achieved, the demo served my purposes — namely to convince myself that the only reason that Microsoft doesn’t support SVG is because they chose not to.

In the case of mapping MathML using CSS, it is not clear that the full range of MathML can be supported in this manner. In fact, it appears that it can not.

Thanks for feedback.

White Lynx: mind if I ask if you have you ever visited The n-Category Café, Planet Musings, or Jacques Distler’s blog? While I truly wish I understood even 1% of it, it is clear to even me that the equations that are contained on those pages are not contrived in a manner to make any particular browser vendor look good or bad, but are precisely the types of things that this group of people want to scribe on the white-board that is the internet.

In plain TeX, you would write $R_i{}^j{}_k{}^l$. This is still semantic garbage, but that’s not the point. (No one, for instance, claims TeX is accessible.)

In itex, there’s a \multiscripts{}{}{} and a \tensor{}{} command, which generate the desired MathML markup (mmultiscripts with or without mprescripts).

I was thinking about what fraction of math content would need mmultiscripts with both prescripts and sub/superscripts.

Since you, apparently, don’t have an acceptable way to denote tensors at all, the fact that you can’t, at the same time, include prescripts seems like a minor problem.

But, anyway, on my blog, of 192 posts containing MathML, 13 had at least one instance of mmultiscripts and of those, 5 included prescripts as well. None of the 13 (if I understand the limitations of your proposal) are compatible with your CSS profile.

If you want better statistics, there are tools for gathering such. (There is, admittedly, an inherent bias: most MathML is generated by converting from some dialect of TeX and, unlike itex, some other converters do not have a way to generate mmultiscripts.)

Sam’s trick of mapping some subset of SVG to SilverLight

Jacques: I’m not sure that’s a good analogy. I did that exercise to convince myself that Silverlight had an adequate amount of primitives to be able to handle all of SVG. The only reason why that demo is a subset is that once that goal was achieved, the demo served my purposes — namely to convince myself that the only reason that Microsoft doesn’t support SVG is because they chose not to.

Not knowing anything about SilverLight, I would not have known that. But, despite the bad analogy, it doesn’t change the point.

In the case of mapping MathML using CSS, it is not clear that the full range of MathML can be supported in this manner. In fact, it appears that it can not.

Oh, we haven’t even gotten started.

MathML has an “operator dictionary” which determines which math operators are stretchy (horizontally, vertically, or both). The CSS implementation doesn’t have such a dictionary, which produces semantically-correct, but comically bad-looking renderings.

White Lynx: mind if I ask if you have you ever visited The n-Category Café, Planet Musings, or Jacques Distler’s blog?

Browsing those blogs in the latest Opera 9.50 is a particularly revealing illustration of the limitation of White Lynx’s CSS approach to implementing MathML.

(Not an inherent limitation, but I think you will be very amused at how White Lynx’s stylesheet treats the annotation-xml element.)

Not an inherent limitation, but I think you will be very amused at how White Lynx’s stylesheet treats the annotation-xml element

In exactly the same way how it is treated by Mozilla (in case you find it amusing).

Browsing those blogs in the latest Opera 9.50 is a particularly revealing illustration of the limitation of White Lynx’s CSS approach to implementing MathML.

Most of that content can be perfectly expressed in CSS profile.

In plain TeX, you would write $R_i{}^j{}_k{}^l$.

Not hard to imagine what would you do if I would suggest it.

White Lynx: mind if I ask if you have you ever visited The n-Category Café, Planet Musings, or Jacques Distler’s blog?

Yes.

While I truly wish I understood even 1% of it, it is clear to even me that the equations that are contained on those pages are not contrived in a manner to make any particular browser vendor look good or bad, but are precisely the types of things that this group of people want to scribe on the white-board that is the internet.

Well, I hear complains about something that is common practice is about every language excluding MathML. There are plenty of LaTeX users, that produce exactly that type of content without having mmultiscripts. There are many M$ Office users that don’t have those mmultiscripts either and yet handle tensor indices. As Jacques just commented there are plenty of conversion tools that don’t produce mmultiscripts. And it is apparently acceptable limitation for multimegabyte applications, but for some reason it is completely unacceptable for 15K style sheet to have the same issue.

Most of that content can be perfectly expressed in CSS profile.

See my previous comment.

but for some reason it is completely unacceptable for 15K style sheet to have the same issue.

I don’t give a hoot about a 15K stylesheet.

What I care about is whether Opera’s “out of the box” MathML support actually implements the MathML Specification. What needs to be done “under the hood” to achieve that is of no concern to me. If one could do it with a 15K stylesheet, that would be great.

But one can’t.

And moving the goalposts to “We’ll implement whatever can be achieved with a 15K stylesheet” is not an adequate response. If Sam doesn’t like my SilverLight analogy, find another one. But please don’t pretend that “whatever can be achieved with a 15K stylesheet” is supposed to be satisfactory.

For those unfamiliar with “White Lynx,” he has long been an advocate of a pure-css approach to formatting mathematics on the web.

If that approach resulted in CSS3 and/or MathML being updated to allow the expressions that you care about to be rendered correctly, and such that support for changes were to find their way into browsers like Opera in time frames that actually are relevant, then that would seem to me to be a good outcome.

Recommendations that “ASCII art” and such be employed in the interim seems counter-productive to that goal.

Recommendations that “ASCII art” and such be employed in the interim seems counter-productive to that goal.

Hmm.. “Do The Simplest Thing That Could Appear To Possibly Work Some of Time If You Don’t Really Care About the Cases That Don’t Work” ? It doesn’t exactly roll off the tongue but I think it could catch on :-)

If that approach resulted in CSS3 and/or MathML being updated to allow the expressions that you care about to be rendered correctly, and such that support for changes were to find their way into browsers like Opera in time frames that actually are relevant, then that would seem to me to be a good outcome.

It seems to me that a lot of people are waiting impatiently on CSS3. But, yeah, if it so happened that features were added to CSS3 which paved the way for a pure-CSS rendering of MathML, that would be great. But it seems we shouldn’t be holding our breath.

Alternatively, if we’re dreaming about alternative routes to rendering MathML, there’s GtkMathView (LGPL), which can render MathML to SVG. Luca Padovani’s offer to help integrate it into WebKit seems to have fallen on deaf ears.

(AbiWord's equation editor uses itex2MML as a front-end and GtkMathView as a back-end, so I’ve played around with it a little bit.)

The only reason why that demo is a subset is that once that goal was achieved, the demo served my purposes — namely to convince myself that the only reason that Microsoft doesn’t support SVG is because they chose not to.

It’s hard to sell your super-duper technology when those implementing a five year old spec can get the same functionality.

If that approach resulted in CSS3 and/or MathML being updated

Well, we are making some changes on MathML side as you already noticed and wish to make changes on CSS3 side too [1-2] if allowed to do so. Obviously there is no guaranty that either CSS WG will make enough efforts to address issue or browsers will quickly implement relevent extensions.

to allow the expressions that you care about to be rendered correctly,

To clarify, the particular examples that triggered discussion are renderable with CSS, but when working on appropriate MathML profile we had to ensure both backwards compatibility with MathML 2.0 and restrictions coming with CSS rendering model that makes it much more tricky. If we would be allowed to break backwards compatibility and change markup for mmultiscripts to ensure that order of elements in markup matches their inflow position it would not be an issue.

Recommendations that “ASCII art” and such be employed in the interim seems counter-productive to that goal.

So far I did not mention ASCII art.

See, e.g., this post

So, what? First child of semantics is assumed to be presentational MathML the rest are hidden in both Mozilla and Opera to allow those who use parallel markup (with content MathML/OpenMath annotations for example) without breaking presentational part in browsers. Was that amusing?

And moving the goalposts to “We’ll implement whatever can be achieved with a 15K stylesheet”

That is not the goal. What is going on here is that we are exposing functionality that rendering engine has in the way that can be reused by among others MathML community (assuming there is such).

Alternatively, if we’re dreaming about alternative routes to rendering MathML, there’s GtkMathView (LGPL), which can render MathML to SVG.

There is some progress, you don’t fear SVG anymore :)

So, what? First child of semantics is assumed to be presentational MathML the rest are hidden in both Mozilla and Opera...

Umh, no.

Try looking at that post in Mozilla. Note the presence of SVG-in-MathML-in-XHTML.

And moving the goalposts to “We’ll implement whatever can be achieved with a 15K stylesheet”

That is not the goal.

Given the way this has been presented, one might be forgiven for thinking otherwise.

What is going on here is that we are exposing functionality that rendering engine has in the way that can be reused by among others MathML community (assuming there is such).

What I would like to see, in MathML3 is an expansion in the range of mathematical notation that can be represented in MathML. What I see here is a severe restriction, compared to what is expressible in MathML2.

It’s perfectly possible that, at some distant future date, CSS3 (or 4 or 5) will add the features necessary to make a pure-CSS approach competitive with native MathML rendering (as currently provided by Gecko or MathPlayer or GtkMathView).

Perhaps that’s a goal worth working towards. But it’s far enough in the future that it’s not relevant to me. If that’s the road Opera chooses to pursue, good luck to y’all.

I’d still like to see native WebKit support for MathML. And, given their track record delivering SVG, I’m pretty sure it can be delivered on a time-scale much shorter than the CSS-WG.