[whatwg] seamless iframes and event propagation

[Ojan Vafai]

On Wed, Jul 11, 2012 at 3:38 AM, Chaals McCathieNevile <w3b at chaals.com>wrote:

> On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai <ojan at 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
>> iframe's root in order for these keyboard handlers to work when the
>> iframe has focus.
>>
>
> Using javascript for keyboard shortcuts is not a good idea in the first
> place. People will keep doing it instead of something more scalable to the
> web like improving their accesskey implementations, but we should not be
> encouraging it, by making it easier to do the wrong thing instead of
> somethign useful.
>

In practice, this is a very common thing to do. Making seamless iframes not
work for this thing people are already doing seems backwards to me. We
should address the problems with why doing this in JS is problematic
directly.

(The problem is that javascript key handlers generally do not
> internationalise well, are awful across a wide range of devices, and are
> almost guaranteed to fail future devices).


How does accesskey improve on this?

 Use-case 2: A dragging UI. Without event propagation, if you don't add
>> handlers to the iframe's root, you would just stop dragging when the
>> mouse is over seamless iframes. In addition, the coordinates of the mouse
>> event should be changed to the parent document's coordinate space when it
>> is refired on the iframe, otherwise your code needs to know when it's
>> over an iframe.
>>
>
> Isn't this why we introduced native drag and drop to HTML?
>

This isn't about drag-dropping. It's about dragging within a web page (e.g.
a dialog). Again, there's a ton of code out there that does this. Making it
all retrofit to understand seamless seems like a non-starter to me. So, in
practice, any site that uses code like this and starts using seamless
iframes will have a crappy user experience.


> cheers
>
> Chaals
>
>  We should fire two events. One inside the iframe and one on the iframe
>> element itself (in the parent document). Any pointers to DOM nodes in the
>> event would need to be nulled out in the event fired in the parent
>> document if the seamless iframe is cross-domain and non-CORS accessible.
>>
>> This makes seamless iframes more seamless. Most existing keyboard
>> shortcut and dragging JS code would magically keep working without needing
>> to know anything about seamless.
>>
>> Use-case 3: Making an email client that wants the content of the email
>> isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
>> the editable area sizes to the emails size). In this case, you don't want
>> to inherit the CSS for the mail client into the email's content.
>> Similarly, you may not want your global keyboard handlers to run when
>> typing in the editable area.
>>
>> Similar to Adam's allow-seamless proposal, I'd like to see seamless have
>> the ability to tweak which bits of the frame act seamlessly. Adam's
>> proposal has inherit-styles. We could also add propagates-events to
>> allow-seamless. Both of those would be off by default. For seamless, we
>> could have no-inherit-styles and no-propagate-events in order to disable
>> either behavior, also off by default.
>>
>> Ojan
>>
>> On Sat, May 26, 2012 at 5:16 PM, Adam Barth <w3c at adambarth.com> wrote:
>>
>>  Hi whatwg,
>>>
>>> I've added a proposal to the wiki
>>> <http://wiki.whatwg.org/wiki/**AllowSeamless<http://wiki.whatwg.org/wiki/AllowSeamless>>
>>> about letting a document
>>> indicate that it is willing to be displayed seamlessly with a
>>> cross-origin parent.  This proposal is a refinement of the approach
>>> previously discussed in this thread:
>>> <http://old.nabble.com/**crossorigin-property-on-**
>>> iframe-td33677754.html<http://old.nabble.com/crossorigin-property-on-iframe-td33677754.html>
>>> >.
>>>
>>> Let me know if you have any feedback.
>>>
>>> Thanks!
>>> Adam
>>>
>>>
>
> --
> Chaals - standards declaimer
>