- From: Cyril Concolato <cyril.concolato@enst.fr>
- Date: Mon, 20 Oct 2008 09:22:00 +0200
- 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 UTC