W3C home > Mailing lists > Public > www-svg@w3.org > September 2005

Re: [SVG] assigning to currentScale

From: Jim Ley <jim@jibbering.com>
Date: Tue, 20 Sep 2005 23:29:30 +0100
To: www-svg@w3.org
Message-ID: <dgq2h9$937$1@sea.gmane.org>

"Rick" <graham.rick@gmail.com> wrote in message 
>On 9/20/05, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> Jonathan Watt wrote:
>> > I don't see how it violates the specification. I haven't seen anything
>> > to say that implementations "must not throw errors except as described
>> > in this and other applicable recommendations".
>> That's because imposing such a constraint on implementations is 
>> unreasonable.
>> For example, I have yet to see a specification that describes throwing 
>> out of
>> memory exceptions, and at the same time implementations that _are_ out of 
>> memory
>> are far better off throwing said exceptions than just silently doing 
>> completely
>> incorrect things.  In my opinion, of course.
>These are implementation issues and beyond the scope of the spec.  The
>spec defines a graphic description language and cannot determine what
>an implementation should do when it nears the limits of the CPU,
>memory resources, integer/float register width, display capabilities,
>etc., of the platform it is running on.

It's a very different situation to hitting the limits of the machine - 
memory errors, and an arbitrary spec violation of clamping a value, there is 
no way a client-side scripter can script to degrade gracefully in respect to 
memory full errors, especially as executing more script is one of the things 
that it won't be able to do any more of.

Being forced to violate the spec of infinite (well IEEE double Max number) 
zooming is one thing, to do that, and then make it even worse on the author 
by choosing to throw implementation specific errors helps no-one attempting 
to author interopable content.

Received on Tuesday, 20 September 2005 22:33:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:04 UTC