This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9887 - parsing algorithm should allow HTML content in MathML <annotation-xml>
Summary: parsing algorithm should allow HTML content in MathML <annotation-xml>
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-09 02:28 UTC by Michael[tm] Smith
Modified: 2010-10-04 13:59 UTC (History)
7 users (show)

See Also:


Attachments
example use case of mathml using annotation-xml (868 bytes, text/html)
2010-08-18 09:53 UTC, David Carlisle
Details

Description Michael[tm] Smith 2010-06-09 02:28:12 UTC
for more context, see comments in bug 9859 -- in particular, this comment from Simon:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=9859#c2

relevant excerpts from that:
 
[[
The HTML5 parser only allows <svg> or MathML in <annotation-xml>. Not HTML."

We could change the parser to allow HTML there (like it allows HTML in MathML
<mi>), but then it would break MathML in <annotation-xml>. The MathML spec has
an example with MathML in <annotation-xml>.

Maybe we need a special tag that enables HTML in <annotation-xml>? <div>? It
means MathML can't have a future element called <div>.

"A start tag whose tag name is "svg" or "div" if the current node is an
annotation-xml element in the MathML namespace."
]]
Comment 1 Simon Pieters 2010-06-09 09:33:18 UTC
Using annotation-xml to embed svg or html in mathml seems like an ugly hack, maybe we shouldn't support it at all and require use of <mn> et al instead.
Comment 2 Simon Pieters 2010-06-16 22:10:55 UTC
http://www.w3.org/TR/mathml-for-css/ has the following rule (which appears to be implemented in Opera):

annotation, annotation-xml
	{display:none;}
