On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai <[email protected]> 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 (which might just be
because I am not very bright, or missing something...)
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.
(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).
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?
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 <[email protected]> wrote:
Hi whatwg,
I've added a proposal to the wiki
<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>.
Let me know if you have any feedback.
Thanks!
Adam
--
Chaals - standards declaimer
