Is an entire shadow div hierarchy really necessary? That sounds expensive, and potentially hard on the slower/less robust browsers.
Here's another potential option. Is the inversion of visible/ clickable views only local? That is, do the visible and clickable views share a close parent? Because if so you could use event capturing (or bubbling) in the common parent to redirect the event. Here's code that creates a mouse event and dispatches it to a particular event. You could do the same with a nonsynthetic mouse event, passing it to the one known clickable view in the subview hierachy. (This would require adding the concept of the "one known clickable view", of course.) http://developer.mozilla.org/en/docs/DOM:document.createEvent And here's another sample that redirects a click event from one view to another: http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/ createeventobject.asp As for whether there is a single well-defined shared parent, if there isn't perhaps we should make one up? Something like the focustrap attribute may signal a place to redirect, for example -- the idea of hierarchical focus is in some ways connected with what we're discussing here. jim On Sep 13, 2006, at 4:33 PM, Max Carlson wrote: > That's right - and it almost sorta works now. It fixes my > testcase, but doesn't work in LzPix yet. I'm going to keep going > down this path because if we don't get this right a lot of things > will break. For example, the little animated focus rectangles > prevent clicks to the underlying focused component... And that's > just one tiny example. I really want to minimize the number of > things people porting to DHTML have to think about... > > -Max > > Henry Minsky wrote: >> Max has already a done a bunch of work which implements an entire >> "shadow" stack of invisible views >> which mirror the view hierarchy and sit above the visible apps in >> order to catch mouse clicks. I believe it actually >> works. I was worried that there would might be performance >> implications to having to manage twice as many DHTML divs, but it >> may be necessary and it might not be so bad for performance, for >> example maybe there could be some kind of optimization to disable >> it maybe when you don't need it or when you can declare for sure >> that a view is never going to be clickable. >> On 9/13/06, *Neil Mix* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> This is the problem I was trying to bring up a few months ago. I >> don't take issue with Henry's suggestion except for the fact that >> it's highly backward incompatible. As a data point, Pandora >> has at >> times relied heavily on the current behavior. (I'm not sure >> to what >> extent it does at-this-moment.) >> FWIW, I've experienced general cross-browser flakiness when >> trying to >> stack areas of different clickability on top of each other in >> DHTML. >> It's a tough problem. >> An alternative suggestion to Henry's: place an invisible mouse- >> event- >> catching div at the top layer in an application, and write >> your own >> code for calculating where to deliver the events. >> On Sep 13, 2006, at 11:25 AM, Jim Grandy wrote: >> > Moving thread to laszlo-dev. >> > >> > On Sep 13, 2006, at 7:35 AM, Henry Minsky wrote: >> > >> >> Being naturally lazy and simple-minded I've thrown this >> out before >> >> as an idea, what if we say that LZX uses the DHTML model of >> >> click-handling, and modify SWF to act the same way (i.e., all >> >> views clickable). Not being a GUI designer, I don't >> really know >> >> what the pluses and minuses are, but it seems to me like >> if the >> >> app designer is going to put graphics on top of >> >> clickable views which are in a different parent hierarchy, >> then >> >> maybe it is incumbent upon them to explicitly forward >> >> the mouse events to the area they are covering up? >> >> >> >> >> >> >> >> On 9/13/06, P T Withington <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: I guess >> >> this is no worse than the SWF case where we have to have two >> >> movie clips for every view? Still sucks though. >> >> >> >> On 2006-09-13, at 02:36 EDT, Max Carlson wrote: >> >> >> >> > It turns out any view physically on top of a clickable >> view (but >> >> not a >> >> > child) intercepts all mouse events. We originally thought >> this was >> >> > restricted to text views >> >> > ( http://jira.openlaszlo.org/jira/browse/LPP-2520 ) but it >> >> applies to >> >> > any >> >> > view. I'm making this my top priority. I filed a new >> bug to >> track >> >> > this: >> >> > http://jira.openlaszlo.org/jira/browse/LPP-2680 >> >> > >> >> > I'm glad I left the fix in! >> >> > >> >> > -Max >> >> > >> >> > _______________________________________ >> >> > >> >> > Internal-Dev mailing list >> >> > [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> > https://hedwig.laszlosystems.com/mailman/listinfo/ >> internal-dev >> >> > >> >> > To search the dev list: http://lists.laszlosystems.com/ >> intranet/ >> >> > finddev.cgi >> >> >> >> >> >> _______________________________________ >> >> >> >> Internal-Dev mailing list >> >> [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> https://hedwig.laszlosystems.com/mailman/listinfo/internal- >> dev >> >> >> >> To search the dev list: http://lists.laszlosystems.com/ >> intranet/ >> >> finddev.cgi >> >> >> >> >> >> >> >> -- >> >> Henry Minsky >> >> Software Architect >> >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> >> >> >> >> >> _______________________________________ >> >> >> >> Internal-Dev mailing list >> >> [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> https://hedwig.laszlosystems.com/mailman/listinfo/internal- >> dev >> <https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev> >> >> >> >> To search the dev list: http://lists.laszlosystems.com/ >> intranet/ >> >> finddev.cgi >> > >> > >> > _______________________________________________ >> > Laszlo-dev mailing list >> > [email protected] <mailto:[email protected]> >> > http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >> <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev> >> _______________________________________________ >> Laszlo-dev mailing list >> [email protected] <mailto:[email protected]> >> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >> -- >> Henry Minsky >> Software Architect >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> Laszlo-dev mailing list >> [email protected] >> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
