On Feb 12, 2014, at 2:33 PM, Jonas Sicking <[email protected]> wrote:
> On Wed, Feb 12, 2014 at 2:08 PM, Ryosuke Niwa <[email protected]> wrote: >> On Feb 12, 2014, at 11:23 AM, Rafael Weinstein <[email protected]> wrote: >>> In a certain sense, you can extend the argument that CE callbacks should be >>> MO records, and you arrive at the conclusion that you don't need Custom >>> Elements at all -- that everything can be implemented with Mutation >>> Observers. But the point of Custom Elements is two fold: >>> >>> 1) To allow implementation of Elements by user-space code in roughly the >>> same model as privileged code. >>> 2) To explain the platform. >>> >>> Put another way: the *implementation* of an element simply needs to be >>> privileged in some respects. For custom elements, this means >>> >>> a) There can only be one. I.e., we don't allow multiple registration of the >>> same element: Primary behavior is the domain of custom elements, secondary >>> behavior is the domain of Mutation Observers >>> b) Callbacks need to fire ASAP. It's important that the implementation of >>> an element get a chance to respond to events before other concerns so that >>> it can create a synchronously consistent abstraction >> >> I'm not convinced that only custom elements require a synchronously >> consistent abstraction. > > I want to be *very* careful about exposing synchronous callbacks. > While I'm sure a lot of authors will ask for it, it's a tremendous foot gun. Right. This is why I’d like to know exactly why end-of-microtask synchronicity isn’t sufficient for custom elements. > The first type of footgun that it is is that authors can footgun > themselves when using these callbacks. For example by accidentally > calling into external code while they are in an inconsistent state. > Another thing to remember here is that you can only really have one > consumer that truly receives synchronous callbacks. The moment you > have two observers it means that the second observer doesn't have time > to react before the first observer runs. This can be a problem both > for the first observer, since it sees a world where the mutation has > happened, but where the second observer hasn't had time to react to > it, and for the second observer, since the world can have changed > under it before it has had a chance to react to a mutation. That is a good point. There is a clear disadvantage in the case of multiple observers observing the same node. > The second type of footgun is that by adding synchronous callbacks, we > are limiting our own ability to extend and optimize the platform since > we have to worry about JS callbacks running at inopportune times. So > by adding synchronous callbacks, we're footgunning ourselves. But why is it okay to add semi-synchronous callbacks to custom elements then? >>> I think there's an argument to be made that Mutation Observers *should* be >>> extended to allow for observation of trees which include DOM reachable >>> through shadowRoots. The motivation for this would be to allow existing >>> de-coupled concerns to operate faithfully in the presence of custom >>> elements implemented with shadowDOM. The obvious concern here is that >>> de-coupled code may interfere with the implementation of elements, but >>> that's no more true with custom elements than it is today, and shadowRoot >>> is imperatively public, it's consistent to allow MutationObservers to >>> continue to fully observe a document. >> >> I think this would be a nice opt-in feature; component authors should be >> able to choose whether or not to expose its internal DOM in embedding >> documents. > > For now Mutation Observation never crosses shadow DOM boundaries. When > we add that ability I think it needs to be explicitly opted into, and > even when explicitly opted into, it should not cross the boundary into > private shadow DOM trees. > > In short, I think this is an orthogonal discussion, and should follow > the decision of the open/close debate. This is just one more aspect of > how shadow DOM nodes can be exposed and should follow the policies > that are used elsewhere. I agree. This should be discussed separately. - R. Niwa
