- From: David Carlisle <davidc@nag.co.uk>
- Date: Sat, 22 Dec 2007 22:46:48 GMT
- To: hsivonen@iki.fi
- CC: www-math@w3.org
> Now, the MathML spec can continue to say that you first trim
> whitespace and then compare against an internal constant. However,
> this evidently isn't currently implemented in Gecko (at least for this
> attribute) and experience with not only MathML but SVG and HTML as
> well suggests that if you spec the whitespace trimming approach,
> someone always implements the comparison without the trimming.
> Therefore, I suggests that regardless of what MathML defines as the UA
> processing model, document conformance should require the token to
> appear without surrounding whitespace so that conforming documents end
> up being resilient to implementation differences in whitespace trimming.
>
Speaking personally, I'm not sure.
It is maybe true that whitespace trimming isn't reliably impemented, and
you are perfectly correct to suggest that such considerations should be
considered as input for possible changes, however whitespace trimming is
specified throughout the spec, for attribute and element content. For
example <mo> + </mo> should be styled the same way as <mo>+</mo> which
implies not only that the white space isn't rendered, but that style
attributes from the operator dictionary are looked up after trimming
white space. Also MathML attribute processing requires much more than
white space trimming and lookup, many have specific syntax: lengths,
colours and also mtable's lists-of-lists using {} braces. I don't see
how we can change all these syntactic constructs (even if we wanted to)
and I'm not sure it makes sense to just change some of them (in the main
spec, the considerations are of course different in the profile for
css). I wouldn't object to adding a note advising that extra spaces are
avoided, and not using such space in examples in the spec, but my initial
reaction would be to avoid changing the normative specification. But as
I say this is a personal first reaction, not a considered WG response....
David
Received on Saturday, 22 December 2007 22:47:36 UTC