- From: Justin James <j_james@mindspring.com>
- Date: Tue, 1 Apr 2008 16:08:39 -0400
- To: "'Sam Ruby'" <rubys@us.ibm.com>, "'Ian Hickson'" <ian@hixie.ch>
- Cc: "'Bruce Miller'" <bruce.miller@nist.gov>, "'David Carlisle'" <davidc@nag.co.uk>, "'Henri Sivonen'" <hsivonen@iki.fi>, <public-html@w3.org>, <public-html-request@w3.org>, "'Robert Miner'" <robertm@dessci.com>, <www-math@w3.org>
> 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