cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: ISSUE: is noHighlight functionality needed?
- From: Lofton Henderson <lofton@rockynet.com>
- To: cgmo-webcgm@lists.oasis-open.org
- Date: Fri, 01 Jul 2005 16:03:52 -0600
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]