> What I would be proposing for HTML5 is just the following list of
> elements:
>
> math, mrow, mfrac, msqrt, mroot, mstyle, merror, mpadded, mphantom,
> mfenced, menclose, msub, msup, msubsup, munder, mover, munderover,
> mmultiscripts, mtable, mlabeledtr, mtr, mtd, maction
I don't like mlabeledtr very much (I have already expressed my views
about it to folks of the MathML WG), and would hope that they will take
my suggestion for <mtr label="..."> in MathML3. The former is
unnecessarily bloated and doesn't degrade gracefully at all with
renderers that don't support it (not to mention that it is hard to fit
in Gecko's existing table code).
However, your list misses some key tags, in particular leaf tags such as
<mspace/> -- which is sometimes quite useful. Also, <mprescripts/> and
<none/> are needed in <mmultiscripts> (albeit it can be argued that
<none/> is the same as <mrow></mrow> or an empty <mspace/>, but the
differentiation is worthwhile).
In general, I would prefer the list to at least include all the tags
that we already support, and which existing webpages have come to depend
on. This effectively boils down to your list above, excluding
<mlabeledtr>, and including <mspace/>, <mprescripts/>, <none/> and
<mi>, <mn>, <ms>, <mtext>, <mo>. In particular, <mo> is a vital tag as
it is at the heart of those stretchy MathML characters.
Implementation-wise, as this inclusion of MathML-in-HTML5 marks the
beginning of tag soup, it may be that the HTML parser would have to have
some knowledge of leaf tags, so that for example, a stray <mspace>
doesn't become the root of an entire HTML tree... which is later fed to
the hapless MathML engine. (The patch I attached in bug 353926 ignored
the issue.)
---
RBS
On 26/09/2006 3:59 AM, Ian Hickson wrote:
On Sun, 24 Sep 2006, Boris Zbarsky wrote:
Ian Hickson wrote:
We didn't check that <canvas> wouldn't cause clashes, either.
I see. I had assumed that we in fact had.
I don't see why. We don't want a flag for when people can use the storage
APIs. Or when they can use <img> elements. Or whatever.
True, because those are very unlikely to collide with random stuff the pages
are doing (e.g. the storage APIs are using fairly long names that are unlikely
to collide with page-defined functions and variables).
If we think MathML has a similarly low risk of collision, great.
I don't know about "we".
What I would be proposing for HTML5 is just the following list of
elements:
math, mrow, mfrac, msqrt, mroot, mstyle, merror, mpadded, mphantom,
mfenced, menclose, msub, msup, msubsup, munder, mover, munderover,
mmultiscripts, mtable, mlabeledtr, mtr, mtd, maction
...and of those only <math> came up at in the top 1000 elements in my
search of elements on about one billion pages.
According to that same research, <math> is, on the Web, less frequent than
the following elements: <m>, <e>, <rem>, <tab>, <yr>, <prohibits>, <your>,
<lable>, <text-spez>, etc. It was present on less than 0.002% of the pages
the research covered. (To give an idea of scale, <h8> is used on more than
0.003%, so if we avoid <math> because of this, we should probably
introduce <h7> and <h8> into HTML, since we're saying that's an important
enough level to worry about.)
Now, of course, it could be that those 0.002% of pages are all hugely
important and that we'll break the Web in adding this feature. We can't
know until we've tried.
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
