Re: Exploring new vocabularies for HTML

For the non-visual use case; note that MathML 1.0 was explicitly
designed to be better than TeX/LaTeX for that specific use case.

I like to write TeX/LaTeX; however asserting that that notation
is somehow superior to MathML for the non-visual use case is bogus.

Henri Sivonen writes:
 > 
 > On Mar 29, 2008, at 19:08, David Carlisle wrote:
 > >> I'm investigating possible options for addressing the problem of  
 > >> "Putting
 > >> an equation in a Web page". One of the options is doing something  
 > >> with
 > >> MathML.
 > >
 > > Given the existing implementation and experience in this area surely
 > > MathML should not simply be "one of the options" it should be the main
 > > option. For HTML5 to invent some new math markup unsupported by any
 > > existing mathematical software would be a complete disaster for the
 > > cause of putting scientific documents on the web.
 > 
 > I agree. Moreover, I think the HTML WG doesn't have the bandwidth to  
 > reinvent math notation *properly*.
 > 
 > As far as existing formats and options go, I'm concerned that  
 > implementing support for a constrained *TeX flavor in browsing  
 > software for non-visual access (http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0000.html 
 > ) would be a further diversion from getting MathML support in browsers  
 > (with accessibility). For visual and dynamic scenarios, a *TeX flavor  
 > wouldn't integrate with DOM scripting and CSS formatting the way  
 > presentational MathML does.
 > 
 > > (Microsoft Word converts to MathML on cut-and-paste,
 > 
 > 
 > Out of curiosity, where can one copy from? It has been over a year  
 > since I looked at Gecko's clipboard code, but I don't recall seeing an  
 > XML clipboard export code path for something like this.
 > 
 > > I think the assumption here was that in an html context one might  
 > > want to
 > > give up some of the rules coming from XML parsing (attribute quoting,
 > > perhaps some element closing, etc) I think it would be a mistake to  
 > > try
 > > to insert character level tokenisation and parsing to imply token
 > > elements such as mn and mi. The strength of a format like MathML
 > > is that such tokenisation is explict (and one of the problems in
 > > converting from say, TeX, where these things are not explicit is that
 > > different systems have different heuristics.
 > 
 > I agree that we shouldn't try to define magic start tag inference.  
 > It's not worth the trouble when it is reasonable to expect authors to  
 > generate MathML anyway most often anyway. (We should define popping  
 > rules when the end tag doesn't match the element on the stack, though.)
 > 
 > >> MathML is a very big language, with just shy of 190 unique elements  
 > >> in
 > >> MathML2 (HTML4, including all the deprecated elements, has but 91).  
 > >> Could
 > >> we get away with making that simpler for HTML, e.g. by not including
 > >> support for Content markup in the text/html variant?
 > >
 > > I think you should aim for the support level of mozilla.
 > > So basically just supporting presentation mathml (which brings the
 > > element count down to a handful of structural forms) but support
 > > <semantics> by rendering its first child and skipping over any
 > > annotation-xml children with display property of none. So annotation- 
 > > xml
 > > ought to be able to be take as content any well formed XML, but the  
 > > only
 > > requirement for html5 would be to parse to the end of it, not to  
 > > display
 > > content mathml natively. (Native rendering of content mathml3 would be
 > > nice but I think in the real world it's not going to happen  
 > > everywhere)
 > 
 > In Firefox 3, Gecko supports SVG in annotation-xml. I think annotation- 
 > xml should establish a new <body>-like parsing scope like <td> does.  
 > An <svg> element would establish an SVG scope right away, but other  
 > elements would be taken as HTML.
 > 
 > I'm not quite convinced about the utility of annotation-xml for  
 > purposes other than embedding vocabularies supported by Web engines  
 > (HTML and SVG). A while ago, I implemented XHTML5 + SVG 1.1 + MathML  
 > 2.0 compound document support in Validator.nu with XHTML root and then  
 > arbitrary recursion through annotation-xml and foreignObject. For  
 > MathML in SVG in XHTML and SVG in MathML in XHTML, there are use cases  
 > on Jacques Distler's blog. However, I also created an "any OpenMath  
 > goes" hole, since the spec suggested OpenMath would be the third  
 > embeddable XML vocabulary in addition to XHTML and SVG.
 > 
 > I thought Jacques Distler's comment feed would have been one of the  
 > best ways to reach for MathML authors who are tracking now  
 > developments in this domain, so I posted there:
 > http://golem.ph.utexas.edu/~distler/blog/archives/001475.html
 > 
 > However, so far no one has come forward with OpenMath-in-annotation- 
 > xml validation needs. Is OpenMath actually used on the Web? What  
 > client is expected to consume it? So far it looks like it would make  
 > more sense to assume that browser-targeting authors use annotation-xml  
 > for SVG or XHTML, so we might as well open a new <body>-like HTML  
 > parsing scope in there (with <svg> in turn establishing an SVG scope  
 > straight away).
 > 
 > >> One of the use cases is the mixing of graphics and form controls into
 > >> equations. Is it possible to extend MathML to allow specific HTML5
 > >> phrasing-level elements (like <em>, <img>, <input>, also maybe the  
 > >> <svg>
 > >> element) wherever the <mglyph> element is currently allowed, or  
 > >> something
 > >> along those lines?
 > 
 > That would lead to much more special casing than establishing a nested  
 > scope in annotation-xml as I suggested above (and have suggested  
 > earlier).
 > 
 > > It's possible technically of course but I think it's fair to say that
 > > there isn't total consensus on whether it's a good idea.
 > > there are though two aspects to that question.
 > >
 > > In a purely mathml context, should mathml be opened up to allow any
 > > foreign markup there.
 > >
 > > or if in "pure" mathml that is not allowed, should html+mathml allow  
 > > nested
 > > html (and docbook+mathml allow nested docbook, and as came up
 > > controversially recently should OOXML+MathML allow nested OOXML)
 > 
 > Do those cases allow the elements from the different vocabularies to  
 > intermingle without an annotation-xml scope?
 > 
 > -- 
 > Henri Sivonen
 > hsivonen@iki.fi
 > http://hsivonen.iki.fi/
 > 
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Monday, 31 March 2008 21:45:29 UTC