Henri Sivonen said:
Jul 15, 2006, at 16:31, <juanrgonzaleza (AT) canonicalscience (DOT) com>
<juanrgonzaleza (AT) canonicalscience (DOT) comwrote:
>
>The WHATWG specification

>and MathML was strongly rejected and after eliminated (recom.) from
>the spec.
>
I think the readers of xml-dev shouldn't jump to any conclusions
based on Juan R.'s characterization of the discussion on the WHAT WG
list.
For those who are actually interested in looking at the archives, the
subject of the thread is "Mathematics on HTML5" and it spans May and
June in the WHAT WG mailing list archives:
Well,
1) I would begin by citing your views on HTML5. For instance your heated
reply to editor's comment
If we made MathML work in HTML, possibly with rules that make
the syntax easier (by implying tags as I suggested earlier)
was
"The implied stuff seems scary. I was hoping for no more tag inference
beyond HTML 4 legacy."
2) You forget to say here that HTML5 spec (i.e. the draft) was
explicitely recommending the usage of MathML and that was eliminated in
a new version of the draft after discussion maintained at the list,
3) Resume of thoughts onn MathML and HTML5-Math
James Graham disagreed with MathML.
E. Andersen said "First of all, I must say that I applaud the
initiative to include tags for mathematics in HTML5 and that I really
hope that this will be part of the final specification."
Michel Fortin agreed with main proposals while adding further ideas and
criticism for the improvement of the basic mathematical markup draft
suggested.
Henri Sivonen (even if adding scary stuff about MathML, LaTeX and others
at the list) wrote, "First of all, I am not saying that MathML is
great."
Stefan Goessner highly appreciates a lightweight, pragamatic solution
for doing math on the web in a convenient way. And apointed that
solution could parallel MathML the same way as Canvas parallels SVG.
Martin Atkins wrote, "It seems to me that a good path would be to fix up
CSS's shortcomings (which have been discussed at length in this thread)
so that it is possible to specify math rendering with CSS." I.e. without
p-MathML.
H Wium Lie expressed its personal interest to adding it to HTML5.
"Personally, I'm open to adding it to HTML5." H Wium Lie also noted
that MathML and HTML5-Math both can co-exist just like WebForms and
XForms can co-exist today.
Alexey Feldgendler also agree with the idea of HTML5 math.
Mihai Sucan disagrees with the MathML way and wait for a new reliable
approach to math on the web.
Therefore, i think that my previous message exclaiming the strong
rejection of MathML at the WHATWG, the fact that previous recommendation
(to MathML) was eliminated from the HTML5 spec (draft) and the fact that
only a small minory at the list was happy with MathML was accurate.
Also Robert 'Callahan (Mozilla Layout team) wrote:
From my point of view, a <fractionelement that can be implemented
using inline-block in the UA style sheet seems like a reasonable thing
to support in HTML5, since it's basically no effort and is a
small increment over existing <supetc.

Jul 16, 2006, at 13:50, <juanrgonzaleza (AT) canonicalscience (DOT) com
<juanrgonzaleza (AT) canonicalscience (DOT) comwrote:

Henri Sivonen said:
>Jul 15, 2006, at 16:31, <juanrgonzaleza (AT) canonicalscience (DOT) com>
><juanrgonzaleza (AT) canonicalscience (DOT) comwrote:
>>
The WHATWG specification

and MathML was strongly rejected and after eliminated (recom.) from
the spec.
>>
>I think the readers of xml-dev shouldn't jump to any conclusions
>based on Juan R.'s characterization of the discussion on the WHAT WG
>list.

1) I would begin by citing your views on HTML5. For instance your
heated
reply to editor's comment

Heated? Wow. Your heat detector is miscalibrated.

BTW, I agreed with Hixie that making MathML serializable as HTML5
probably makes sense.

2) You forget to say here that HTML5 spec (i.e. the draft) was
explicitely recommending the usage of MathML and that was
eliminated in
a new version of the draft after discussion maintained at the list,

As you quoted Hixie yourself, the recommendation wasn't particularly
intentional. You are reading way too much into the use of MathML
being recommended in the first place and you are also reading way too
much into the subsequent removal of that piece of text.

