[whatwg] Mathematics in HTML5

[White Lynx]

Anne van Kesteren wrote:
> but just putting  
> this in the specification as well and requiring UAs to support it by  
> default seems too much to ask, imho
Maybe, but taking into account that WHATWG does not want to establish several levels 
of compliance, what can we do?

> I see at least three things in the specification that are in need of  
> improvement. (1) There need to be more examples. I guess this is true  
> for most specifications out there... 
It is not specification yet, at the moment we just want to know whether 
proposal like this is accaptable for WHATWG and to collect some preliminary feedback
from community.

> (2) The intend of the HTML  
> parsing rules is there, but they are not implementable. For example,  
> according to the specification:
>
>   <fraction>17<den>125</fraction>
> 
> ... comes out as:
>
> <fraction>
>   <num>17</num>
>   <den>125</den>
>   </fraction>
> ... now where did that whitespace come from? 
Issue with white space is just typo and will be fixed. Note however that parsing rules does not
fully follow SGML conventions, because as far as I know WHATWG does not consider HTML5 to be SGML based
markup, if however compatibility with SGML is still required please let us know and parsing rules will be changed accordingly
(for usability reasons we prefer to keep current rules).

> (3) Error handling. What  
> happens when I nest elements where they not belong etc. Does that  
> affect parsing? 
It is important issue, I think parsing should not be affected.
Normative error handling mechanism could be a problem, 
it can be provided but is unlikely to be followed by implementations,
and thus will be useless. We'll return to issue later today and with some examples.
> Or for content models like "matrix element or vector  
> element followed by either marker or submark" what happens when I  
> actually write down a <submark> followed by <marker> followed by  
> <matrix>? I guess these issues are mostly relevant for parsing  
> (styling is pretty clear once that's defined), but it should be clear  
> what the semantics are in such cases as well.
Introducing too complex parsing rules will spoil our efforts to keep
markup easy to implement. Note in particular that in XHTML version we
don't want to introduce any special parsing rules at all. 
Current proposal does not require special parser for XHTML, breaking this rule
would reduce chances of markup to be implemented. In HTML we can provide
some special parsing and error handling rules, but not too much otherwise we risk
to make markup difficult to implement for the sake of no actual functionality.

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

Powered by Outblaze