W3C home > Mailing lists > Public > www-svg@w3.org > November 2002

RE: SVGLoad event.

From: Robert Diblasi <rdiblas@wpo.it.luc.edu>
Date: Tue, 05 Nov 2002 11:29:37 -0600
Message-Id: <sdc7aba8.063@wpo.it.luc.edu>
To: <jon@ferraiolo.com>, <jim@jibbering.com>, <www-svg@w3.org>

This has been very informative to me...I can not speak Jim.

I think your example and description should be in a non-normative  section in the SVG 1.1 ...1.2....2.0 ? recommendation

We all learn by sharing what we know
Robert A. DiBlasi
SVG User Group: Chicago IL. Chapter member

>>> "Jon Ferraiolo" <jon@ferraiolo.com> 11/05/02 09:43AM >>>

Thanks for clarifying. It is absolutely true that there is some
confusion in the SVG specification in the conflict between the
progressive rendering requirement for Conforming High-Quality Dynamic
SVG Viewer and the definition of the 'SVGLoad' event, which says that
the event isn't fired until the target element for the SVGLoad event
listener is fully ready to render.

Here is the way to work through the confusion:

1) Conforming High-Quality Dynamic SVG Viewer must implement progressive
rendering and honor the externalResourcesRequired attribute, which can
be used to disable progressive rendering

2) Progressive rendering occurs as content is received unless
externalResourceRequired is set to true.

3) SVGLoad events will be dispatched on individual elements within the
file as these elements become fully parsed and ready to render. For
example, with a <g>, the SVGLoad event on that <g> occurs once you have
parsed the end element (</g>) and ready to progressively draw that <g>.
If you want to prevent progressive rendering from occurring on those
elements within the <g> before the <g> is fully parsed, then set

4) Once the document is fully parsed and every element is ready to
render, then the SVGLoad event is fired on the outermost <svg> element

In other words, you can think of the SVGLoad event as just another thing
that happens along the way as progressive rendering occurs. For example,
take the following SVG file:

  [1] <svg>
  [2]   <g onload="...">
  [3]     <rect/>
  [4]     <circle/>
  [5]   </g>
  [6] </svg>

Assuming your SVG viewer implemented every aspect of the language
completely and was programmed to update the screen after fully parsing
each particular element it encounters. Then, first a rectangle would be
drawn on the screen. Then the circle would be drawn. Then you reach the
</g> and the SVGLoad event would be fired on the <g>.

Does this help?


> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
> Jim Ley
> Sent: Tuesday, November 05, 2002 1:54 AM
> To: www-svg@w3.org
> Subject: Re: SVGLoad event.
> "Jon Ferraiolo" <jon@ferraiolo.com>
> > If I understand your question, I think the answer is yes -- your
> > description "just before the content is rendered" is reasonably
> to
> > the official words.
> >
> > > (which is completely incompatible with
> > > Dynamic High Performance SVG viewers.)
> >
> > How so? You must be thinking of some particular wording in the SVG
> > specification regarding Dynamic High Performance SVG Viewers, but
> > nothing comes to me right now.
> In a high performance dynamic svg viewer, the content must be rendered
> paralell to downloading:
> ( http://www.w3.org/TR/SVG/conform.html )
> | A Conforming High-Quality Dynamic SVG Viewer must support
> | the following additional features:
> | Progressive rendering and animation effects (i.e., the start of the
> | document will start appearing and animations will start running in
> | parallel with downloading the rest of the document).
> So consider onload of the root SVG element, the contents of this "will
> start appearing" before the content is fully downloaded, so onload at
> best can only appear immediately before the last element downloaded is
> rendered.
> Jim.
Received on Tuesday, 5 November 2002 12:31:40 UTC

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