- From: <bugzilla@jessica.w3.org>
- Date: Thu, 27 Mar 2014 17:59:28 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887 --- Comment #73 from Jonas Sicking <jonas@sicking.cc> --- XBL1 these days do have explicit insertion points. I.e. we leave the insertion points in the tree. The reason XBL1 doesn't have this problem simply because it optimizes simplicity over usefulness. For example, if you have an XBL1 binding for a button that looks like <content> <-- xbl1 equivalent of shadowroot, sort of <div style="border:1px solid red"> <div style="border:1px solid green"> <children/> <-- xbl1 equivalent of <content> </div> </div> </content> And content like: <mybutton style="-moz-binding: url(#fancybutton)"> <img src="icon.gif"> <span>text here</span> </mybutton> then clicking on the icon or the text in the button does not fire any events in the XBL1 shadow content at all. However if you click a few pixels away so that you hit the borders added by the two divs now the event does fire on the shadow content. >From an author point of view this is arguably very inconsistent. Normally with the DOM, it doesn't matter if the user clicks on the border of an element, or on any of the elements inside it. This makes a lot of sense from a UI point of view too when it comes to things like click events. However with XBL1 that model is broken and if you want to implement a UI widget that has insertion points you are basically out of luck when it comes to catching all UI actions inside your widget as I can tell. You could overlay any inserted content with absolutely positioned elements, but that means that those events don't reach the content inside the insertion point that the user clicked which is really bad too. So while XBL1 is simple implementation-wise, it seems to me that it creates a lot of complexity for authors. Or am I misremembering the XBL1 event model? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 27 March 2014 17:59:30 UTC