The default bug view has changed. See this FAQ.

MathML attributes are not mapped to style

RESOLVED FIXED in mozilla29



16 years ago
3 years ago


(Reporter: rbs, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




16 years ago
mathml includes a number of attributes which can only be supported if 
they are properly mapped to style. These include, "color", "fontsize",
for example.

The way things work in Gecko is that content elements that wish to map 
attributes to style have to implement a GetAttributeMappingFunctions()
which should return their attribute mapping function:

                      nsMapAttributesFunc& aFontMapFunc,
                      nsMapAttributesFunc& aMapFunc) const

However, mathml is currently implemented without custom made content objects.
Rather, generic XML elements are used, and mathml frames are simply associated
to these content elements based on their tags and the mathml namespace. And all
the details of the rendering are handled by these frames using whatever the
Style System gets from the default CSS rules in mathml.css.

It is not clear to me how to generally reflect mathml attributes into the style
contexts with which mathml frames are created.

Would this requires custom made mathml content objects (i.e., doing what XUL
has being doing and which is going away in the forthcoming refactoring of the
content code). Or, would the refactoring provides an extended mechanism for
others to hook in so that the particular mapping of mathml attributes could
become a non-issue? I will appreciate any feedback/follow-up on this, Gecko 
folks. Do well to remember those of us sitting on the sidelines :-)
cc'ing hyatt who might have some good ideas on how to do this now that he is so
intimately familiar with the style system.

Comment 2

16 years ago
After hyatt's overhaul in bug 78695, the new fucntion is:
                    aMapRuleFunc) const

But the issue remains the same. Without custom-made objects for MathML, there 
doesn't seem a way to map MathML attributes to style. It is not that much of a 
problem if there were custom-made MathML objects since what is done in other 
modules could be replicated for MathML elements as well (it will just add more 
code). I have been holding off doing anything in that respect in the hope of 
first seeing the foundation that will be laid from the proposed plan to 
refactor the content code (bug 69996).
rbs: Unfortuinately, the typedef for that function involves nsIHTMLSyleSheet and
friends - the code is all html specific.

SVG has custom content classes, but it still doesn't help us. See bug 107100. I
think theres another, more specific one, but I can't find it ATM.

Bug 111317 is the svg equivalent to this bug.

Comment 4

15 years ago
I have checked-in a work-around for the problem in the MathML land. The 
work-around has consisted in creating a special internal stylesheet on the fly, 
and populating it by gradually mapping attributes to CSS rules as MathML frames 
get created. For example, if a content has for example, background='green', then 
I insert a CSS rule: [background='green'] { background-color: green }, and the 
support logic in the Style System does the rest... The special sheet is owned by 
the document and so it has the same lifetime as the document.

There were issues with the fact that adding such rules caused a reframe mid-way 
(I am doing this in the Init() methods of the frame construction code). Although 
this first approach was working, it was then causing the popup frame to later 
crash when right-clicking the window to trigger the contextmenu (GetStyleData 
was bad on the primary frame checked by the popup menu). I worked around the bug 
by avoiding the reframe -- and this even gave another win w.r.t. the speed of 
the mapping. Not a luxurious solution to this bug, but works like a charm. And 
it is perhaps indicative of what may be done later to provide generic APIs 
applicable everywhere for such problems.
QA Contact: ian → mathml
Assignee: rbs → nobody
Blocks: 330964, 527201
Depends on: 560100
Blocks: 594420
The private _moz-* attributes used instead a style mapping are:

Depends on: 731667
Depends on: 785956
No longer depends on: 785956
Depends on: 114365
Fixed by the dependencies.
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Target Milestone: mozilla28 → mozilla29
You need to log in before you can comment on or make changes to this bug.