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: ISSUE: is noHighlight functionality needed?


Source:  editors

ISSUE:  do the object behaviors need a way to turn off existing highlighting?

DISCUSSION:

The spec (6/28 Editors draft, reviewed at last telecon) says:  "The object behaviors are built from a set three "atomic" navigation keywords and a set of two "atomic" highlight keywords, defined below. The navigation keywords have no highlighting side effects and the highlighting keywords have no navigation side effects -- the navigation and highlighting keyword sets are orthogonal."  This is a basic principle of the new object behaviors scheme.

There appears to have been some leftover expectation that 'move' would clear existing highlighting (comments at last telecon).  But the newly articulated orthogonality between navTerm and highlightTerm would say ... if a picture is displayed, and if anything is already highlighted, then 'move' should leave it alone. 

This would leave one functionality missing:  the ability to clear highlighting (with or without a change of view).  E.g., one could not return to a full_noHighlight view once any highlighting behaviors had been invoked.  For reference:

-- newHighlight erases any existing highlight and then applies the new highlighting.
-- addHighlight applies the new highlighting, leaving any existing highlighting alone.

Note that this issue only arises in the context of cumulative behavior, which we have only just recently started to clarify.  I.e., it is easy to specify object behaviors that, upon initial load, have any desired highlight state.  But it is XCF or DOM sequences like the following that become problematic.

#(someName, zoom_newHighlight)
#(someId, zoom_newHighlight)
[same view all highlighting off] or
[full picture no highlighting] or ...

The [...] capabilities of the last two lines are not there.

ALTERNATIVES:

1.) do nothing: which means you can't return to a no-highlight state, once something has been highlighted (i.e., "the functionality is not important enough")

2.) compromise "orthogonal": move (& other nav. keywords?), when alone, implicitly clear highlighting (leaving no way to navigate within a picture without affecting the highlighting state).

3.) add some noHighlight functionality to the behaviors:  either for whole picture (i.e., all objects. for example via a wildcard object selector), or for individual target object(s), or both.  [3 flavors here].

RECOMMENDATION:  none yet.  TC should think and discuss.

-Lofton.


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