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: Re[4]: [cgmo-webcgm] Highlight test


Benoit,

I agree with your opinion here.

Highlighting is certainly not a style property.
In fact, the way how highlighting occurs is left up to the viewer.
3.2.1.1 says:
"Viewers shall give visual feedback to the user that a successful pick has
occurred, and an indication of the particular object (or region) which has
been picked. The exact method of feedback is viewer dependent."

This is the visual feedback upon a click. There is no definition anywhere
that would explain the exact way how highlighting should be done, hence it
is left up to the viewer.

The purpose of the highlight method in the DOM was to give users a way to
duplicate the behavior that the viewer would use if a
#id(someId,addHighlight) were used.

Best regards,
Dieter


> -----Original Message-----
> From: Benoit Bezaire [mailto:benoit@itedo.com] 
> Sent: Thursday, June 15, 2006 4:12 AM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: Re[4]: [cgmo-webcgm] Highlight test
> 
> Hi Lofton,
> 
> I've expressed my opinion, I would certainly like to hear 
> Dieter's as well. I just don't see why a user would do what 
> was done in the test.
> I could be wrong, but I doubt that's going to happen very often.
> 
> Also, the fact that id(*,clearHighlight) is the only way to 
> remove a highlight (i.e., remove all highlights) using the 
> EBNF complements my argument... Meaning, if we've only 
> expected the need for a clear all highlights in the EBNF, why 
> would we need a highlight that behaves like a Style Property 
> in the DOM?
> 
> My two cents.
> 
> Note: If the highlight method wording is not clear enough, 
> someone should send a LC comment about it.
> 
> --
> Regards,
>  Benoit   mailto:benoit@itedo.com
> 
> This e-mail and any attachments are confidential and may be 
> protected by legal privilege. If you are not the intended 
> recipient, be aware that any disclosure, copying, 
> distribution or use of this e-mail or any attachment is 
> prohibited. If you have received this e-mail in error, please 
> notify us immediately by returning it to the sender and 
> delete this copy from your system. Thank you for your cooperation. 
> 
> 
> Wednesday, June 14, 2006, 7:47:04 PM, Lofton Henderson wrote:
> 
> > At 04:07 PM 6/14/2006 -0700, Galt, Stuart A wrote:
> >>Hello,
> >>
> >>My confusion may have started because in step 2 I remove 
> the highlight 
> >>on "C" but it still remains highlighted.  I assume that this is 
> >>because of the nested structure in this CGM and the 
> previous call to 
> >>highlight "B" (that contains "C").
> 
> > FWIW, I still would have expected that "C" (and all that it 
> contains) 
> > should have gone "off".  The spec says:
> 
> > =====
> > state of type boolean
> 
> >      A true value will highlight the nodes, whereas false 
> will remove 
> > the highlight.
> > =====
> 
> > It doesn't say, "...; false will remove highlight, but ONLY 
> IF it was 
> > previously set explicitly on that node by a call to 
> highlight() with 
> > that node in the argument list."  (If that's what's meant, 
> > clarification of the wording might be in order.)
> 
> >>[...]
> >>If highlighting is a state system and that when you turn on 
> >>highlighting for circle B.  The entire contents of B (which 
> includes 
> >>"C" and "D") is highlighted.
> 
> > If we intend that "C" -- whose contents were incidentally 
> highlighted 
> > because they are also contents of "B", which received the call 
> > "highlight(B, true)" -- should stay highlighted when it the 
> user tries 
> > to turn it off with "highlight(C, false) ... that seems a 
> strange and 
> > surprising result to the unwary!  At the very least, some 
> explanation 
> > in the text is in order, if that is the intention.  Some 
> people would 
> > not guess this behavior without some better hints in the text.
> 
> > Thoughts?
> 
> > One small follow up on my earlier comment...
> 
> > [...]
> >> > Maybe that would be a good clarification comment -- that
> >> > highlight(someObject) is identical to:  #id(someObject,
> >> > newHighlight) or #id(someObject, addHighlight).  Which one?
> >> > I'd say the 2nd, 'addHighlight'.  Thoughts?
> 
> > Oops, about my statement "highlight(someObject, true) is 
> identical to ..."
> 
> > The problem with such an example is that there is no 
> symmetrical "off"
> > example.  I.e., there is no fragment "#id(someObject,...)" that is 
> > equivalent to "highlight(someObject, false)."  There is #id(*, 
> > clearHighlight), but only the wildcard "*" (all objects) is 
> allowed -- 
> > you can't name a single object in place of "*".
> 
> > -Lofton.
> 
> 
> 
> 



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