W3C home > Mailing lists > Public > public-webapps-bugzilla@w3.org > August 2012

[Bug 18630] New: [Shadow]: It's unclear where a 'load' event is fired for replaced elements where author shadow root is attached.

From: <bugzilla@jessica.w3.org>
Date: Mon, 20 Aug 2012 23:01:02 +0000
To: public-webapps-bugzilla@w3.org
Message-ID: <bug-18630-2532@http.www.w3.org/Bugs/Public/>

           Summary: [Shadow]: It's unclear where a 'load' event is fired
                    for replaced elements where author shadow root is
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
        AssignedTo: dglazkov@chromium.org
        ReportedBy: hayato@chromium.org
         QAContact: public-webapps-bugzilla@w3.org
            Blocks: 14978

The spec says:
> 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'>

Next, we attach an author shadow root (and its children) to an image element

<img src='a.png'>
     - <div id=B>
        - <shadow>

So a composed shadow tree would become:

 <img id=A src='a.png'>
    <div id=B>

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

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.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 20 August 2012 23:01:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 August 2012 23:01:05 GMT