[whatwg] Mathematics in HTML5

Juan R. Gonzalez-Alvarez wrote:

> I assume that authors agree. Therefore, now is matter for developers, they
> have the last word.

Basically there is nothing in proposal that could be difficult to implement,
morover on first stage XHTML with fallback style sheets can work without
any kind of native support. So implementation costs, 
that in any case are much lower then alterenatives, are unlikely 
to be an obstackle.

Look at proposal once again:

1. formula, dformula, dformgrp - just containers, no problems.
2. sub, sup - already exist nothing to add
3. stack - requires support for inline-blocks. No problems in MSIE, Opera, Prince. 
Safari and Mozilla will have to fix bug affecting inline-blocks.
4. fraction, num, den - the same as stack.
5. over, obase, top, overbrace - the same as stack
6. under, ubase, bottom, underbrace - if content of ubase is restricted to PCDATA then the same as stack,
otherwise either inline-tables (work in Opera, Prince, require small bug fix in Safari) or 
inline-blocks and CSS3 inline-block-align properties are needed. So in case inline-tables will 
be considered unrealistic elements still can be retained provided that content of ubase is restricted
to PCDATA, in future this constraint can be easily eliminated.
7. opgrp, op, uli, llim, limits - the same as stack
8. radical, radix, radicand - requires inline-tables. Element is safe to omit as equivalent fuctionality
is available in power notations. So in case inline-tables will be considered unrealistic element may be omitted.
9. sqrt - requires inline-blocks, maybe image borders, or SVG backrgound image. Element is safe to omit as equivalent fuctionality
is available in power notations.
10. fence, fenced, marker, submark - the same as stack. Support for image borders or SVG backrgound images would be useful.
11. matrix, det, choose, cases, case, row, entry, cell, value, scope - formally it requires inline-tables, but necessary functionality 
exists in all browsers in a form of (X)HTML table with display set to inline, inline-table or -moz-inline-box.

Thus proposal can be naturally split into three ones.

I. Full proposal
II. 1,2,3,4,5,6 with restricted content of ubase, 7, 10, 11 (Juan's proposal)
III. 1, 2, 4 (Michel's proposal)

All of them are realistic and should not be difficult to implement.
If WHAT WG does not want to standardize first proposal as markup for mathematics in HTML5, 
then options II and III exist. Regarding presentation quality issues, please once again note that markup focuses on structure, 
we don't ask anyone to register proposal as participant of Miss Finland 2006.









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

Powered by Outblaze

Received on Wednesday, 21 June 2006 04:16:54 UTC