OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re[2]: [cgmo-webcgm] Question: object onload param


I'm confused ... need more clarification.

At 03:28 PM 12/9/2005 -0500, Benoit Bezaire wrote:
>[...]
>As far as I can remember:
>
>  - the initial intent was just to have an onload event (plain and
>  simple).
>  - then we realized that by the time a user added the onload event
>  listener, the CGM was done loading (the event was dispatched too
>  late). (this is happening because scripts are always executed on the
>  outside).
>  - so we opted for the 'onload' object param, which lets
>  implementation more options on when to dispatch the event.
>  - now it turns out that the spec is unclear, is the 'onload' event
>  dispatch when IE is done parsing the 'object' tag

[that seems implied by the language of 3.4 ... tho' let's sort out what is 
useful.]

>or is it
>  dispatched when a WebCGM illustration is loaded.

When you say "loaded", do you mean:

a.) loaded-but-not-yet-displayed?
b.) or loaded and displayed?

Why does this interpretation -- "when a WebCGM illustration is loaded -- 
not have the same problem as identified in the 2nd dash above, i.e., the 
problem with having a straightforward 'onload' event defined in WebCGM?

For the use case (Stuart's) of using WDOM to alter the initial display 
*before* it occurs, is there any difference between your two options 
(upon-ActiveX and upon-Metafile)?

>  - note 1: it is possible to parse the 'object' tag without loading a
>  CGM file (ex: no 'data' attribute on the object tag)

Question.  Script could detect this by (getWebCGMDocument().src == 
emptyString), right?

>  - note 2: 'onload' being dispatched after a CGM file is loaded
>  _could_ imply that it is dispatched every time the 'src' attribute is
>  changed.

Is that bad?  For the use case that initial, pre-display DOM interactions 
need to be dependent on the content of the specific metafile instance, this 
would be necessary.  Is this a use case that is to be supported?  Stuart's 
message seemed to imply that he wanted to alter visibility of objects 
before display, which seems to be metafile-content dependent.

Actually, I think there are a couple things running around here:
i.) does it refer to ActiveX load or metafile load;
ii.) does "load" imply "load-and-display"?


>  I hope this recaps well the situation.
>
>  I think the way forward is to nail down what is most useful for the
>  users.

Another question.  Has SVG faced this?  It would seem likely.  I recall 
mail list discussion about the timing of load events.  (SVG's event 
handling is so complex that I don't have a good sense of it, and would have 
to go research carefully.)

Regards,
-Lofton.

>
>Friday, December 9, 2005, 11:59:54 AM, you wrote:
>
> > ALL --
>
> > I need help finding documented history of this...
>
> > At 02:14 PM 12/7/2005 -0500, Benoit Bezaire wrote:
> >>[...]I haven't heard anything about anyone regarding the onload issue.
> >>
> >>Could we simply start by having everyone describe what they wish to
> >>accomplish with the onload event (i.e., what do you want to do with
> >>it)?
>
> > I have started one step further back -- to see if I could find
> > *documentation* about why we added it (the onload <param> of <object>) in
> > the first place.  I.e., there must have been something that we wanted to
> > do, but couldn't do with addEventListener() on the Metafile interface, 
> right?
>
> > For reference, Benoit submitted the proposed text to the TC list on
> > 6/29/05.  I have done a little searching of the archives, and found one
> > message thread that contains some hints:
>
> > http://lists.oasis-open.org/archives/cgmo-webcgm/200503/msg00032.html
>
> > ALL -- can anyone find either a mail archive ISSUE, or  telecon minutes,
> > which documents the resolution to add the <param> onload element?
>
> > Or can you remember clearly, why we thought we needed it, when we decided
> > to add it, in the Mar-Jun timeframe?
>
> > Regards,
> > -Lofton.
>
>
>
>
> >>Friday, November 25, 2005, 7:43:12 AM, you wrote:
> >>
> >> > Hi,
> >>
> >> >   The current WebCGM 2.0 specification says the following about the
> >> >   'onload' param (of the Object tag):
> >> >   - [...] allows script writers to manipulate the WebCGM DOM at the
> >> >   point at which the user agent has fully parsed the object tag and
> >> >   its descendants and is ready to render the object to the screen.
> >>
> >> >   Ralf and I interpreted this differently. One of us thought it meant
> >> >   that the onload would be dispatch when the ActiveX is loaded, and
> >> >   the other thought that it meant the onload is dispatched when the
> >> >   Metafile is loaded? There is a difference. From a technical
> >> >   perspective the ActiveX can be loaded without a CGM file (as long as
> >> >   the MIME type is specified on the 'object' tag, the ActiveX will be
> >> >   created).
> >>
> >> >   We noticed the problem when trying the WebCGMEvent test. The 'src'
> >> >   attribute is actually set in the script that is called via the
> >> >   onload param.
> >>
> >> >   So when should we dispatch the onload event?
> >>
> >> >   We see advantages to both interpretations:
> >> >   i) When the ActiveX is loaded... allows to set the 'src' parameter
> >> >   in the onload event handler or alternatively, possibly modify via
> >> >   the DOM the CGM before the first display.
> >>
> >> >   ii) When the Metafile is loaded... is like a DOM Mutation event
> >> >   where you get notified that the document has change. In this case
> >> >   you would get the onload every time the 'src' attribute is set or
> >> >   for each internal link to a new WebCGM file. The use case here is to
> >> >   extract metadata information to be interpreted by the host
> >> >   application following each load.
> >>
> >> >   What was the intent?
> >> >   Which is needed?
> >>
> >> >   Regards,




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]