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

Re: ISSUE-2137 (canvas negotiation begin time): Add clarification about begin time for canvas negotiation (ACTION-2320)

From: Cyril Concolato <cyril.concolato@enst.fr>
Date: Mon, 20 Oct 2008 09:22:00 +0200
Message-ID: <48FC3198.8040605@enst.fr>
To: Doug Schepers <schepers@w3.org>
CC: SVG Working Group WG <public-svg-wg@w3.org>

Hi Doug,

Doug Schepers a écrit :
> Hi, Cyril-
> 
> Cyril Concolato wrote (on 10/14/08 2:36 AM):
>> SVG Working Group Issue Tracker a écrit :
>>> ISSUE-2137 (canvas negotiation begin time): Add clarification about
>>> begin time for canvas negotiation [Last Call: SVG 1.2 Tiny ]
>>>
>>> http://www.w3.org/Graphics/SVG/WG/track/issues/2137
>>>
>>> Raised by: Doug Schepers
>>> On product: Last Call: SVG 1.2 Tiny
>>> Cyril Concolato
>>> <http://lists.w3.org/Archives/Public/www-svg/2008Oct/0110.html>:
>>> [[
>>> * Section 7.1. Coordinate Systems, Transformations and Units Introduction
>>> Could you add a clarification about when the canvas negotiation
>>> happens? I think it happens upon parsing the start tag of the SVG root
>>> element but this is not clear. 
>> More precisely, I suggest adding the following sentence in the
>> progressive rendering section (5.9.2) after the sentence:
>> "The following rules apply to progressive rendering:"
>> "* the negotiation process for the size of the SVG viewport (see
>> Establishing the size of the initial viewport) happens when the
>> start-tag of the rootmost 'svg' element has been processed."
>>
>> This clarification is needed because I think that since script elements
>> can have access to the viewport width/height, the negotiation has to
>> happen before any script is processed.
> 
> Your reasoning and wording are sound, but this is actually
> implementation-specific.  It could happen at parse-time, or rendering
> time, or any time in between.
If you say that it's implementation-specific then you accept that an SVG content renders well in non-progressive rendering but might lead to error in progressive cases. I don't think that's a good thing to do that is why I suggested the above sentence. I agree this may need further thoughts especially in the case below.

> It may be even out of the control of the SVG user agent, for example if
> the SVG is embedded in an HTML page, the viewport size may not be a
> function of the SVG root settings, and may change as a result of script,
> resizing, any one of a number of other factors.
I'm not sure about this one. I have to think about it more.
 
> Authors who need to be sure of the viewport should do so with load-event
> or resize-event handlers.
In the meantime, could you then add this as a note (maybe in the uDOM section) ?

> Personally, as an author, I would like this to be clarified, and maybe
> with some more research, we could figure out how do so in SVG 2.0 Core.
> 
> I hope this explanation is reasonable to you, and satisfies your comment.
I agree with delaying the complete resolution of the problem but I still think the note is useful. Adding the (informative) note would satisfy my comment.

Cyril

-- 
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
http://tsi.enst.fr/~concolat 
Received on Monday, 20 October 2008 07:22:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 October 2008 07:22:38 GMT