15969 2012-02-13 07:07:02 +0000 [Shadow]: Document.activeElement should be mentioned. 2012-02-20 09:47:06 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 14978 15967 1 morrita dglazkov dominicc public-webapps-bugzilla oldest_to_newest 64016 0 morrita 2012-02-13 07:07:02 +0000 This may be more implementation-like than for this standard but... Docuent.activeElement should return null when the focus is inside - a shadow - a frame in a shadow. Feel free just to close this if this is out of the standard scope. 64020 1 dominicc 2012-02-13 08:08:40 +0000 Should it return null, or should it be "retargeted" to the outermost host? Is there a design principle that anytime one of these DOM attributes/methods is modified to make sense for shadows, that the API should be replicated on the ShadowRoot to provide "scoped" semantics? 64023 2 morrita 2012-02-13 09:06:34 +0000 (In reply to comment #1) > Should it return null, or should it be "retargeted" to the outermost host? I think returning null is reasonable because there are few usecases which can use scoped activeElement. For example, we cannot click() to activate it. we cannot executeCommand() it. etc. > > Is there a design principle that anytime one of these DOM attributes/methods is > modified to make sense for shadows, that the API should be replicated on the > ShadowRoot to provide "scoped" semantics? Good point. I hope we could minimize the # of API. So most of "short-hand" type API like named getter won't be replicated. For activeElement(), maybe we need this because there is no alternative way to expose the fact. 64059 3 dominicc 2012-02-14 00:46:05 +0000 (In reply to comment #2) > (In reply to comment #1) > > Should it return null, or should it be "retargeted" to the outermost host? > I think returning null is reasonable because there are few usecases which can > use > scoped activeElement. For example, we cannot click() to activate it. we cannot > executeCommand() it. > etc. But consider how activeElement works when the focus is inside an iframe--the activeElement of the outer document is the iframe. Focus inside shadow should work the same way. > I hope we could minimize the # of API. I think consistency should be the goal. I think we should try to use this standard: If I move a chunk of markup from the document into a ShadowRoot, does the code continue to work, as long as I replace document. with s. where s is a reference to the containing shadow root? 64062 4 morrita 2012-02-14 04:03:03 +0000 (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Should it return null, or should it be "retargeted" to the outermost host? > > I think returning null is reasonable because there are few usecases which can > > use > > scoped activeElement. For example, we cannot click() to activate it. we cannot > > executeCommand() it. > > etc. > > But consider how activeElement works when the focus is inside an iframe--the > activeElement of the outer document is the iframe. Focus inside shadow should > work the same way. That's true. > > > I hope we could minimize the # of API. > > I think consistency should be the goal. I think we should try to use this > standard: > > If I move a chunk of markup from the document into a ShadowRoot, does the code > continue to work, as long as I replace document. with s. where s is a reference > to the containing shadow root? > OK. We need to investigate Document.idl to triage APIs to pick. Just to clarify: we are not going to allow simple s/document/s/ replacement but require developers to pick one of these two instead, right? For example, Do we need ShadowRoot::createElement() ? My understanding is no. But the naive understanding of the check above says yes. 64191 5 dglazkov 2012-02-16 21:15:09 +0000 Since the shadow DOM elements do participate in document focus navigation, we will indeed have situations where the document.activeElement will technically point to an element in a shadow DOM subtree. To maintain encapsulation, we should retarget. Otherwise, the information about a focused element will be lost, and that seems inconsistent. I like Dominic's iframe focus analogy: http://jsfiddle.net/nPLTD/ Since we retarget, we should somehow stash the actual value. I like the idea of adding an accessor on the ShadowRoot. Will spec. 64195 6 dglazkov 2012-02-16 22:43:29 +0000 WDYT? http://dvcs.w3.org/hg/webcomponents/rev/5037164fd76e As added bonus, I also made ShadowRoot receive events, since listening to events at the top of the shadow DOM subtree seems like a useful feature. 64249 7 dglazkov 2012-02-17 18:42:42 +0000 Please reopen if I messed up. 64298 8 morrita 2012-02-20 09:47:06 +0000 Looks good. Thanks for caring.