- From: William F Hammond <hammond@csc.albany.edu>
- Date: Tue, 10 Oct 2006 17:56:07 -0400
- To: www-math@w3.org
"White Lynx" <whitelynx@operamail.com> writes: >> Beyond that I would like to see the HTML elements <a>, <em>, and >> <b> (or <strong>) incorporated in the XHTML+MathML document type >> definition as elements that are allowed in <mtext>. > > Technically you can't do such a things in DTD, if you allow em, b, a > in mtext then you effectively allow all inline elements (including > MathML math) to be descendands of mtext element (however such a > compound of HTML and MathML, probably, can be properly defined in > RelaxNG). It is not a problem in HTML5 as it has no DTD/Schema at > all. > >> > Is <b> really needed, when one has <mstyle mathvariant="bold"> (which >> > works everywhere in MathML)? >> Yes, <b> (or something) is needed. > > It is there even if it is not needed. > >> <mstyle> is not allowed in <mtext> even though Mozilla seems to >> tolerate it there. > > You can use something like <mtext>normal text </mtext><mtext > mathvariant="bold">bold, </mtext><mtext mathvariant="italic">italic, > </mtext><mtext mathvariant="monospace">teletype</mtext> I guess the spec does allow the use of mathvariant with mtext. Now that I think more about it, AFAIK Mozilla's implementation of the mathvariant attribute is entirely CSS dependent. (Is this right?) However, even if one is not getting into trouble with math style vs text style in using "mathvariant" with "mtext" (for example, by using "font-family" in CSS with a selector tied to any use of "mathvariant" or calling for the value "double-struck" in <mtext>), I think consecutive <mtext> elements for style variations is uselessly messy. It also needlessly adds to the semantic analysis of the enclosing "mrow". A new element <mspan>, allowing only pcdata in content and usable only in mtext would be better. To avoid confusion with HTML's <a> (which does now work inside "mtext" in Mozilla with a namespace hook) and the limitations of formal doctype specifications and also to avoid namespace issues in parallel HTML5, why not bring up a new element "mlink" with attribute "href" and content model (#pcdata|mspan)* usable only in "mtext". It should be entirely equivalent via XSLT (when that is available) to profiled use of <mtext> with xlink/href. On a point raised a while ago: strictly presentational non-semantic use of xlink/href in XHTML+MathML with <mrow> rather than <mtext> strikes me as undesirable. -- Bill
Received on Tuesday, 10 October 2006 21:56:24 UTC