I believe it would be better to change that behavior and be compatible with what developers know when they are building HTML 5 apps. It seems that Flash is not as accepted any more as a technology as it was a few years ago, and that should be reflected in the platform.
It would drastically reduce the number of divs for a DHTML runtime app as well, which would be good for mobile devices. On Fri, May 13, 2011 at 1:17 AM, Henry Minsky <[email protected]> wrote: > Early on when we were implementing the dhtml runtime, I wanted to give up > and make everything > have the behavior of HTML DOM, but Max came up with heroic measures to > emulate the swf > behavior. I think it would have been easier to emulate the DHTML behavior in > the swf runtime, but > we already had quite a few projects that depended on the swf mouse click > behavior .. > > On Thu, May 12, 2011 at 3:43 PM, Raju Bitter > <[email protected]> wrote: >> >> Thanks, Henry. I think there's no bug for the SWF10 runtime. The >> edittext doesn't react to clicks on the background of the edittext >> field in both runtimes, so that behavior is consistent. But it's not >> possible to enter any text into either inputtext or edittext covered >> by another view in DHTML runtime. >> >> I've created a JIRA issue with a small test case: >> http://jira.openlaszlo.org/jira/browse/LPP-9934 >> >> http://jira.openlaszlo.org/jira/secure/attachment/13298/LPP-9934-click-behavior-dhtml.lzx >> >> I already wondered how you managed to simulate the same click behavior >> in DHTML, where you "click through" views, which probably is not >> possible. And I ran into the clickdivs a few times in the LFC, but >> never looked into the details of the implementation. >> >> On Fri, May 13, 2011 at 12:30 AM, Henry Minsky <[email protected]> >> wrote: >> > The expected behavior is supposed to match how SWF worked, which is that >> > nonclickable views >> > are supposed to be totally invisible to mouse clicks. >> > >> > To emulate that in DHTML, where mouse clicks don't pass through, max had >> > to >> > implement a whole >> > 'clickdiv' hierarchy which consists of a stack of invisible views on top >> > of >> > the app which mirror >> > the clickable views hierarchy. >> > >> > I am kind of suprised there is a bug in swf10, with events not passing >> > through nonclickable views, since that is the behavior we were trying so >> > hard to emulate in DHTML. >> > >> > >> > >> > >> > On Thu, May 12, 2011 at 3:07 PM, Raju Bitter >> > <[email protected]> wrote: >> >> >> >> I noticed a difference in the click behavior with text, edittext and >> >> inputtext for the SWF10 and DHTML runtime. When I put a a text, >> >> inputtext and edittext field behind a view with clickable="false", I >> >> observed the following behavior: >> >> >> >> Action: Click on the the element behind the non-clickable cover view >> >> >> >> SWF10: inputtext and text receive the onclick event (clicking through >> >> the cover view), editext doesn't receive the onclick event. A view >> >> which is covered by a non-clickable view will receive the onclick >> >> event. >> >> >> >> DHTML: only text received the onclick event, inputtext and edittext >> >> don't receive the event. A view which is covered by a non-clickable >> >> view will receive the onclick event. >> >> >> >> What should the expected behavior be? Shouldn't both runtimes show the >> >> same behavior? >> > >> > >> > >> > -- >> > Henry Minsky >> > Nest Labs >> > >> > > > > > -- > Henry Minsky > Nest Labs > >
