W3C home > Mailing lists > Public > www-math@w3.org > January 2008

Re: Whitespace around enumerated attribute values

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 7 Jan 2008 16:54:57 +0200
Cc: www-math@w3.org
Message-Id: <4295AAE2-380C-4A9E-91C5-66C9065B33A0@iki.fi>
To: David Carlisle <davidc@nag.co.uk>

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
Received on Monday, 7 January 2008 14:55:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:46:45 UTC