RE: Exploring new vocabularies for HTML

> Can someone please fill in some of the gaps, here?
> I get the feeling there's a stage(s) where "Magic Happens"...

I could not agree more. Right now, we are only accounting for MathML. Even
when we discuss this issue as not MathML-specific, we are thinking only in
that context. What's to happen if I come up with my own DOM and want to
embed it? Do I also have to account for, in my DOM, these kinds of issues?
Do I submit it to the W3C and hope that the handling rules make it into HTML
6?

I propose a much simpler solution that is properly within the spirit of
HTML.

Allow the HTML author to embed an OBJECT reference to a parser that handles
their format. Problem solved. Just because MathML (or *ML) happens to use
the XML syntax, what right do their authors have to expect that an *HTML
renderer* will be able to handle it? Why should everyone who writes an HTML
consuming library or application have to account for every DOM that we
either hardwire in at this time, or allow to be dynamically used? Why not
treat non-HTML DOMs the same way we would treat any other non-HTML file
format, as either something that can be embedded with OBJECT, or something
that the user agent can download and let the OS handle?

In other words, what makes MathML (or *ML) so special that we feel the need
to cater to it in HTML 5? It is *impossible* to properly handle this without
a "magic happens" style spec, or creating some giant kludge of an embedded
*ML handling system that allows the authors of "foreign" DOMs to use some
standardized scripting to control the HTML user agent. In other words, we
would need to re-create something like ActiveX, Silverlight, Java applets,
Flash, etc. to allow DOM authors to provide the full handling implementation
to an HTML user agent in a standardized way. Or we can just use the
existing, working, and standardized plugin system. I vote for the latter.

J.Ja

Received on Monday, 31 March 2008 16:28:05 UTC