Comment 3 David Carlisle 2010-06-17 08:11:25 UTC
(In reply to comment #1)
> Using annotation-xml to embed svg or html in mathml seems like an ugly hack,
> maybe we shouldn't support it at all and require use of <mn> et al instead.

I can not see why you call this a hack, this is the intended usage of the element
It is far preferable to use a an mn with a number in it and then annotate it with annotation-xml if necessary as that gives specified fallback for those systems that do not understand each kind of annotation.  The default display for an annotation is to ignore it, so all a browser needs to do with annotation-xml is not generate an error with it.
Comment 4 David Carlisle 2010-06-17 08:16:20 UTC
(In reply to comment #2)
> http://www.w3.org/TR/mathml-for-css/ has the following rule (which appears to
> be implemented in Opera):
> 
> annotation, annotation-xml
>     {display:none;}

Yes that is the default behaviour for the css profile and more or less the default behaviour for the full mathml as well (where the default behaviour is to ignore all annotations except to use a presentation mathml annotation for display in preference to rendering the base). html5 (or an xhtml+mathml document format might want to additionally specify that html (or svg) in an anotation should be rendered instead of the base, but that would be an issue for html5 to specify (or in general the designer of any compound document format including mathml) it is beyond the scope of the mathml recommendation itself.
Comment 5 Simon Pieters 2010-06-17 09:35:14 UTC
> I can not see why you call this a hack, this is the intended usage of the
element

> Yes that is the default behaviour for the css profile and more or less the
default behaviour for the full mathml as well

If the intended usage of annotation-xml is to render SVG, then why is annotation-xml display:none?

If annotation-xml is intended for embedding stuff that's not supposed to be rendered, then it's not appropriate to put SVG in there.
Comment 6 David Carlisle 2010-06-17 10:24:07 UTC
(In reply to comment #5)
> > I can not see why you call this a hack, this is the intended usage of the
> element
> 
> > Yes that is the default behaviour for the css profile and more or less the
> default behaviour for the full mathml as well
> 
> If the intended usage of annotation-xml is to render SVG, then why is
> annotation-xml display:none?

> If annotation-xml is intended for embedding stuff that's not supposed to be
> rendered, then it's not appropriate to put SVG in there.

You need to make a distinction between mathml (or mathml-css-profile) and 
mathml (or mathml-css-profile) in html.

A conforming mathml system is not obliged to render svg or html, so the default behaviour of an annotation-xml with svg or html in them is that they are legal, and validate against the mathml schema but by default they have no effect on rendering or anything else. the only annotation type for which the mathml spec suggests any rendering behaviour is an annotation-xml containing presentation mathml which should be used as the rendering in preference to rendering the base. Basically annotation-xml acts like an unknown attribute, except that it is an element to allow structured content.


However html5 spec is defining a larger html+mathml+svg compound document format, and there it would be perfectly logical to say that an annotatation-xml with html or svg (or some combination thereof) should be rendered in preference to the base if that is what you want to specify. The html5 spec can say this as it has the vocabulary to talk about html and svg. the Mathml spec can say very little about how mathml is embedded in a larger format, it has to work with html, docbook, TEI, ODF, and in different contexts different annotations may have a rendering effect and others will be ignored. In mathml+docbook it may be that annotating with a fragment of inline docbook markup affects the rendering, but an annotation with svg is ignored, and in mathml+html the opposite is true.
Comment 7 David Carlisle 2010-06-29 08:43:10 UTC
please see

http://lists.w3.org/Archives/Public/www-math/2010Jun/0022.html
Comment 8 Simon Pieters 2010-06-29 13:12:10 UTC
(In reply to comment #7)
> please see
> 
> http://lists.w3.org/Archives/Public/www-math/2010Jun/0022.html


> 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.

The purpose of this bug is finding if the algorithm can be changed to something better. However, to know what is better, real-world pages and use cases are needed.


> 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).

It's a bit complicated. text/html is not XML. It does not support arbitrary namespaces. It only supports HTML, SVG and MathML. For compatibility with existing content, certain tags have to break out of <math> unless they appear in places where HTML is expected (like <mtext>).

Since <annotation-xml> can contain MathML, the parser can't expect HTML there since it would break MathML in <annotation-xml> (the elements would be in the HTML namespace instead of the MathML namespace).

> 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.

Are you aware of any existing content that uses HTML in <annotation-xml>?

If you think it should be supported to use HTML in <annotation-xml>, how would you want it to work? Should the parser expect HTML if there's an encoding attribute with a certain value? Should the parser special-case the "div" tag to indicate HTML content in annotation-xml? Something else?

>   >   - 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.

This is only the case if the element is one of "b", "big", etc (see "in foreign content" in the spec). For other elements, they end up in the MathML namespace but don't break out.

> That would be entirely incorrect.

It's for compat with pages that have bogus <math> followed by HTML content. Not rendering the HTML content would break the page.


>   > 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?

See above. Users want pages to continue to work as they worked in the previous version of the browser, even if the page contains a <math> or <svg> tag somewhere where it's not intended to be MathML or SVG.

>   >    --Mike
>   >
>
> David
> (speaking personally)
Comment 9 David Carlisle 2010-06-29 14:10:29 UTC
(In reply to comment #8)


> However, to know what is better, real-world pages and use cases are
> needed.
> 

there are essentially no real world cases of html in math in a text/html document as this (as you know) is all new.


> It's a bit complicated. text/html is not XML. It does not support arbitrary
> namespaces.

In text/html I don't really care what namespace the content gets put into, it's clear that namespace support in text/html is never going to be as in xml.
all that needs happen is that any unknown stuff in annotation-xml is parsed and left in the dom without affecting the rendering.

> It only supports HTML, SVG and MathML. For compatibility with
> existing content,

mathml in html has never been previously specified or implemented widely as far as I can see. To specify that forever a completely counter-intuitive behaviour is specified making annotation-xml essentially unusable for most of its intended uses, in order that a few pages that I'm sure can be found that may have had some strange existing markup continue to work in some browsers, seems very strange.

>  certain tags have to break out of <math> unless they appear
> in places where HTML is expected (like <mtext>).
> 
> Since <annotation-xml> can contain MathML, the parser can't expect HTML there
> since it would break MathML in <annotation-xml> (the elements would be in the
> HTML namespace instead of the MathML namespace).
> 
> > 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.
> 
> Are you aware of any existing content that uses HTML in <annotation-xml>?

I doubt it since I am not aware of any existing html-capable systems that can handle mathml.

> 
> If you think it should be supported to use HTML in <annotation-xml>, how would
> you want it to work? Should the parser expect HTML if there's an encoding
> attribute with a certain value? Should the parser special-case the "div" tag to
> indicate HTML content in annotation-xml? Something else?
> 
> >   >   - 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.
> 
> This is only the case if the element is one of "b", "big", etc (see "in foreign
> content" in the spec). For other elements, they end up in the MathML namespace
> but don't break out.

OK as I say below, personally, while I find that unfortunate it's not that much of a problem if you end up saying that html only works as expected in annotation-xml if the annotation consists of a single div (which is presumably enough to hide these elements?)


> It's for compat with pages that have bogus <math> followed by HTML content. Not
> rendering the HTML content would break the page.

If pages have entirely bogus markup that is eventually specified with a meaning
in som elater version of html then it is unlikely they worked reliably ever. No doubt some pages existed with video or canvas with some spurious interpretation.


> > 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?
> 
> See above. Users want pages to continue to work as they worked in the previous
> version of the browser, even if the page contains a <math> or <svg> tag
> somewhere where it's not intended to be MathML or SVG.

which users have pages that use mathml (in a form presumably that does not render as math in any existing browser) and want to distort the use of mathml forever, so that those pages carry on working unchanged? Do you have any examples?


I realise that the html parser is under some constraints, and while I'm aware of the general nature of the constraints I'm not that close to the implementation so I'll list my (personal) wish list for annotation xml

1 (most important)

annotation-xml should allow any content that has all end-tags and empty tags explicit, it just needs to correctly parse to the matching /annotation-xml

2) (important)
all annotations except the ones specifically highlighted below should have no affect on rendering.

3 (desirable)

in text/html it should be able to parse things without the usual xml syntax rules (so omitted end tags, etc)

4) (desirable)
for an annotation of Presentation-MathML, the system should render the annotation rather than the base.

5) (for the HTML WG to decide)
possibly other annotations should affect rendering, eg html or svg.
(if you need some extra rules like html must be in a div, or whatever
 so be it)
Comment 10 Ian 'Hixie' Hickson 2010-08-16 22:03:38 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: It doesn't seem like the use cases are clearly defined here. Given the complexity and subtlety of allowing this, I think we shouldn't do it unless we have very concrete and very clear use cases.
Comment 11 David Carlisle 2010-08-18 09:53:25 UTC
Created attachment 911 [details]
example use case of mathml using annotation-xml
Comment 12 David Carlisle 2010-08-18 10:08:15 UTC
the bug was marked as won't fix  with a request for additional use cases. 

It's hard to know where to start as the currently specified behaviour is so counter-intuitive and unusable it is impossible to think of any use cases where it would be desired. The following is a personal reply although it is likely that the Math working group may also make a request for this to be fixed (if that proves necessary). I would expect that the SVG group would have the same concern as presumably SVG's foreign-element is similarly broken presently.

annotation-xml is designed to allow structured annotation of parts of the expression. the default rendering is empty, but of course scripting or other technologies might make the annotations visible either all the time, or on user action. In an HTML+MathML context HTML is perhaps the _most likely_ language that might be used for annotations, however this is unusable as currently specified.

I have added a small file as a typical use case example.


The attached file shows the same mathml expression first with each subterm annotated by an "unknown" element <zzz> this all works as expected, the mathMl renders correctly (in Firefox 4 beta 2) and its view source shows the DOM is as expected, matching the tree implied by the markup.

the second example in the file shows the same example but this time annotated using html <div>. Here the MathML fails to render correctly at all (in Firefox 4 beta 2) as the html annotation has forced the closing of the math element so the majority of the expression is no longer inside <math> Firefox's view selection shows the following DOM fragment

    <math>
     <semantics>
      <mi>x</mi>
      <annotation-xml></annotation-xml></semantics></math><div>the variable</div>


     <semantics>
      <mo>=</mo>
      <annotation-xml><div>assignment</div></annotation-xml>
     </semantics>
     <semantics>
      <mfrac><mn>1</mn><mn>2</mn></mfrac>
      <annotation-xml><div>the value</div></annotation-xml>

     </semantics>
Comment 13 Ian 'Hixie' Hickson 2010-08-18 17:57:11 UTC
I don't understand the example. What's the actual use case? Annotation? Wouldn't <mtext> be the way to do annotation?
Comment 14 David Carlisle 2010-08-19 01:12:39 UTC
(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.
Comment 15 David Carlisle 2010-08-19 10:23:30 UTC
(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?

another example is given in the mathml spec

http://www.w3.org/TR/MathML3/chapter6.html#interf.graphics

the first child there is content mathml so not directly relevant to mathml-in-html but 

 <apply>
    <intersect/>
    <ci>A</ci>
    <ci>B</ci>
  </apply>


could be changed to <mrow><mi>A</mi><mo>&cap;</mo><mi>B</mi></mrow>
and the example would still stand.
Comment 16 Ian 'Hixie' Hickson 2010-08-19 18:12:03 UTC
Well I can't speak for MathML, but I do consider it my responsibility to consider how HTML is going to be used, that's the only way I can make informed decisions on how to write the spec!

Would it be acceptable to have <annotation-xml encoding="text/html"> be the way to escape back out to HTML?
Comment 17 David Carlisle 2010-08-19 20:59:47 UTC
(In reply to comment #16)
> Well I can't speak for MathML, but I do consider it my responsibility to
> consider how HTML is going to be used, that's the only way I can make informed
> decisions on how to write the spec!

well yes, but some things are expressly extension points that when specifying the language you want to ensure can carry information or be used for future as yet un-thought of uses, but by default be ignored. data- attributes in html5 being a good example. annotation-xml is essentially exactly the same as data- attributes except that math(ml) terms being structurally more complicated typically require structured annotations hence the need for an element based attribution mechanism rather than simply using xml/html attributes. So in an ideal world (which may not be the world we live in) the default behaviour of the html parser would, at minimum, always parse correctly to the end of the annotation without messing up the rest of the expression, even if the annotation was put in the wrong namespace or even discarded it would be better than the behaviour shown in the attached example where annotating a subterm kills the entire expression.
> 
> Would it be acceptable to have <annotation-xml encoding="text/html"> be the way
> to escape back out to HTML?

Actually we had a Math WG telecon this afternoon and discussed this as one of the possibilities. We weren't sure whether making the parsing of the content depend on an attribute value would fit into the the html parser's world view. I assume from your comment that this would be possible. This would certainly be a lot better than the current behaviour.  Personally as I mention above I'd have hoped it were possible to ensure that the annotation could always be parsed to correctly find the end (assuming the content is well formed) however if that is too difficult (either for you to do, or for us to persuade you to do it) I suspect that using an attribute to switch the behaviour may in fact be acceptable, but at this point you'd better not take my word for it: I'll take this to the WG and report back.
Comment 18 Ian 'Hixie' Hickson 2010-08-19 21:23:40 UTC
As far as the parser being dependant on attributes goes, we've unfortunately already crossed that bridge, so I wouldn't worry about it.
Comment 19 Ian 'Hixie' Hickson 2010-08-19 21:26:30 UTC
Oh and we could make the value be application/xhtml+xml instead of (or as well as) text/html, to be more pragmatic about making polyglot documents possible — basically the trade-off there is between making polyglot documents and transitioning between HTML and XML possible, and making people understand that text/html isn't XML and has different parsing rules. Things won't just work magically — making a polyglot document is a lot of work and may not be especially wise, all things considered.
Comment 20 Ian 'Hixie' Hickson 2010-08-19 21:28:51 UTC
Oh another option is to just always assume <annotation-xml> is an HTML integration point (as we do with the <mo>/<mi>/etc elements), but then we wouldn't support the Content MathML stuff there, you'd have to give a <math> element to get back to MathML. I assume that's a non-starter.
Comment 21 David Carlisle 2010-08-19 21:42:30 UTC
(In reply to comment #20)
> Oh another option is to just always assume <annotation-xml> is an HTML
> integration point (as we do with the <mo>/<mi>/etc elements), but then we
> wouldn't support the Content MathML stuff there, you'd have to give a <math>
> element to get back to MathML. I assume that's a non-starter.

Actually that was one of the other options the WG discussed earlier today.
Personally I think I may prefer it as it would have the good property (I think) of meaning that if the annotation has well formed content it will always be parsed completely, but perhaps have elements placed in the wrong namespace (if <math> is not used)

For many uses that wouldn't matter (as the attribution isn't actually used, it's just some mathml generating tool has added some annotations as possible fallbacks.
If you wanted to make the annotation render (I think) you'd have to use some javascript to re-namespace the mathml elements back into the mathml namespace, which is a bit of a pain but perhaps easy to explain (text/html parsing doesn't really do xml namespaces) and certainly a lot easier to fix up than trying to fix up the parse tree after the current html parser has forced the surrounding math element to close.
Comment 22 Henri Sivonen 2010-08-23 14:50:39 UTC
(In reply to comment #18)
> As far as the parser being dependant on attributes goes, we've unfortunately
> already crossed that bridge, so I wouldn't worry about it.

We only crossed the bridge for backwards compat purposes. MathML in text/html isn't about backwards compat in the same sense.

Also, so far, we've only crossed the bridge in the sense of comparing an attribute value ASCII case-insensitively with a constant, so full-blown MIME parameter parsing craziness wouldn't be backed by any precedent. (I'm mentioning this for completeness, since the proposed value looks like a MIME type.)
Comment 23 David Carlisle 2010-08-23 16:58:47 UTC
(In reply to comment #19)


> Oh and we could make the value be application/xhtml+xml instead of
> (or as well as) text/html,

After some discussion by the Math Working Group of various alternatives,
we would like to state a preference that

annotation-xml be parsed as currently specified (defaulting to mathml namespace) unless the encoding attribute is either text/html or application/xhtml+xml in which case it should be parsed more like mtext with element content defaulting to html (and any nested html elements not causing the math expression to be terminated).

We did consider the simpler alternative you suggested in comment #20 of just always parsing annotation-xml like mtext, however the real problem there is that when using the html parsing rules any xml /> empty element syntax would have parsed as a start tag rather than an empty tag, and this is much harder for any script to correct than "just" being in the wrong namespace. Having the default behaviour be to put an unusable annotation in the DOM seemed too dangerous.
Comment 24 Ian 'Hixie' Hickson 2010-08-23 22:14:51 UTC
Ok, I can work with that.

Henri: it would be a case-insensitive comparison in the same way, no MIME type parsing.
Comment 25 Henri Sivonen 2010-08-25 11:52:29 UTC
(In reply to comment #24)
> Ok, I can work with that.
> 
> Henri: it would be a case-insensitive comparison in the same way, no MIME type
> parsing.

However, with <input type=hidden>, the attribute value affects the processing of the token itself. In this case, the processing of subsequent tokens would be affected, so a new single-purpose bit on the stack nodes needs to be introduced.

Also, if <annotation-xml> starts taking HTML content like <div> in the attachment, you need to make <annotation-xml> scoping (just like <foreignObject>), since otherwise stuff breaks when <math> is a descendant of <p>.
Comment 26 Ian 'Hixie' Hickson 2010-08-26 19:01:57 UTC
Yes, we would have to be careful about that. Could you clarify whether you are arguing that we should not do this, or whether you were just pointing out these problems as things to be careful about?
Comment 27 Henri Sivonen 2010-09-01 14:10:37 UTC
(In reply to comment #26)
> Could you clarify whether you are
> arguing that we should not do this, or whether you were just pointing out these
> problems as things to be careful about?

I don't really know if I'm arguing that we shouldn't do this. I'm a bit nervous about adding features this late and I'm skeptical about the utility of this feature. OTOH, better now than later.
Comment 28 Simon Pieters 2010-09-08 08:42:44 UTC
Another option is to make <annotation-xml><div> special.
Comment 29 Ian 'Hixie' Hickson 2010-09-26 03:04:00 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below (based on comment 23 and comment 25)
Rationale: I've tried to add this. I don't know if it's a great idea; I'm not convinced the use cases are really that compelling, but I don't know MathML well.

At this point it's up to implementors. If implementors don't think this is compelling and thus don't implement it, then I'll remove it from the spec again.
Comment 30 contributor 2010-09-26 03:04:21 UTC
Checked in as WHATWG revision r5509.
Check-in comment: Support <annotation-xml encoding='text/html'> in the parser. (experimental)
http://html5.org/tools/web-apps-tracker?from=5508&to=5509