- From: David Carlisle <davidc@nag.co.uk>
- Date: Tue, 29 Jun 2010 09:39:06 +0100
- To: "Michael(tm) Smith" <mike@w3.org>
- Cc: www-math@w3.org
On 29/06/2010 08:13, Michael(tm) Smith wrote: > If you have use cases and/or real-world examples, in existing > documents, of<annotation-xml> instances containing HTML content, > please post them as replies to this message and/or as comments > to the following HTML WG bugzilla bug - > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=9887 > > The background on my request is this: > > - The HTML5 specification defines an algorithm for parsing > text/html (non-XML) documents that contain MathML elements. > > - That algorithm deals with the<annotation-xml> element as a > special case; it provides for both SVG and MathML content in > <annotation-xml> being properly parsed into a DOM as expected. If this is the best that can be achieved in the html5 parsing algorithm it is I suppose better than nothing but it is really a very broken design. annotation-xml should take any well formed XML. The XML syntax (with explicitly closing /> empty element syntax was designed to make this easy to achieve; it should always be possible to reliably parse to the correctly matching close /annotation-xml. In an HTML5 context the syntax rules no doubt would be relaxed a bit, but it should still be possible to parse to the end of the annotation reliably, and to place those elements into the dom (with by default no effect on rendering). annotation-xml is essentially like data- attributes in html except that being an element rather than an attribute it can take structured content. There are any number of reasons for wanting to annotate an expression with (x)html, it may be a fallback html rendering for cut and paste into systems that don't do mathml, it may be some kind of tooltip or structured help which is perhaps activated by script elsewhere on the page, it might be a copyright statement. It really isn't the job of the specification to try to second guess why an expression is annotated, just to allow it to be annotated. > > - However, for the case of HTML content in<annotation-xml>, it > does not provide for that content getting into the DOM as child > content of the<annotation-xml> element; instead such content > will essentially end up getting into the DOM as a following > sibling of any ancestor<math> element. That would be entirely incorrect. > > You can test and see for yourself by using a recent Mozilla > Minefield or Firefox nightly build with this page: > > http://software.hixie.ch/utilities/js/live-dom-viewer/ > > for example: > > http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3E%3C%2Ftitle%3E%0A%3Cp%3E%0A%3Cmath%3E%0A%3Csemantics%3E%0A%3Cmi%3Efoo%3C%2Fmi%3E%0A%3Cannotation-xml%3E%0A%3Cimg%20src%3Dbar%3E%0A%3C%2Fannotation-xml%3E%0A%3C%2Fmath%3E%0A%3C%2Fp%3E > > or: http://bit.ly/dy4Rxj > > So what I would like to try to get clarification on is whether > there are compelling use cases for having HTML content within the > <annotation-xml> element that would justify making a change at > this point to the parsing algorithm in the HTML5 spec (and to the > behavior of existing implementations of that). I can think of no possible justification for rendering the child of an annotation element that is deeply nested inside a math expression as text following the math expression, so the question seems strangely posed. Given that no user could possibly want this behaviour, what is the compelling use case for specifying things that way? > > --Mike > David (speaking personally) ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________
Received on Tuesday, 29 June 2010 08:39:38 UTC