Re: MathML and CSS

David

> I agree some better access to the character content from CSS selectors
> would make things easier for MathML. Substituting - signs etc, as you
> say.
There are three advantages in this approach. First not all people are
really glad to edit Unicode text directly (I mainly mean Plane 1 math 
alphanumericals) so text-transform will simplify coding. 
Second it will simplify styling of math expressions. 
Because putting variables in <mi></mi> containers and applying 
font-style:italic; is not the best solution as in most of fonts
Latins does not look like math variables and italic usually makes
them too slanted (in CSS there is also intemediate font-style:oblique
which theoretically is more suitable for maths but usually not available in 
current fonts). Plane 1 math alphanumericals are specially designed for
mathematics and IMHO are the best solution.
Third advantage was already mentioned here and provides good fallback
mechanism, as there are few fonts that cover Plane 1 maths and some browsers
may not support Plane 1 at all, it is safer to use widespread notations and
CSs text-transform property.



> The reference to TR25 there is rather strange, TR25 (which is of course
> later than all but the last version of MathML) is closely aligned with
> MathML and MathML tracked TR25 through various revisions in the exact
> definition of the variant selector and other things listed in that
>report.
I just meant that MathML does not fully use advantages of Unicode,
in particular I don't like usage of markup like
<mi>a</mi><mo>=</mo><mn>5</mn> that semantically says absolutely 
nothing and is almost merely intended to style variables in italic
(for this purpose one can use corresponding Plane 1 alphanumericals).
In any case this seems to be a little bit offtopic discussion so
lets not to go into details.

> The one part of TR25 that doesn't relate to MathML is its
> somewhat speculative suggestion of a "plain text" unicode mathematics,
> such a system would of course be completely unstylable with CSS, as what
> you call "ugly tag soup" is what some of us would rather call markup,
Maybe but I get used to call markup like XHTML
<p>Simple text</p>
that reflects basic structure of document a MARKUP
and things like
<paragraph><sentence><adj>Simple</adj> <noun>text</noun></sentence></paragraph>
a TAG-SOUP. 

>>(I know that there is also content MathML used by nobody)
>Strange you say that. Have you ever saved MathML from Maple for example?
In any case it is not widely supported.

> It seems to me that the main things
> required to get mathematical layout (from any markup) would be the
> following, all of which are mentioned in your list as well:

> stretchy characters (horizontal and vertical)
Agree. But being more specific there are two possible way to go.
First is to introduce some kind of character stretching properties
in CSS that may require specially designed fonts and does not seem
realistic to me (maybe I am wrong).
Second that we use in our custom XML markup is to avoid stretching
at all. Usually stretching (horisontal/vertical) is needed for 
smart resizing of brackets that I beleive can be replaced with 
appropriate border styles (new border styles will be needed),
also we have to stretch some operators (integrals, sums, products etc.)
however in case of operators I think it is enough to increase font-size.
There are also some stretchy diacristics like tildes or overhats putted
over several characters. I don't know what to do with them. As far as
Unicode does not address this issue maybe it is reasonable to reflect it 
in CSS3 math module (maybe something like math-decoration:tilde is suitable).

> radicals
Agree

> baseline control
Agree


> If you look at being able to do MathML specifically then it would be
> good to have in addition selectors that have access to element content,
> I don't know how feasible that is in a CSS context. For example one
> can't really implement an "operator" dictionary in CSS2 (I think) where
> the default spacing around an <mo> depends on its character content.
> I don't know if any of the currently planned CSS3 extensions would
> support such a thing?

There is  selector :contains() in CSS3 so it is possible to target individual 
operators.

> Then there are some specific layout forms (such as mmultiscripts) 
> which although they could use an inline table model for layout have the
> data specified in a different order. I don't have a good enough feel for
> the kinds of display types envisioned in CSS3 to know whether something
> could be done here or whether you would need to profile mathml and say
> prescripts were not supported (or specify some non-conventional but
> legible rendering of the mmultiscripts construct that _could_ be
> supported by css). Your message seemed to indicate that you thought
> that the CSS3 facilities _would_ be strong enough to do this kind of
> localised data re-arrangement. That would be very useful for math
> layout, Is there an existing CSS3 module that I should re-read?
CSS3 generated and replaced content module 
http://www.w3.org/TR/css3-content
addresses this issue well enough,
(see content, pending and move-to properties). 
However it is better to ask Ian Hickson 
whether this features will be preserved in future versions on module
(it is just WD). If not we will have a lot of troubles not only with 
prescripts.

Best Wishes,
George
-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Received on Wednesday, 19 May 2004 04:48:05 UTC