Re: Whitespace around enumerated attribute values

On Jan 7, 2008, at 16:08, David Carlisle wrote:

>> Do any common MathML generators generate whitespace around enumerated
>> attribute values?
>
> I've no idea, but I'm vary wary of the (commonly expressed) argument
> that some feature is not used much so can be removed.

Note that I was talking about document conformance to err on the  
prudent side when it comes to actual interop issues. I was silent on  
whether processing in UAs should be changed not to trim whitespace in  
attribute values.

> Even for features that are bad, illogical or even possibly never  
> implemented, I think that unless there is overwhelming reason to  
> remove them they should be kept.

If a feature has never been implemented, it should be removed from the  
spec between CR and REC at the latest.

> Documents live forever, but applications (eventually) get upgraded to
> the latest version of the spec.

Considering that the #1 native browser implementation of MathML has  
problems with whitespace around enumerated attribute values, it seems  
relatively safe to speculate that there isn't a critical mass of  
MathML content *on the Web* requiring whitespace trimming. Still,  
that's relevant to the processing requirements in non-validator UAs.  
I'm talking about the requirements for creating new MathML content.

> Making a breaking change that makes old documents no longer work  
> with new applications should be avoided at all
> costs.

I agree. I wasn't suggesting changes to how MathML-consuming apps  
(other than validators) are prescribed to behave. I have not tested  
enough MathML-consuming apps to generalize how they behave.

> There's no hard and fast rules here different people take different
> value judgements on when it's worth breaking with the past to  
> improve the
> future. Perhaps it's my TeX background, but I know I'm positioned much
> further towards the "never change anything" end of the scale than most
> people. (Any of my colleagues on the WG could confirm that they have
> heard the above argument from me at F2F meetings and phone  
> conferences,
> on more than one issue within the spec:-).

I'm close to the change-avoidance camp when it comes to changing  
implemented and shipped UA behavior--especially if there are multiple  
interoperable implementations. However, I think specs can and should  
change when following specs doesn't lead to interop given the  
implementation reality.

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

Received on Monday, 7 January 2008 14:55:15 UTC