On Fri, Jan 11, 2013 at 3:54 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren ann...@annevk.nl 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
On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
My bad, I actually meant if a's associated shadow tree had an
insertion point through which a's child, which is b, would go and
then the event would be dispatched in b's associated shadow tree. (I
phrased that beyond
On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
My bad, I actually meant if a's associated shadow tree had an
insertion point through which a's child, which is b, would go and
then the event
On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
My bad, I actually meant if a's associated shadow tree had an
On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov dglaz...@chromium.org 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
On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Okay, so event path would be (in tree order):
a -- [shadow
On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov dglaz...@chromium.org
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
On Fri, Jan 11, 2013 at 11:14 AM, Anne van Kesteren ann...@annevk.nl wrote:
Normally with b being a child of a 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 8:16 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren ann...@annevk.nl 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
On Fri, Jan 11, 2013 at 11:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 11, 2013 at 8:16 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren ann...@annevk.nl wrote:
Is that the case for all non-target/relatedTarget attributes
On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov dglaz...@chromium.org 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
On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov dglaz...@chromium.org
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
On Tue, Jan 8, 2013 at 6:32 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
1) For a tree a -- [shadow root] - b -- [shadow root] - c
(where - denotes child-parent relationship and -- denotes
host-root relationship)
2) if an event is dispatched on c
3) where is the event target's adjusted?
On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov dglaz...@chromium.org 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
On Tue, Jan 8, 2013 at 6:26 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Okay. Here is all the shadow DOM-related monkeypatching:
1) When dispatching events (http://dom.spec.whatwg.org/#dispatching-events),
on
On Mon, Dec 17, 2012 at 1:48 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
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
On Fri, Dec 14, 2012 at 12:18 PM, Anne van Kesteren ann...@annevk.nlwrote:
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
On Fri, Dec 7, 2012 at 6:38 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren ann...@annevk.nl 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
On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov dglaz...@chromium.org 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 img with an image of a volume
On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov dglaz...@chromium.org
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
On Wed, Dec 5, 2012 at 9:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov dglaz...@chromium.org
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
On Wed, Dec 5, 2012 at 1:02 AM, Ian Hickson i...@hixie.ch 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
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
On Wed, Dec 5, 2012 at 11:54 AM, Hayato Ito hay...@chromium.org 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
On Wed, Dec 5, 2012 at 8:16 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Dec 5, 2012 at 11:54 AM, Hayato Ito hay...@chromium.org 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
On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito hay...@chromium.org 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
On Wed, Dec 5, 2012 at 3:49 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito hay...@chromium.org wrote:
Some kinds of events should be always stopped at the shadow boundaries.
See
On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov dglaz...@chromium.org 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 img is inside the shadow tree (rather than distributed
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 case,
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 for
On Tue, Jul 17, 2012 at 7:51 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
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
On Mon, Jul 16, 2012 at 9:24 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay olli.pet...@helsinki.fi
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
On Tue, Jul 17, 2012 at 4:28 PM, Ojan Vafai o...@chromium.org 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
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
On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay olli.pet...@helsinki.fi 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
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
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 Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai o...@chromium.org 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
On Wed, Jul 11, 2012 at 3:38 AM, Chaals McCathieNevile w...@chaals.comwrote:
On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai o...@chromium.org 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
On Wed, 4 Apr 2012, Ojan Vafai wrote:
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2
already expects iframe:not([seamless]) { border: 2px inset; }. In 90%
percent of uses, seamless iframes will not want a border
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
Am 05.04.2012 03:59 schrieb Ojan Vafai:
On Wed, Apr 4, 2012 at 6:52 PM, Ojan Vafaio...@chromium.org wrote:
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
expects iframe:not([seamless]) { border: 2px inset;
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
expects iframe:not([seamless]) { border: 2px inset; }. In 90% percent of
uses, seamless iframes will not want a border and will want to fill their
container. This
On Wed, Apr 4, 2012 at 6:52 PM, Ojan Vafai o...@chromium.org wrote:
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
expects iframe:not([seamless]) { border: 2px inset; }. In 90% percent of
uses, seamless
44 matches
Mail list logo
