W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2010

[Bug 9887] parsing algorithm should allow HTML content in MathML <annotation-xml>

From: <bugzilla@jessica.w3.org>
Date: Thu, 19 Aug 2010 01:12:40 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1OltgO-0004JW-3l@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9887





--- Comment #14 from David Carlisle <davidc@nag.co.uk>  2010-08-19 01:12:39 ---
(In reply to comment #13)
> I don't understand the example. What's the actual use case? Annotation?
> Wouldn't <mtext> be the way to do annotation?


No. mtext is a token element that renders text as part of the expression not a
(typically unrendered) structured annotation. annotation-xml (like svg's
foreign-element) is a container element for arbitrary structured content
(typically but not necessarily, non-mathml). HTML, being the canonical markup
language for structured text is perhaps the prime example of what one might
want to put in such an annotation. Certainly there can be no justification for
such a simple well formed valid input document to produce such a bizarre
unusable DOM tree.

It isn't for the mathml spec (or its editor) to speculate on what possible uses
the annotation may have, perhaps it is data used by some in-page javascript to
pop up proof help tips, or perhaps it's alternative representations as openmath
or content mathml, or html4.

My preference would be to remove the entire mechanism to make html elements
break out of foreign content, the only justification given for this (supporting
possible legacy documents using a previously undefined math element in html)
seems very weak, such an argument would prevent any new elements ever being
added to html. failing that annotation-xml and svg's foreign-content should be
protected from this so that they are usable.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 19 August 2010 01:12:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:21 UTC