RE: Exploring new vocabularies for HTML

> There is a tension here.  Forgive me as I'm about to use a loaded term.
 One can take a
> myopic view and look at simply the requirements for a few specific
vocabularies as they are
> understood at a given moment at time and hope they never change, and
optimize for that.

> Or you can take a farsighted view (which, if the world were fair, would
have an equally
> negative connotation as nearsighted) and not focus on local optimizations
but on the big 
> picture: namely that there will always be a need for people to
"unilaterally extend the
> language to address problems we are currently unaware of and that
therefore are not covered
> by existing functionality; Without trampling on the toes of others; and
without being
> beholden to an external entity to provide the enhancements for the author
on a timescale
> that is useful to the author."

I agree completely. The options are really simple, regardless of how many
various examples we throw at this question.

1) Fully incorporate MathML, SVG, and maybe one or two other specs into
HTML, to ensure that the changes are 100% compatable and complimentary as
time goes by.

2) Completely ignore the situation by expected HTML authors to use <object>
to request that a user agent plugin, if available, handle these non-HTML
markups; maybe allow the <object< tag to hold a CDATA of the "foreign"
document.

3) Do the same thing as #2, but with a specialized tag. Just as we are now
going with <audio> and <video>, there could be <image> for SVG and <math>
for MathML, and those tags have just enough attributes and elements to allow
a user agent plugin to get the needed content. This lets the UA determine
the precise plugin to use, as opposed to having the content author determine
it as is the case with <object>.

4) Work closely with the SVG, MathML, and maybe one or two other groups to
provide a "presentation subset" of their spec that could be imported into
the HTML spec and follow the spirit and intent of the HTML spec as opposed
to their own. The HTML spec would say, basically, "must support whatever
MathML's presentation spec says", so MathML could be updated at different
times from HTML (and vice versa), and the MathML group would consult with
the HTML group on the issue of that one subset only, while still retaining
final control over their own spec. As it becomes clear that additional
vocabularies need to be support, similar arrangements would be made with
those groups.

#1 is just plain impossible. #2, which I previously supported, does not
really help anyone, and allows HTML to ignore the concept of non-text in
documents, which I think is a poor idea. #3 is consistent to the approach
taken with non-SVG images historically, and audio and video in HTML 5, and I
think that it is a valid approach. It essentially says, "we hardcode in a
special case that breaks HTML's consistency just for a few select items that
are critical to HTML, but need to be defined outside of HTML". #4 is
likewise an approach that I believe we could live with.

Whatever we do, it must be sustainable not just for the MathML question
today, but for future new vocabularies as well.

J.Ja

Received on Tuesday, 1 April 2008 20:09:39 UTC