Closed
Bug 39411
Opened 24 years ago
Closed 23 years ago
Default style rules for <mtable> need tuning
Categories
(Core :: MathML, defect, P3)
Core
MathML
Tracking
()
RESOLVED
FIXED
mozilla0.9.9
People
(Reporter: rbs, Assigned: rbs)
References
()
Details
(Keywords: helpwanted, Whiteboard: [Hixie-P3] mathml:mtable)
While full and proper support of <mtable> is not yet there, mathml.css needs appropriate style rules for <mtable> and its related elements so that <mtable> can yield interesting layout in common situations. [http://lxr.mozilla.org/seamonkey/source/layout/mathml/tests/mathml.css] One particular problem with the current rules is that they leave a spacing around the table. Hence if for example someone does v = ( <mtable>column_vector_here</mtable> ), there is an ugly gap between the stretchy parenthesis and the mtable content... Of interest are also rules to map things like <mtable rowlines="solid">, <mtable columnlines="solid"> (as per the description given the URL). With MathML-enabled binaries now available, hope you now have a setup to try things out :-)
Comment 1•24 years ago
|
||
Accepting for now, but I am currently overwhelmed by Layout bugs so moving to M20 for now... :-/
Status: NEW → ASSIGNED
OS: Windows 95 → All
Priority: P3 → P2
Hardware: PC → All
Summary: Default style rules for <mtable> need tuning → Default style rules for <mtable> need tuning
Updated•24 years ago
|
Priority: P2 → P5
Not sure if the collapsing table code has changed as of late. I have seeing some ugly layout of <mtable> due to this bug... Any chance you can have a look at it these days?
Here is what is needed by default (all horizontal units are em, all vertical unitis are ex) 0.4em 0.4em /--/-------------------------------------------------/--/ | 0.8em 0.8em | 0.5ex + +---------------/-/--------------/-/--------------+ / | | | | | | | | | | | | | | | | | | content-box | | | | | | | | | | | | | | | | | | | | | | + +---------------+-+--------------+-/--------------+ + | | | | | | 1ex | | + +---------------+-+--------------+-/--------------+ + | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + +---------------+-+--------------+-/--------------+ + | | | | | | 1ex | | + +---------------+-+--------------+-/--------------+ + | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + +---------------+-+--------------+-+--------------+ / | | 0.5ex +-------------------------------------------------------/
Comment 4•24 years ago
|
||
The collapsing borders code is in a rather ugly state right now. I assume in your diagram that the gaps are gaps, not borders, right? I'll try to look at this soon, but no promises...
Yep, the outlines are for illustration only. They show the edges on the content boxes. There are no borders.
Updated•23 years ago
|
Comment 6•23 years ago
|
||
I actually had a look at this, finally. However, MathML tables don't seem to be displaying right at all. See, for example, tests 23 and 24 of the torture test on mozilla.org: http://www.mozilla.org/projects/mathml/demo/texvsmml.xml A small version is available here: http://www.hixie.ch/tests/adhoc/mathml/001.xml I have to fiddle with the font size to get them to either appear at all or to appear as a grid, respectively. So there are two ways I can see to do this: either fiddle with :first-child and :last-child rules and use the separate border model and margins and padding on the cells, which will look bad if anyone uses borders, or use transparent collapsed borders, which will also look weird if people use borders, although less so. The second option is blocked on bug 41262. Which would you prefer? Reading further through the rules in the MathML spec, I'm having some difficulty trying to come up with CSS rules that fully implement what they ask for. As I understand it, they say each element inside an <mtr> is automatically imagined to be inside an <mtd>, but this is "hard" in CSS (i.e., impossible). Also, some of the attributes (e.g. "framespacing") seem to me to require some C++ love. Also, "rowlines" and "columnlines" (and friends), while possible to do in CSS, kind of clash with your request for spacing... I'm not sure how to handle those. Just use the same width as your spacing, but for the lines?
<mtable> is simply mapping to <table>, but at each milestone something seems to go wrong somehere when used in the mathml context. Because it is a direct mapping, if you can customize the rules for a <my:table> to display as required, then that will still be fine in the long run when they are passed to <mtable>. Actually, I don't have any preferences regarding how your do it. Any that works in an efficient way around the existing table bugs will do. The MathML 2.0 spec has now removed these optional 'inferred' <mtr> and <mtd>. So you can safely assume that the table is well-formed in the strict XML sense.
Also don't worry about attributes that need some C++ support. Just setting rules that emulate their default values is fine. Then, these could be overriden later in the C++ side.
Comment 9•23 years ago
|
||
Excellent news about the inferred stuff.
Comment 10•23 years ago
|
||
I had a go at implementing this, but <mtable> elements are not matching the mtable rule in mathml.css. They _are_ matching the :-moz-math-table table. Is this expected? Should I simply style the pseudo-element?
Assignee | ||
Comment 11•23 years ago
|
||
Are things okay when you combine the two: :-moz-math-table, mtable { ... } [I might have to revisit the frame constrution code to eliminate one or the other]
Comment 12•23 years ago
|
||
That should work (merely because the <table> rule is ignored).
Keywords: helpwanted
Whiteboard: [Hixie-P3] → [Hixie-P3] mathml:mtable
Assignee | ||
Comment 13•23 years ago
|
||
Taking the bug & targeting m0.9.9. I have iterated on the code to cover most of what is needed in common situations.
Assignee: ian → rbs
Status: ASSIGNED → NEW
Priority: P5 → P3
Target Milestone: mozilla1.1 → mozilla0.9.9
Assignee | ||
Comment 14•23 years ago
|
||
Improvements checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•