Re: Whitespace around enumerated attribute values

On Dec 23, 2007, at 00:46, David Carlisle wrote:

>> 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.

Not rendering intra-element whitespace and collapsing whitespace for  
rendering within text nodes is a totally separate issue from the  
attribute value issue.

Real implementations of CSS formatters have a much better track record  
with collapsing whitespace in element content before rendering than  
vocabulary-specific code has with trimming whitespace in attribute  
values before comparing with a set of enumerated values.

 From the implementation point of view and from the point of view of  
authoring for real-world implementations, there's no reason to  
conflate there two places of white space handling.

> 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).

Support for specific microsyntaxes in attribute values adds utility.  
Supporting extra whitespace around enumerated values does not add  
utility.

> 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....

Do any common MathML generators generate whitespace around enumerated  
attribute values? What's the downside of banning the extra whitespace  
from the point of view of document conformance? The upside is that  
checking documents for conformance becomes a more useful indicator of  
the document working in actual UAs.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 7 January 2008 13:53:19 UTC