18630 2012-08-20 23:01:02 +0000 [Shadow]: It's unclear where a 'load' event is fired for replaced elements which has an author shadow root. 2012-08-20 23:22:50 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED WONTFIX P2 normal --- 14978 1 hayato dglazkov shinyak public-webapps-bugzilla oldest_to_newest 72451 0 hayato 2012-08-20 23:01:02 +0000 The spec says: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements > all HTML elements must have an equivalent of a shadow DOM subtree that is created and populated at the time of element instantiation. According to the spec, <img> element should have a shadow DOM subtree like: <img id=A src='a.png'> -#shadow-root <real-image-implementation> Next, we attach an author shadow root (and its children) to an image element like: <img src='a.png'> -#shadow-root <real-image-implementation> -#author-shadow-root - <div id=B> - <shadow> So a composed shadow tree would become: <img id=A src='a.png'> <div id=B> <real-image-implementation> My question is: - Where a 'load' event should be fired after 'a.png' is loaded? Option A) On an <img id=A> element directly. Option B) On a <real-image-implementation> so that <div id=B> can receive an load event. If we adopt option B, we must not stop the 'load' event at shadow boundary of <img>. That means: - We should not stop a load event if it is fired on real-image-implementation at the shadow boundary between <img> and <real-image-implementation>. - We should stop other load events at the shadow boundary. 72452 1 hayato 2012-08-20 23:03:52 +0000 My preference is option B. 72453 2 dglazkov 2012-08-20 23:06:27 +0000 (In reply to comment #1) > My preference is option B. Can you explain why? 72454 3 hayato 2012-08-20 23:09:09 +0000 I don't have a strong technical reason, but it looks natural for me at first glance. (In reply to comment #2) > (In reply to comment #1) > > My preference is option B. > > Can you explain why? 72455 4 dglazkov 2012-08-20 23:17:35 +0000 (In reply to comment #3) > I don't have a strong technical reason, but it looks natural for me at first > glance. Here's why I think we should stay with option A (which is what is in HTML spec right now): 1) No additional work necessary. The HTML spec clearly states that the event is dispatched on HTMLImageElement. 2) Logically, there's a clear separation of responsibilities. The <real-image-implementation> is just a pixel surface. The loading machinery lives in HTMLImageElement, where it should be. In a way, the <real-image-implementation> could be just a canvas tag. It has no loading/error plumbing whatsoever. 72456 5 hayato 2012-08-20 23:22:50 +0000 Okay. Thank you. I don't have strong opinion on this because we don't have a strong use case that requires option B. Let's close the bug. Shinya, please feel free to reopen this if you encounter a use case which requires option B. (In reply to comment #4) > (In reply to comment #3) > > I don't have a strong technical reason, but it looks natural for me at first > > glance. > > Here's why I think we should stay with option A (which is what is in HTML spec > right now): > > 1) No additional work necessary. The HTML spec clearly states that the event is > dispatched on HTMLImageElement. > > 2) Logically, there's a clear separation of responsibilities. The > <real-image-implementation> is just a pixel surface. The loading machinery > lives in HTMLImageElement, where it should be. In a way, the > <real-image-implementation> could be just a canvas tag. It has no loading/error > plumbing whatsoever.