From: Bruce Miller <bruce.miller@nist.gov>

Date: Wed, 12 Apr 2006 10:52:50 -0400

Message-ID: <443D1442.10604@nist.gov>

To: www-math@w3.org

Date: Wed, 12 Apr 2006 10:52:50 -0400

Message-ID: <443D1442.10604@nist.gov>

To: www-math@w3.org

White Lynx wrote: > Bruce Miller wrote: > >>However, I think that your comments would be more >> productive >>--- assuming you're actually >>trying to have a constructive discussion > > Productive in what sense? It clear that W3C will > not change basic design principles of MathML > no matter how constructive, consistent and relevant > our comments are. W3C left no space for productivity > and we are forced to seek for niches either in current > web stanadrds (XML/CSS/ECMAScript/DOM) > or take more radical approach and create something > completely new like Juan wan't to do. > Inspite the fact that Math WG is unlikely to change > anything I reserve right to express my concerns regarding design of MathML. Hi George; Productive in the sense of working _with_ us to do what is _possible_ to improve MathML. Or alternatively by proposing new basic design principles that solve the problem better. Of course, you'd be kinda obligated to demonstrate that these new principles actually can solve the _whole_ problem better, or whatever you think is the important part of the problem. And in fact, it would need to be dramatically better: David has already pointed out the impact of making radical changes to MathML now; that really can't be done. A new markup will have to be compelling enough for both authors and implementors to adopt. Were browser developers slow to implement MathML because MathML was so poorly designed? Or because "Who cares about math?" Nevertheless, if you find that MathML is truly unredeemable, then you really should propose an alternative, and work to get it adopted. As you know, MathML also has a goal of representing the "meaning" of math, or at the least it's structure, beyond mere presentation. You might reasonably debate whether it _should_ have that goal, or whether it meets it, but it's there. Thus, for example, encapsulating the base of sub & superscripts is important; a simple <sub> tag doesn't do this. As you also know, I share your frustration that MathML can't be presented solely by CSS. I wasn't part of the group at the time, but the first MathML recommendation came only a year (early 1998) after the first CSS recommendation (late 1996). I doubt that it could have been forseen at that time that CSS would become the basis for rendering engines, rather than icing on top of it. If it had, might MathML have come out differently? Perhaps... Maybe CSS would have, too. In any case, the languages of MathML & CSS don't match so well. There are some `accidental' choices made in MathML that are hard to address with CSS's Selectors. On the other hand, while CSS's box model comes surprisingly close, it really isn't yet up to the task of Math either (Math in general, not specifically MathML). So, where do we go from here? Redesign MathML from the ground up? Redesign CSS from the ground up? Lobby for enhancements, clarifications and even deprecations in both MathML and CSS? -- bruce.miller@nist.gov http://math.nist.gov/~BMiller/Received on Wednesday, 12 April 2006 14:53:06 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:58 GMT
*