{"action":"opened","issue":{"url":"https://api.github.com/repos/hayatoito/test/issues/103","labels_url":"https://api.github.com/repos/hayatoito/test/issues/103/labels{/name}","comments_url":"https://api.github.com/repos/hayatoito/test/issues/103/comments","events_url":"https://api.github.com/repos/hayatoito/test/issues/103/events","html_url":"https://github.com/hayatoito/test/issues/103","id":79352104,"number":103,"title":"[Shadow]: Make event retargeting optional (bugzilla: 28444)","user":{"login":"hayatoito","id":160288,"avatar_url":"https://avatars.githubusercontent.com/u/160288?v=3","gravatar_id":"","url":"https://api.github.com/users/hayatoito","html_url":"https://github.com/hayatoito","followers_url":"https://api.github.com/users/hayatoito/followers","following_url":"https://api.github.com/users/hayatoito/following{/other_user}","gists_url":"https://api.github.com/users/hayatoito/gists{/gist_id}","starred_url":"https://api.github.com/users/hayatoito/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hayatoito/subscriptions","organizations_url":"https://api.github.com/users/hayatoito/orgs","repos_url":"https://api.github.com/users/hayatoito/repos","events_url":"https://api.github.com/users/hayatoito/events{/privacy}","received_events_url":"https://api.github.com/users/hayatoito/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-05-22T08:28:01Z","updated_at":"2015-05-22T08:28:01Z","closed_at":null,"body":"Title: [Shadow]: Make event retargeting optional (bugzilla: 28444)\n\nMigrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444\nAssigned_to: *Hayato Ito*\n\n----\ncomment: 0\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444#c0\n*Dimitri Glazkov* wrote on 2015-04-08 16:00:41 +0000.\n\nFrom https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html\n\nAnnevk: \"I think opt-in (or only\nwith isolated) would be better and perhaps if the API needs to change\nanyway we can do that, but we could probably live with opt-out as\nwell. When you use shadow DOM to compose, global reasoning about state\nand events is a fairly established pattern that we should enable.\"\n\n----\n\ncomment: 1\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444#c1\n*Dimitri Glazkov* wrote on 2015-04-08 18:27:59 +0000.\n\nAs far as I understand, the event.path is the mechanism to enable global reasoning about events. Optional event retargeting seems to be only complicating already complex algos. Consider a scenario where you have a mix of trees with and without retargeting.\n\n----\n\ncomment: 2\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444#c2\n*Anne* wrote on 2015-04-13 09:32:36 +0000.\n\nYeah, which is why perhaps we should only do retargeting if the tree is explicitly closed. (Isolated would also have to do it of course.)\n\nThat seems like a much more logical model and allows for event.path and event.target to be consistent. The current approach seems a lot like the originalTarget approach from XBL.\n\n----\n\ncomment: 3\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444#c3\n*Dimitri Glazkov* wrote on 2015-04-13 17:42:47 +0000.\n\n(In reply to Anne from comment #2)\n> Yeah, which is why perhaps we should only do retargeting if the tree is\n> explicitly closed. (Isolated would also have to do it of course.)\n\nThis suggestion is interesting, but it is orthogonal to the complexity concern. I would still need extra branch points in the retargeting algos in order to account for nested trees that interleave the setting with and without retargeting (whether or not coupled to the closed/open setting), plus the extra transitive complexity of managing insertion points.\n\n \n> That seems like a much more logical model and allows for event.path and\n> event.target to be consistent. The current approach seems a lot like the\n> originalTarget approach from XBL.\n\nCan you explain a bit more why event.path seems bad? As far as I can tell, it works well for consumers with event delegation needs.\n\n----\n\ncomment: 4\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444#c4\n*Dimitri Glazkov* wrote on 2015-04-13 18:01:23 +0000.\n\n+dfreedm to comment on the coupling of closed/open and retargeting opt-in idea.\n\n----\n\ncomment: 5\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444#c5\n*Daniel Freedman* wrote on 2015-04-13 22:17:16 +0000.\n\nI think retargeting events for \"open\" shadowroots is still the right paradigm.\n\nWhen composing elements with ShadowRoots together, it is far more useful to think of those elements as one whole, rather than their constituent pieces.\nWith retargeting, a developer can use very simple event delegation in their own scope with event.target for discrete composition points, rather than some more complicated ancestry checking.\n\nFor example:\n\nIf I have a fancy tab bar that controls content\n\n  <tab-bar>\n    #shadow-root\n      <t-ab id=\"one\">\n        #shadow-root\n          <fancy-ripple-effect></fancy-ripple-effect>\n          Tab One!\n      </t-ab>\n      <t-ab id=\"two\">\n        (..snip..)\n        Tab Two!\n      </t-ab>\n  </tab-bar>\n\nand click on the first tab, with retargeting I can just check event.target === #one to show the associated content.\n\nWith event retargeting, each composition boundary can have this simple event delegation construct and be very intuitive for development.\n\nI see event.path as more useful for a global event delegation mechanism, such as for determining desired scrolling behavior with touch events:\n\n  for (var i = 0, el; el = touchEvent.path[i]; i++)\n    if (el._shouldStopScrolling)\n      touchEvent.preventDefault();\n\n----\n\ncomment: 6\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444#c6\n*Hayato Ito* wrote on 2015-04-27 03:17:25 +0000.\n\nLet me move this bug to v2 since it is not a blocker for v1."}}