From: William F Hammond <hammond@csc.albany.edu>

Date: Fri, 04 Apr 2008 13:29:37 -0400

To: public-html@w3.org, www-math@w3.org

Message-ID: <i7wsndwmta.fsf@hilbert.math.albany.edu>

Date: Fri, 04 Apr 2008 13:29:37 -0400

To: public-html@w3.org, www-math@w3.org

Message-ID: <i7wsndwmta.fsf@hilbert.math.albany.edu>

David Carlisle <davidc@nag.co.uk> writes: > ... > While this is a lot better than not allowing math at all (or not > allowing xml markup in semantic annotations), it is incompatible with > (and less useful than) what is implemented in mozilla for xhtml+mathml > where > <math><mtext><b>foo I gather the math WG for some reason doesn't want to "adopt" a small number of html elements allowed for use only in <mtext>: <strong>, <em>, <a>, and <span> come to mind. (Isn't it correct that a semantic MathML consumer like a computer algebra system does not look inside <mtext>?) Alternatively roll out a new presentation mathml container, say <mspan>, for explicitly escaping math-semantics, that allows a small number of adopted html elements. Of course an anchor can be made in <mtext> per the mathml2 spec by breaking the <mtext> up into segments so that there is a single xlinked <mtext> that houses the visible anchor text, but this is rather cludgy. >> The key to avoiding the problem is the variant on Simon's idea, which is >> to hard-code all the HTML element names and cause them to automatically >> close the "namespaced" scope. > > I still don't see why they can't be recognised and go back to a > (nested) html Yes. > That assumes that all browsers will use a monolithic model like mozilla > where the rendering is being implemented natively or being accessed by > specific extension elements such as <object>. There is another model, > which has its problems certainly, but is potentially more flexible, > where the browser's parser only has to be able to parse the tree (without > special knowledge of all the tags involved) but that specific elements > are handled by external processors. this is of course the model IE > uses. the details of how one registers the external procesors to handle > specific elements are arcane (and apparemntly changing again for IE8) > but the design of html5 shouldn't preclude (or force) this design. With "external" processors one should not forget the importance of interface hooks for things like font scaling Note. An implementation that spawns subordinate processing, whether "internal" or "external", for inline math content should not automatically assume that the math content should be surrounded by whitespace. This is a sensitive matter at the end of a sentence. So as things are now for xhtml+mathml in some user agents, with the markup <p>The value is <math><mn>5</mn></math>.</p> the author risks having the period stranded at the beginning of the next line. The unpleasant workaround: <p>The value is <math><mn>5</mn><mtext>.</mtext></math>.</p> where the math is css-styled with nowrap white-space. -- BillReceived on Friday, 4 April 2008 17:30:20 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 29 September 2014 09:38:54 UTC
*