W3C home > Mailing lists > Public > www-svg@w3.org > June 2003

Re: SVG 1.2 12.1.1 The Progress Event

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Wed, 4 Jun 2003 08:21:54 -0400
Message-ID: <16093.58466.114530.997031@frog.rl.kodak.com>
To: Jim Ley <jim@jibbering.com>
Cc: www-svg@w3.org

>>>>> "JL" == Jim Ley <jim@jibbering.com> writes:

JL> "Dean Jackson" <dean@w3.org>

>> > Also what should happen if the returned resource is a 404 or other non-200
>> > status code, should the document that accompanies the 404 be displayed and
>> > made available with progressLoad events (after all it may well be
>> > a document of a type renderable by the UA) or should it be a
>> > failure and therefore fire my proposed ERROR event.
>> We'll think about it. What do you suggest?

JL> I don't know, for Batik (which only accepts SVG and image types) a
JL> server should really be returning the body of a 404 in a type
JL> displayable by it, so batik could display it.  

    This is an attractive answer but goes against what has been
happening for 404's on images since HTML started being used on the
web.  It would clearly be easier for servers to generate SVG 404's
than say 'JPEG' 404 - but I still doubt it's likely to happen :)

JL> I think it should be rendered, it's still a valid document, and if
JL> an author doesn't want it, then they can simply return an empty
JL> body (although this violates SHOULD's of http1.1).
Received on Wednesday, 4 June 2003 08:23:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:56 UTC