Re: several messages about New Vocabularies in text/html

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.


                                    -- Bill

Received on Friday, 4 April 2008 17:30:20 UTC