From some recent porting experiences, i can say it would minorly impact
my applications, although it can be fixed. If you supply an API that can
halt the propagation of events, and call that clickable="false", then
you could also have clickable="auto" and clickable="true" where in the
auto case you must control propogation your self (via handler? how i
wonder. i don't know)
Make sense?
-james
P T Withington wrote:
We're asking for community feedback on a feature that we can support
in swf8 and swf9 platforms, but cannot support on DHTML.
On swf-based platforms, any view can be 'clickable' or not. Views
that are not 'clickable' do not intercept mouse gestures at all. Even
if a clickable view is completely covered by a non-clickable view, you
can still click through the non-clickable view to manipulate the
clickable view. (Obviously, the view in front needs to be at least
partially transparent for you to be able to see what you are actually
manipulating).
DHTML has a different model of clickability. In DHTML, clicks will be
passed from children up to parents, if the children do not handle
them; but they are not passed to unrelated views that are behind other
views.
Since LZX originated on the swf platform, we have tried to maintain
the swf-based clickability model on the DHTML platform, and it works
for all views _except_ for one corner case (the subject case:
selectable <text> or <inputtext> behind a partially transparent
view). We have tried to develop a work-around for this case, but it
results in visual artifacts (like the text appearing to 'bleed
through' the view in front).
We feel the only choice in this case is to document the more limited
semantics that will be available on all platforms -- that is, to not
support clicking through partially transparent views to selectable
<text> or <inputtext> elements.
We'd appreciate your opinions, and to know whether or not this would
affect your applications.
P T Withington
OpenLaszlo.ORG/Laszlo Systems
