On Fri, Jan 11, 2013 at 3:54 PM, Dimitri Glazkov wrote:
> On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren wrote:
>> I want you to create a list :-)
Apologies for such a long delay. Dog-ate-homework, etc. Here's what
WebKit does. If interface isn't mentioned, then there's nothing
special goin
On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren wrote:
> On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov
> wrote:
>> Sure. Where are you seeing this list being mentioned? In Shadow DOM
>> spec or in DOM Core spec? I am happy to help, just not sure what
>> exactly I need to be doing :)
>
> I
On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov wrote:
> Sure. Where are you seeing this list being mentioned? In Shadow DOM
> spec or in DOM Core spec? I am happy to help, just not sure what
> exactly I need to be doing :)
I want you to create a list :-) Which attributes are initialized
versus
On Fri, Jan 11, 2013 at 11:28 AM, Anne van Kesteren wrote:
> On Fri, Jan 11, 2013 at 8:16 PM, Dimitri Glazkov
> wrote:
>> On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren wrote:
>>> Is that the case for all non-target/relatedTarget attributes that need
>>> adjustment? That they do not actual
On Fri, Jan 11, 2013 at 8:16 PM, Dimitri Glazkov wrote:
> On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren wrote:
>> Is that the case for all non-target/relatedTarget attributes that need
>> adjustment? That they do not actually need to be adjusted but are
>> calculated on getting based on the
On Fri, Jan 11, 2013 at 11:14 AM, Anne van Kesteren wrote:
>>> Normally with being a child of there would not be any
>>> adjustment.
>>
>> Yup. I don't understand whether you're just agreeing with me or disagreeing
>> :)
>>
>> With shadow trees in place, we need to let them react to events
>>
On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren wrote:
> On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov
> wrote:
>> Can you elaborate on this a bit more. Note, you don't need to compute
>> offsetX/Y until they are actually requested (which is what WebKit does
>> anyway).
>
> I see. That wo
On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov wrote:
> On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren wrote:
>> On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov
>> wrote:
>>> Okay, so event path would be (in tree order):
>>>
>>> -- [shadow root] -> .. -> -- -- [shadow
>>> root] -> ..
On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov wrote:
> Can you elaborate on this a bit more. Note, you don't need to compute
> offsetX/Y until they are actually requested (which is what WebKit does
> anyway).
I see. That would change matters indeed.
Is that the case for all non-target/related
On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren wrote:
> On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov
> wrote:
>> On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren wrote:
>>> My bad, I actually meant if 's associated shadow tree had an
>>> insertion point through which 's child, which i
On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov wrote:
> On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren wrote:
>> My bad, I actually meant if 's associated shadow tree had an
>> insertion point through which 's child, which is , would go and
>> then the event would be dispatched in 's associa
On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren wrote:
>
> My bad, I actually meant if 's associated shadow tree had an
> insertion point through which 's child, which is , would go and
> then the event would be dispatched in 's associated shadow tree. (I
> phrased that beyond poorly however and
On Tue, Jan 8, 2013 at 6:32 PM, Dimitri Glazkov wrote:
> 1) For a tree -- [shadow root] -> -- [shadow root] ->
> (where "->" denotes child-parent relationship and "--" denotes
> host-root relationship)
> 2) if an event is dispatched on
> 3) where is the event target's adjusted?
>
> If that's t
On Tue, Jan 8, 2013 at 6:26 AM, Anne van Kesteren wrote:
> On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov
> wrote:
>> Okay. Here is all the shadow DOM-related monkeypatching:
>>
>> 1) When dispatching events (http://dom.spec.whatwg.org/#dispatching-events),
>> on step 4, the event path is bui
On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov wrote:
> Okay. Here is all the shadow DOM-related monkeypatching:
>
> 1) When dispatching events (http://dom.spec.whatwg.org/#dispatching-events),
> on step 4, the event path is built using
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/sh
On Mon, Dec 17, 2012 at 1:48 PM, Dimitri Glazkov wrote:
5) Finally, whenever adjusted *relatedTarget* and *target* are the same,
> skip step 9.3 of http://dom.spec.whatwg.org/#concept-event-listener-invoke.
> The intent here is to not invoke event listeners on nodes where adjusting
> both relatedT
On Fri, Dec 14, 2012 at 12:18 PM, Anne van Kesteren wrote:
What would help me is to better understand the requirements of the
> shadow DOM with respect to event dispatch. To calculate the dispatch
> tree, you're using the event type, right? Then at certain points
> you're also making modifications
On Fri, Dec 7, 2012 at 6:38 PM, Dimitri Glazkov wrote:
> On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren wrote:
>> Well, eventually we might want to merge the whole DOM part of Shadow
>> DOM and DOM I think, but for now my proposition was that dispatch
>> calculates its tree in terms of asking
On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren wrote:
> On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov
> wrote:
> > The basic idea here is that some events, when they are dispatched in a
> > shadow tree, are more likely implementation details that aren't useful
> > outside of this tree. For
On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov wrote:
> The basic idea here is that some events, when they are dispatched in a
> shadow tree, are more likely implementation details that aren't useful
> outside of this tree. For example, if an with an image of a volume
> control loads inside of a
On Wed, Dec 5, 2012 at 9:48 AM, Anne van Kesteren wrote:
> On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov
> wrote:
> > Yes, the intent is that in the the events from nodes, distributed to
> > insertion points should feel as if there wasn't any shadow tree around
> them.
>
> Right, but if is in
On Wed, 5 Dec 2012, Anne van Kesteren wrote:
>
> Ian, for HTML that would allow easily dealing with the load exception on
> Window too.
The load exception is weirder than that. It's target is different than the
element that ever gets the event. Unless you mean the other exception, in
which cas
On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov wrote:
> Yes, the intent is that in the the events from nodes, distributed to
> insertion points should feel as if there wasn't any shadow tree around them.
Right, but if is inside the shadow tree (rather than distributed
into it), you do not want
On Wed, Dec 5, 2012 at 3:49 AM, Anne van Kesteren wrote:
> On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito wrote:
> > Some kinds of events should be always stopped at the shadow boundaries.
> > See
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events-that-are-always-stopp
On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito wrote:
> Some kinds of events should be always stopped at the shadow boundaries.
> See
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events-that-are-always-stopped
It's not entirely clear to me what that means. If an ends u
On Wed, Dec 5, 2012 at 8:16 PM, Anne van Kesteren wrote:
> On Wed, Dec 5, 2012 at 11:54 AM, Hayato Ito wrote:
>> Shadow DOM's event retargeting in WebKit uses one Event object for
>> every shadow trees.
>> When crossing shadow boundaries, an Event object's target (or
>> relatedTarget) is set to t
On Wed, Dec 5, 2012 at 11:54 AM, Hayato Ito wrote:
> Shadow DOM's event retargeting in WebKit uses one Event object for
> every shadow trees.
> When crossing shadow boundaries, an Event object's target (or
> relatedTarget) is set to the appropriate one, but the event object
> itself is reused.
In
Shadow DOM's event retargeting in WebKit uses one Event object for
every shadow trees.
When crossing shadow boundaries, an Event object's target (or
relatedTarget) is set to the appropriate one, but the event object
itself is reused.
FYI.
I've tried to implement event retargeting for seamless ifra
On Wed, Dec 5, 2012 at 1:02 AM, Ian Hickson wrote:
> I've done the HTML side of this (a paragraph), but the heavy lifting for
> this will be in DOM. Anne and I spoke about this earlier in #whatwg if you
> want to see the discussions. Some pointers to the logs can be found in the
> relevant DOM bug
On Mon, 9 Jul 2012, Ojan Vafai wrote:
>
> I'd like to see us add event propagation into the parent document for
> seamless iframes, e.g. key and mouse events inside a seamless iframe
> should be refired on the iframe element.
I've done the HTML side of this (a paragraph), but the heavy lifting f
On Tue, Jul 17, 2012 at 7:51 PM, Dimitri Glazkov wrote:
> An interesting quirk here is whether the full list of event ancestors
> should be computed ahead of time (per
> http://www.w3.org/TR/dom/#dispatching-events). If yes, then it's still
> just like retargeting, but with issuing a new event obj
An interesting quirk here is whether the full list of event ancestors
should be computed ahead of time (per
http://www.w3.org/TR/dom/#dispatching-events). If yes, then it's still just
like retargeting, but with issuing a new event object at the iframe
boundary. If no, then two separate dispatches w
On Tue, Jul 17, 2012 at 4:28 PM, Ojan Vafai wrote:
> It's not clear to me if any events should be exempt from this. For example,
> should focuses/blurs that are entirely contained within the seamless iframe
> fire in the outer document? My intuition is no, but I could easily be
> swayed either way
On Mon, Jul 16, 2012 at 9:24 AM, Dimitri Glazkov wrote:
> On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay
> wrote:
> >
> > On 07/14/2012 12:38 AM, Ojan Vafai wrote:
> >>
> >> It's been pointed out to me that what I'm asking for is essentially the
> >> same retargeting as we do for shadow DOMs in web
On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay wrote:
>
> On 07/14/2012 12:38 AM, Ojan Vafai wrote:
>>
>> It's been pointed out to me that what I'm asking for is essentially the
>> same retargeting as we do for shadow DOMs in web components, where the
>> iframe is the shadow host and the document is
On 07/14/2012 12:38 AM, Ojan Vafai wrote:
It's been pointed out to me that what I'm asking for is essentially the
same retargeting as we do for shadow DOMs in web components, where the
iframe is the shadow host and the document is the shadow root. This covers
all the details of what properties ne
It's been pointed out to me that what I'm asking for is essentially the
same retargeting as we do for shadow DOMs in web components, where the
iframe is the shadow host and the document is the shadow root. This covers
all the details of what properties need to be updated when crossing the
document
On Wed, Jul 11, 2012 at 3:38 AM, Chaals McCathieNevile wrote:
> On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai wrote:
>
>> Use-case 1: A global key event handler for keyboard shortcuts. Without
>> propagating the events, you need to add a key handler to each seamless
>> iframe's root in order for
On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai wrote:
I'd like to see us add event propagation into the parent document for
seamless iframes, e.g. key and mouse events inside a seamless iframe
should be refired on the iframe element.
The first two of these use cases make no sense to me (whi
I'd like to see us add event propagation into the parent document for
seamless iframes, e.g. key and mouse events inside a seamless iframe should
be refired on the iframe element.
Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key h
40 matches
Mail list logo
