mlabeledtr
Torsten Bronger
Is it a good idea to produce <mlabeledtr> elements in MathML output
that is supposed to be viewed with Mozilla? I know that it's not
yet implemented, I just want to know whether it's worth switching to
<mtr> in the meantime.
Tschoe,
Torsten.
Bernhard Keil
in Mozilla and the implementation in MathPayer
does not put the label (equation number) at
the right margin of the page (istead it positions the
label width a constant distance right beside the
<mtable> matrix.
So I think an acceptable solution working
in IE and Mozilla is using a html table,
like this:
(this makes sure that the equation number is at the
right margin of the page)
<table width="100%">
<tbody>
<tr>
<td style="width:95%" align="center">
<math display="block" xmlns="http://www.w3.org/1998/Math/MathML">
<mi>Y</mi>
<mo>=</mo>
<msup>
<mi>X</mi>
<mn>2</mn>
</msup>
</math>
</td>
<td align="right">
<a id="eq_1">(1)</a>
</td>
</tr>
</tbody>
</table>
Torsten Bronger <bro...@physik.rwth-aachen.de> wrote in message news:<m3y92er...@wilson.rwth-aachen.de>...
Roger B. Sidje
> Halloechen!
>
> Is it a good idea to produce <mlabeledtr> elements in MathML output
> that is supposed to be viewed with Mozilla?
No, it is not a good idea. It is not yet implemented and won't be for a
while since leveraging the table code for that is hard.
I wonder why there is a <mlabeledtr> element at all? Should have been a
simple attribute, <mtr label="mylabel">, no? As it stands, <mlabeledtr>
creates a U-turn in the DOM (picture it: n+1 cells on <mlabeledtr>
while every other <mtr> has n cells), meaning a flurry of special-casing
every where (table code, DOM walking, selection, JavaScript'ing for
authors, etc). And probably the worst resulting consequence is that it
doesn't degrade gracefully.
Seems to me that an attribute could have provided a better trade-off
since most labels are just character data anyway, or can be made to be
character data. Optimizing for the common cases isn't that bad compared
to having an element whose deployment is hampered from the onset (i.e.,
authors are afraid to use it as they are never sure what will happen,
e.g., witness questions such as yours, and the suggested
hacks/work-arounds that people are already devising). I don't remember
to have used a label that wasn't (or couldn't be) character data. Do you?
---
RBS
Steve Swanson
news:3EA460...@maths.uq.edu.au...
> Torsten Bronger wrote:
> > Halloechen!
> >
> > Is it a good idea to produce <mlabeledtr> elements in MathML output
> > that is supposed to be viewed with Mozilla?
>
> No, it is not a good idea. It is not yet implemented and won't be for a
> while since leveraging the table code for that is hard.
>
> I wonder why there is a <mlabeledtr> element at all? Should have been a
> simple attribute, <mtr label="mylabel">, no? As it stands, <mlabeledtr>
> creates a U-turn in the DOM (picture it: n+1 cells on <mlabeledtr>
> while every other <mtr> has n cells), meaning a flurry of special-casing
> every where (table code, DOM walking, selection, JavaScript'ing for
> authors, etc). And probably the worst resulting consequence is that it
> doesn't degrade gracefully.
Or how about an <mtrlabel> element which gives the label for the next or
previous <mtr>? It feels a little funny to have attribute data appear in
the presentation, as you suggest, but no stranger than the <mlabeledtr>
elements.
Oftentimes, the labels are just sequential counters. Does anyone know if CSS
counters can be used in this situation? (Ignoring the fact that Mozilla
doesn't implement this, either.)
Steve Swanson steve....@mackichan.com
MacKichan Software, Inc. http://www.mackichan.com
Torsten Bronger
"Roger B. Sidje" <r...@maths.uq.edu.au> writes:
> Torsten Bronger wrote:
>> Halloechen!
>> Is it a good idea to produce <mlabeledtr> elements in MathML output
>> that is supposed to be viewed with Mozilla?
>
> No, it is not a good idea. It is not yet implemented and won't be for a while
> since leveraging the table code for that is hard.
Okay. Then please have a look at the following LaTeX code:
\begin{eqnarray}
1+1 &=& 2 \label{simple}\\
2+5 &=& 7 \nonumber
\end{eqnarray}
What's the best way to prepare this in MathML for Mozilla?
Tschoe,
Torsten.
Roger B. Sidje
>
> Or how about an <mtrlabel> element which gives the label for the next or
> previous <mtr>? It feels a little funny to have attribute data appear in
> the presentation, as you suggest,
Actually, it is still self-contained. And BTW, there is already
<ol start="mystart"> ... </ol> to generate a numbering that starts
at "mystart" in the presentation.
> but no stranger than the <mlabeledtr>
> elements.
"_less_" stranger...
> Oftentimes, the labels are just sequential counters. Does anyone know if CSS
> counters can be used in this situation? (Ignoring the fact that Mozilla
> doesn't implement this, either.)
To position the label yourself with CSS will be so much hassle that you
won't go far. Imagine having to manually find/update the CSS position
everytime you add/change/replace some labels. Plus, it is not going to
be portable with other renderers.
---
RBS
Roger B. Sidje
Torsten Bronger wrote:
>
> Okay. Then please have a look at the following LaTeX code:
>
> \begin{eqnarray}
> 1+1 &=& 2 \label{simple}\\
> 2+5 &=& 7 \nonumber
> \end{eqnarray}
>
> What's the best way to prepare this in MathML for Mozilla?
Just use a <mtable> with an extra "labeling column" in which the cells
are empty, except those cells with the contents of labels.
---
RBS
Torsten Bronger
"Roger B. Sidje" <r...@maths.uq.edu.au> writes:
I changed now my XSLT style sheets: I substituted <mtr> for
<mlabeledtr> and moved the first <mtd> to the last position. (*)
This means that I produce broken MathML for the first time, it
wouldn't look as nice as it used to do in MathPlayer, and I have to
mark the source carefully in many places so that I can restore
everything when support for mlabeledtr is better.
Why is it so difficult to mimic (*) within Mozilla's MathML
routines?
Tschoe,
Torsten.
Roger B. Sidje
>
> I changed now my XSLT style sheets: I substituted <mtr> for
> <mlabeledtr> and moved the first <mtd> to the last position. (*)
> Why is it so difficult to mimic (*) within Mozilla's MathML
> routines?
Because that's not how it works :-) There is a DOM in which you can't
shuffle things as your are suggesting. And what about
'[' matrix ']' with label on row 1 after the bracket. There are other
pieces that assume a n-by-n DOM grid, and do all sort of voodoos (e.g.,
fixups, multispans, editor interaction, etc) which have taken years for
Netscape/Mozilla people to get right and so are sensitive. Nobody has
really investigated what <mlabeledtr> might touch. There are some nice
things about being an integrated renderer, but that also comes with
other aspects which I alluded to in my earlier post (table code re-use,
DOM, selection, JavaScript'ing for authors, etc).
Speaking of this, it just occurred to me that another good example for
<mtr label="..."> is our own <mfenced open="..." close="..."> which adds
content to the presentation.
---
RBS
Steve Swanson
> ...
> Speaking of this, it just occurred to me that another good example for
> <mtr label="..."> is our own <mfenced open="..." close="..."> which adds
> content to the presentation.
> ---
> RBS
>
I've never liked this construction, either. Why not a more structured markup
like <mfenced> <open>...</open><close>...</close><body>***</body>
</mfenced>?
BTW I'd been told that mfenced was deprecated. But the current MathML spec.
doesn't say anything like that.
Robert Miner
> BTW I'd been told that mfenced was deprecated. But the current MathML spec.
> doesn't say anything like that.
It's not deprecated, just disliked (in some quarters anyway).
--Robert
------------------------------------------------------------------
Dr. Robert Miner Rob...@dessci.com
MathML 2.0 Specification Co-editor 651-223-2883
Design Science, Inc. "How Science Communicates" www.dessci.com
------------------------------------------------------------------