This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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?
(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.
(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?
(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.
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.
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.
Please reopen if I messed up.
Looks good. Thanks for caring.