In order to support special characters such as blackboard characters (a.k.a double-struck characters), MathML 2.0 has introduced a mathavariant attribute so <mi mathvariant="double-struck">R</mi> means renders 'IR' (i.e., double-struck R). See, e.g., http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miequivalents11.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/mimathvariant13.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/mimathvariant14.xml To support this, I have been thinking of adding recognition of new -moz values for |font-variant|: font-variant: -moz-script | -moz-fraktur | -moz-double-struck (currently |font-variant| only supports |small-caps|). With the proposed extension, the text transformer in nsTextFrame could query the font.variant flag and do the necessary genuflections. Bug 114365 comment 2 describes the full scope of the issues needed to support this mathvariant attribute. This bug is a sub-task in the chain. I might take the bug later.

Should this be font-variant or font-style?

If there are still available bits in nsFont::style, it might well be a font-style thing.

I might also have to update nsFontMetricsWin.cpp because it erroneosuly treats mFont.style as a bitfield: logFont->lfItalic = (mFont.style & (NS_FONT_STYLE_ITALIC | NS_FONT_STYLE_OBLIQUE)) ? TRUE : FALSE; // XXX need better oblique support It should be using an equality test (other platforms use an equality test).

I am leaning toward s/-moz-script/-moz-calligraphic/g, what do you think? -moz-script seems prone to confusion in a browser context. With that, the rules will read: [mathvariant="script"] { font-style: -moz-calligraphic; } [mathvariant="bold-script"] { font-style: -moz-calligraphic; font-weight: bold; }

I think I prefer -moz-calligraphic, since that is closer to what the font variant is called in AMS LaTeX. ;) For that matter, we could use -moz-blackboard-bold as well, if we want....

Taking, and updating the title to reflect the new state of the matter.

r=hixie on the patch; can we see where these new styles are going to be used? What happens if I say: p { font-style: -moz-blackboard; } <p>Hello World</p> ...? Will it get drawn in a special font style?

It will be drawn with double-struck letters as seen here: http://www.mozilla.org/projects/mathml/fonts/encoding/math5.gif The plan is to tweak the text transformer so that it remaps each ASCII character to a private encoding before passing it to GFX. Hence the fix won't have to suffer from the zillion versions of GFX this time. Not sure how this fits with CSS3. While Mozilla can get this with the math fonts, it is going to be a lot harder for other user-agents to emulate this since the glyphs are not found in ordinary fonts, and no OS (to my knowlegde) distinguishes these fonts as they do for cursive, serif, sans-serif, etc. Though these glyphs are nice-to-have, as this web page shows (c.f. comments in the sidebar): http://www.fontmenu.com/site/calligraphy.html Also of note: the Math WG has successfully lobbied to get _some_ of these glyphs into Unicode, but unfortunately these are in plane-1 (that's where the question marks in testcase miequivalents11.xml come from). So the support of mathvariant will still resort to internal assignments to the PUA for cross-platform portability.

...in a sense, it is like this 'font-effect' that seems to be there just to guarantee that no implementation can match a spec :-) http://www.w3.org/TR/2002/WD-css3-fonts-20020802/#font-effect

This totally fell off my radar.. rbs, do you need reviews on that patch or an updated version thereof?

No, I don't need a review right now. There is no update. I lost my M$ hard-disk with all the laborious WIP that I was doing to support |mathvariant| per bug 114365. Bad sectors that prevented the M$ OS to even boot. Had to buy a new disk.

Do we still want this? Those haven't been added in CSS3 by the way and that module has past last call (css3-fonts).

"Do we still want this?" Yes! At least we (I) want the mathml mathvariants script, fraktur and double-struck to be supported, whether that be done via css or other means. With STIX fonts installed, the relevant plane-1 blocks seem to work fine in firefox.

Why not use Unicode. For example http://en.wikipedia.org/wiki/Blackboard_bold \mathbb{R} U+211D ℝ Represents the real numbers.

I don't think overloading this onto font-style makes sense at all. Either use the Unicode codepoints specifically designed for this purpose or use an OpenType feature to enable a variant via font-feature-settings. The font-style property is used to select a face within a family, one that generally has a full set of glyphs in that style (e.g. italic) and that doesn't seem appropriate when your use case is specific variant glyphs for a subset of characters. If you still feel this is needed, I would suggest proposing it on the www-style mailing list.

I agree that font-style may not really be what we want for mathvariant. Currently, it seems there is some code to remap BMP chars to style invariant chars in layout/mathml/ but I can't find where it is used. I only see a particular case (to make italic <mi> with a single character) in nsMathMLTokenFrame. It would be simple if we could use a -moz-font-feature-settings in layout/mathml/mathml.css, but is it possible to implement mathvariant values that way? I think the mathvariant property should be implemented somewhere in the style system rather than in the MathML code.