Closed Bug 356870 (mlabeledtr) Opened 13 years ago Closed 8 years ago

mlabeledtr disallowed

Not set

RESOLVED FIXED
mozilla9

Attachments

(2 files, 1 obsolete file)

 3.97 KB, text/html Details 1.23 KB, patch karlt : review+ Details | Diff | Splinter Review
In the course of fixing bug 347355, I added this snippet in mathml.css

+/* Don't support mtr without mtable, nor mtd without mtr */
+:not(mtable) > mtr,
+:not(mtr) > mtd {
+  display: none !important;
+}

This was also shown to be of effect in bug 348492.

I have now got a feedback that the CSS may be too harsh, and that it should perhaps be relaxed so that <mlabeledtr> (which we don't support) is possible for content-providers who want to refer to it. The suggestion is to split the rules, and only put important on one rule, i.e.:

>   /* Enforce no support for mtr unless in mtable */
>   :not(mtable) > mtr {
>     display: none !important;
>   }
>
>   /* Don't support mtd unless in mtr */
>   :not(mtr) > mtd {
>     display: none;
>   }

Note: as a UA, there isn't much point having the second rule without !important. So if we are to take this, we might either just take the first rule, or change the second to include mlabeledtr with important, but I don't want to reference mlabeledtr since we don't have a supporting code for it, and users who look at mathml.css and see a selector with mlabeledtr may be misled into thinking that it is supported.
The "!important" on "not(mtr) > mtd" in "mathml.css" has a significant adverse effect (whole formulas drop out of sight) on legacy XHTML+MathML documents
generated by GELLMU since September 2004, and, moreover, it excludes all use of "mlabeledtr", which _can_ be given usable Mozilla rendering with easy CSS help and _is_ supported by other user agents.  Thanks.


QA Contact: ian → mathml
Blocks: mathml-2
Assignee: rbs → nobody
Alias: mlabeledtr
MathJax is going to add support for equation labeling and referencing, which is likely to be an important new feature:

https://github.com/mathjax/MathJax/issues/71

The labeling relies on mlabeledtr, so it would be good to fix this bug.

(In reply to William F. Hammond from comment #1)

> moreover, it excludes all use
> of "mlabeledtr", which _can_ be given usable Mozilla rendering with easy CSS
> help and _is_ supported by other user agents.  Thanks.

Do you have a proposal for something that could be added in our CSS stylesheet?
http://mxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css
Without the blocking of mlabeledtr by lines 257-260, a content provider can
use CSS color to distinguish the (first) label cell from a normal cell with
something like:
mlabeledtr {
display: table-row;
}
mlabeledtr > mtd:first-child {
color: #004400;
background-color: #fafffa;
}
But the mathml spec describes positioning for the rendered label that this will
not address, and the colors here need to provide sufficient contrast with other
colors.

This same color effect can also be done with "mtr[class='labeled']" instead of
"mlabeledtr".

Without
The lack of support for mlabeledtr is likely to make MathJax v2.0 use the HTML-CSS by default instead of our native rendering:

https://github.com/mathjax/MathJax/issues/71

I'm going to attach a workaround to relax the condition and allow to use mlabeledtr in mtable.
Attachment #561588 - Flags: review?(karlt)
(In reply to Frédéric Wang (:fred) from comment #5)
> Created attachment 561588 [details] [diff] [review]
> allow mlabeledtr to be used in mtable

Probably we don't want mlabeledtr without mtable too...
Comment on attachment 561588 [details] [diff] [review]
allow mlabeledtr to be used in mtable

(In reply to Frédéric Wang (:fred) from comment #6)
> Probably we don't want mlabeledtr without mtable too...

I don't know all the details behind bug 347355, but comments suggest that the display:none rules are no longer necessary for safety, in which case I don't see them as important.

Perhaps it would be worth adding another crashtest like that for bug 347355 but with mlabeledtr instead of mtr, to confirm?
Attachment #561588 - Flags: review?(karlt) → review+
CCing Jesse to check his tests know about mlabeledtr.
Added mlabeledtr to the DOM fuzzer.
The alignment will be incorrect for an mtable that uses both mlabeledtr and mtr rows. This can probably be fixed by adding cell frames in nsMathMLmtableFrame.cpp (I don't know exactly how and where)

Otherwise, we can do

mlabeledtr > mtd:first-child {
display: none;
}

to hide the label (without !important, so that users will be able to override this setting).
Attached file testcase
Or maybe a cleaner way would be to do

mlabeledtr {
display: -moz-labeled-table-row;
}

and implement such a private CSS property on the layout side, but I even less idea which part of the code should be modified.
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=355250067020
Attachment #561588 - Attachment is obsolete: true
The former patch used invalid CSS... I've fixed this and add an overridable rule to hide the label for now. Thus the rendering will be the same as the workaround made by MathJax for Firefox+nativeMML.
Attachment #562167 - Flags: review?(karlt)
Comment on attachment 562167 [details] [diff] [review]
allow mlabeledtr to be used in mtable - V2

(In reply to Frédéric Wang (:fred) from comment #14)
> rule to hide the label for now.

Sounds a good compromise.
Attachment #562167 - Flags: review?(karlt) → review+
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=74d9def9c9de
Keywords: checkin-needed
Assignee: nobody → fred.wang
Hardware: x86 → All
https://hg.mozilla.org/integration/mozilla-inbound/rev/36d40fbb0106
Status: NEW → ASSIGNED
Keywords: checkin-needed
Target Milestone: --- → mozilla9
https://hg.mozilla.org/mozilla-central/rev/36d40fbb0106
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Keywords: dev-doc-needed
Does this make mlabeledtr work, or just make it not fail spectacularly?
(In reply to Eric Shepherd [:sheppy] from comment #19)
> Does this make mlabeledtr work, or just make it not fail spectacularly?

The latter. See bug 689641
Added a note to Firefox 9 for developers.
You need to log in before you can comment on or make changes to this bug.