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[3]: [cgmo-webcgm] Question: object onload param


Friday, December 9, 2005, 5:41:08 PM, you wrote:
> I'm confused ... need more clarification.
I'll try to help, see inline.

> 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?
I'm not sure I can go into those specifics... Some implementations may
do progressive rendering. I think ideally it would be loaded but not
yet displayed; but that may not be possible for all implementations.

> 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?
Because back then the problem was even worse. You wouldn't even get
the event handler to be called... the event was already dispatched and
the event listener was not yet specified.

> 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)?
The only difference is how many times does onload gets dispatched. With
the upon-ActiveX, it's only once, for the upon-Metafile, it could be
many times (every time .src is changed).

>>  - 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?
Correct.

>>  - 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.
I don't think it is bad, it's up to the users to express what they
need.

> Actually, I think there are a couple things running around here:
> i.) does it refer to ActiveX load or metafile load;
agreed.

> ii.) does "load" imply "load-and-display"?
agreed; although I think it may be difficult to force implementations
to support a 'pause' between the loading, script execution 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.)
SVG has similar problems... but they have a lot more ways of working
around these... they have implicit event listeners within the SVG file
(on a per element basis if they want). Because of that, it almost
becomes a non issue. The "load" vs "load-and-display" issue is present
in SVG.

-- 
Regards,
 Benoit   mailto:benoit@itedo.com


> 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]