Also Robert 'Callahan (Mozilla Layout team) wrote:

Basically you are blowing any nod towards non-MathML out of proportion.

[
in-html-via-css.html]

I wonder why I am not seeing stretchy parentheses there

However, i do not see you actively participating on the experiment ;-)

I've been busy fixing bug 18333, which was one of the issues you held
against MathML. :-)

Le lundi 17 juillet 2006 * 13:42 +0100, David Carlisle a crit :
How did this thread get hijacked onto MathML?, still

I think that is has even been hijacked onto HTML 5 and since we are
discussing best technologies that don't win, I am wondering if the best
technology that will loose is supposed to be HTML 5 or XHTML 2.0.

In one of his best pieces, Edd Dumbill once wrote "Don't turn off your
critical faculties because something's a "standard"" [1] and I think
that I have shown that I didn't intend to turn off my critical faculties
concerning the work done by the W3C.

[1]

Now that doesn't mean that you shouldn't tell when you think that
standard organisations are doing a good job and I really think that the
refactoring of XHTML that they are doing with XHTML 2.0 is well done and
most useful and I al genuinely surprised to see that so many people are
so negative about XHTML 2.0.

I have also the feeling that the counter proposal known as HTML 5.0 is
very wrong on many points and that it would lead to a "DockBookization"
of XHTML that we need to avoid.

I mean no offense to DocBook which history has led to be what it is now,
but I think that there are much too many different elements that are not
really core and that despite all these elements you still can't express
all that you would need to express.

The only solution to avoid this kind of issues is not to increase but to
reduce the number of elements and add mechanisms to express not only the
style (like it is the case with the class attribute) but also the
intention (or semantics even if this term doesn't mean much any longer)
of elements.

XHTML 2.0 is going in that direction which seems to be the only safe and
wise one while HTML 5 is going in the opposite direction and looks to me
like a regression in many aspects.

In other words, I think that under its appearance of simplicity, HTML
5.0 will lead to more complexity and that the real simplicity is with
XHTML 2.0.

I am curious to see what this list thinks about this.

Eric

* Eric van der Vlist wrote:
>The only solution to avoid this kind of issues is not to increase but to
>reduce the number of elements and add mechanisms to express not only the
>style (like it is the case with the class attribute) but also the
>intention (or semantics even if this term doesn't mean much any longer)
>of elements.
>
>XHTML 2.0 is going in that direction which seems to be the only safe and
>wise one while HTML 5 is going in the opposite direction and looks to me
>like a regression in many aspects.

XHTML 2 increases the element count by 50% compared to XHTML 1.0 Strict,
and by 10% compared to HTML 2.0, HTML 3.2, HTML 4.01, and XHTML 1.1 com-
bined, including the Frameset and Transitional variants. I am unsure how
you could consider that going into the direction of "not to increase but
to reduce the number of elements".

When evaluating XHTML 2.0 I recommend
as starting point. There you can find:

In discussions, it was agreed that further extending HTML 4.0 would
be difficult, as would converting 4.0 to be an XML application. The
proposed way to break free of these restrictions is to make a fresh
start with the next generation of HTML based upon a suite of XML
tag-sets.

When asked about extensibility of XHTML 2.0, to avoid that XHTML 2.0
will face the same fate of having to be replaced by an entirely new
and incompatible format, twice, the HTML Working Group responds: "at
this time the Working Group has no ready solution". So on both of your
counts -- less elements, improved extensibility -- XHTML 2.0 scores
quite badly. Meanwhile they are still working on a "usable" DTD for
it, <>.

Jul 17, 2006, at 15:42, David Carlisle wrote:

How did this thread get hijacked onto MathML?, still
>
>BTW, I agreed with Hixie that making MathML serializable as HTML5
>probably makes sense.
>
It's easy to make a version of the MathML DTD compatible with the SGML
declaration for HTML rather

There's no need for such a DTD. HTML5 doesn't pretend to be an
application of SGML and has no normative DTD. (HTML5 has no normative
schema of any kind. A non-normative RELAX NG schema is under
construction, though.)

could choose while doing that
whether to make some of the end tags (or even start tags) optional

Hixie suggested that. With my parser writer hat on, I am
uncomfortable with new implied tags.