[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cgmo-webcgm] ISSUE: addHighlight and clearHighlight
All,
when working on the implementation of the addHighlight and clearHighlight behaviors, we ran into one restriction that is not yet mentioned in the spec.
Both behaviors make sense only, if they are sent to an existing viewer control, e.g. by using a DOM call.
They do not make sense if used in a link that creates a viewer control, for example
<html>
....
<p> some text <a href=""mycgm.cgm#id(myID,addHighlight)"" target = "someFrame">link text </a> </p>
</html>
Any such link will be processed by the HTML browser, and it will first delete whatever it finds in "someFrame", and then it will call the MIME type handler for this type of content. So even if there was an existing CGM viewer in "someFrame", it will get deleted before this link gets executed.
If the ending resource (CGM) is the same as the linking resource, the viewer does not reload the resource. This is the default behavior for CGM-to-CGM links. [BB drafted the wording]3.1.2.4.1:
Note that object behaviors are "cumulative". As described in the "Picture behaviors" section, if a link points to the same CGM file that is currently viewed -- e.g., a CGM-to-CGM link within the same file, with _replace picture behavior -- then the picture is not reloaded, and any new object behaviors are applied starting from the current viewing state of the picture.5.7.3, src attributes:
If the CGM resource pointed to by the URI is currently loaded for the object, the user agent shall not reload the CGM (similar to the specification of a same-CGM URI for the _replace behavior on a CGM-to-CGM link.)3.2.2.3--linkuri, and 5.7.6--setAppStructureAttr:
The wording of the spec needs to be changed to reflect this.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]