Re: embedded TEXT elements

>1. I wonder to what degree the standard supports nesting of text and
>math within math.  String literals support a form of text, but I have
>in mind a structure such as
>
>   <math>
>     .... <text> ... <math mode=inline> ... </math> ... </text>
>     ....
>   </math>
>
>....  Often nesting is a more
>natural mode of markup than alternation between text and math in
>these situations.
>
>I understand the math interpreter will have to handle SGML-style
>notations in reading entities and math markup, but do we have in
>mind that the math interpreter also has to interpret standard
>HTML code in a text element within math?  (And further interpret
>math within that text element?)

You're absolutely right about the need for the math interpreter
to interpret standard HTML code within a MATH element (and not even
just within a TEXT element, I think, but, for example, links
and anchors and perhaps other HTML elements embedded directly
within the MATH element).

(I alluded to this in the proposal by including
    <li>embedded html elements of various kinds (e.g. links)</li>
in the list at the end of topics to be dealt with later. I meant to
refer to the whole set of HTML elements that should be includable,
including TEXT.)

I think one of the pieces of work we need to do right away is to
understand the set of HTML elements that we need to support
embedded in a MATH element. (And this is something that
will have to be specified in order to write a MATH DTD extension
of an HTML 3.0 DTD.)

One tehcnical issue of some difficulty is how these embedded elements
can be supported by a "plugin math module". For example, to let the
parent browser fully support anchors within MATH (e.g. to parts of
formulas), it would either be necessary for the plugin interface to have a
way of asking the "math rendering object" it communicates with
(which is implemented by the math-specific code of the plugin)
whether a given anchor is present in the MATH element, or
for the parent browser to parse certain HTML elements within the formula
(at least). I doubt this interface supports either of these, and if not,
supporting this feature will be technically impossible for a plugin.

As for support of text by a plugin, it will be possible, though it
may require duplication of the parent browser's behavior for this
within the plugin code. I think the effort for this is not impossibly
great (and in any case required) for nested TEXT/MATH constructs
such as your example above (and also for things like font changes
purely within the math).