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
