[whatwg] Mathematics in HTML5

[White Lynx]

Oistein E. Andersen wrote:
>>>each mark-up element must be kept as short as possible.
> 
> >Some people argue that short element names being misleading and not
> >intuitive does not actually improve readability, some people like short element
> >names as they are more convenient for authoring.
> 
> The importance of this convenience should not be underestimated. 
> After all, we are discussing a hand-authored format (albeit not exclusively so).

Agree. Once conceptual issues will be resolved and WHATWG will clarify its position 
regarding math markup, we can return to naming conventions and if majority prefer
brief element names, ISO 12083 element names will be replaced with shorter ones.

> > >Make font selection simple and natural
> >See "Kerning and shape of the glyphs" section of current proposal,
> >it mentions possible CSS extensions, that however are not part of this proposal
> 
> If roman is chosen as default type, all (ordinary) variables will need mark-up. 
> Would italic be preferable, and would it be conceivable to make italic the default for Latin and Greek 
> characters later on when these CSS extensions might become available? 
> If so, then everything in roman type must also be marked up to make the code future proof. 

I think roman will be default and once CSS extensions will be available one can
change behaviour via author style sheet (not browser default, for backward compatibility reasons)
	formula, dformula {text-transform:math-italic;}

> Is variable mark-up supposed to be compulsory anyway?

I think no.

> As an aside, traditional French typographical conventions for mathematics require lowercase variables 
> in italic, but uppercase ones in roman.

Interesting detail. Do we need extra values like text-transform:french-italic; and french-bold-italic;
that would transform lowecase Latin and Greek characters to appropriate slanted mathematical
alphanumerical characters and uppercase ones to normal mathematical
alphanumerical characters?

> What i meant was to use <root>3<of>125</root> as a shorthand notation for something 
> like <root><order>3</order><of>125</of></root>, in which case only 
> the actual element names differ from the current proposal.

We can revise naming conventrions later. One more problems with roots, mentioned by Michael Day
in offlist discussion, is that XHTML markup is too awkward. If in HTML "radix" and "radicand"
are optional so in square roots one can omit both 
	<radical>81</radical> = <radical><radix></radix><radicand>81</radicand></radical>
but in XHTML markup we prefer to avoid any special parsing rules, so in XHTML
	<radical>81</radical> != <radical><radix/><radicand>81</radicand></radical>
The only thing that  we can do within XML+CSS framework is to introduce extra element for 
square roots like:
	<sqrt>81</sqrt> = <radical><radix/><radicand>81</radicand></radical>

>>I do not think that automatic mixing of roman and italic would be a good
>>idea at the browser side if one search a rapid cheap implementation fully
>>compatible with current standards.
>
> That is probably quite right.

Yes, roman as a default is Ok as a first approximation. 
Later extra line in author' s style sheet could provide TeX like styling:
	formula, dformula {text-transform:math-italic;}

> Such a script would certainly not fit everyone's needs and desires. 
> It could be potentially useful to many, but the language should be such that 
> hand-authoring be practical -- otherwise, the perfect integration with HTML will be lost.

Script that sniffs content of all text nodes tends to run slowly. XSLT does this job faster (but does not work with HTML).
In any case it would be nice to have simple solution like CSS "text-transform".


> Boldface does not necessarily mean vector, and vectors are not always printed in bold
> type. Presumably, you mean that classes like `vector' need not be defined in the
> specification, that the choice is up to the author, and that a custom CSS style-sheet can
> be used to define the font. (This would require CSS font-families for Fraktur and double-
> struck/blackboard bold.)
> 

Script, fraktur and double-struck letters are available as separate Unicode characters, so font-family
may not be the best solution for these scripts. In ISO 12083 they were available as a separate character entities, not elements.

> Each approach has its problems. Anyway, the specification should probably not try to avoid
> the issue of font selection.

This issue belong to presentational layer and has to be addressed on CSS side 
(there are no problems on XSL and/or DSSSL side as one can make appropriate 
transformations). 

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze