W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Re: ISSUE-2138 (SVG-HTML error processing): Error processing differences in SVG and HTML [Last Call: SVG 1.2 Tiny ]

From: Cyril Concolato <cyril.concolato@enst.fr>
Date: Thu, 16 Oct 2008 09:42:43 +0200
Message-ID: <48F6F073.9040900@enst.fr>
To: Doug Schepers <schepers@w3.org>
CC: SVG Working Group WG <public-svg-wg@w3.org>


Doug Schepers a écrit :
> Hi, Cyril-
> Cyril Concolato wrote (on 10/16/08 2:56 AM):
>>>>> * Section 5.9.1 The 'externalResourcesRequired' attribute What is the
>>>>> rationale behind the sentence:
>>>>> "If a node enters the error state then the document enters the error
>>>>> state and progressive rendering stops." Is this behavior compatible
>>>>> with traditional HTML processing? 
>>>> I've identified the following error states explicitely listed in the
>>>> spec:
>>>> - playbackOrder='all' and use of discard
>>>> - circular references
>>>> - eRR true but resource not fetched
>>>> - a java class listed in SVG-Handler-Class does not implement
>>>> EventListenerInitializer2
>>>> My problem is with the 3rd case. For example, if an image (in a group
>>>> with eRR = true) is not fetched, the UA stops the rest of the rendering
>>>> of the document. HTML browser don't stop rendering when an image link is
>>>> broken and this is a more useful behavior. My suggestion is to say that
>>>> if a node enters the error state (because of an unresolved link), then
>>>> the UA should inform the user but keep rendering the rest of the
>>>> document.
>>> I'm not sure I agree.
>>> The more graceful error recovery is already the behavior when
>>> externalResourcesRequired="false".  externalResourcesRequired="true"
>>> means exactly that: that the author considers the external resources to
>>> be necessary to the proper viewing of the document.  If the author
>>> wishes to allow tolerant error recovery for broken links, then they need
>>> only omit the externalResourcesRequired attribute (lacuna is "false") or
>>> set it explicitly to "false".  The behavior you suggest would defeat the
>>> very purpose of the attribute.  externalResourcesRequired is not a
>>> conditional attribute, to hide or show an element based on the
>>> availability of a resource.
>>> If you still disagree, please let us know why you would expect the other
>>> behavior, and the SVG WG will discuss it.  If this adequately explains
>>> the rationale, please let us know that this is a satisfactory response.
>> I understand your explanation, but eRR=true is actually doing 2 things:
>> controlling the progressive rendering algorithm to stop the rendering
>> until the resource is resolved; and controlling the resolution of the
>> resources. I'm just wondering if it wouldn't be better to have 3 values:
>> externalResourceRequired="none" (lacuna value, equivalent to false)
>> externalResourceRequired="keep" (just pauses the rendering until the
>> children are loaded but it continues rendering if a external resource
>> link is broken)
>> externalResourceRequired="strict" (equivalent to true in the current
>> definition)
>> However, if you think this is too much editing or a too big change, I
>> agree to leave it as is.
> I do see your point, but this would be incompatible with SVG 1.1 [1],
> and would indeed be too big a change to make at this point, for
> relatively little gain.  We already have existing implementations, and
> this would change conformance requirements.
I understand. In fact I did not remember this was in 1.1. 

> This may be something to look at in the SVG 2.0 Core timeframe, but
> since you are satisfied with the explanation as is, we will not change
> it for SVG 1.2 Tiny.


Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Département Traitement du Signal et Images
/Dept. Signal and Image Processing
Ecole Nationale Supérieure des Télécommunications
46 rue Barrault
75 013 Paris, France
Received on Thursday, 16 October 2008 07:43:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC