[whatwg] Key handlers Re: seamless iframes and event propagation

Chaals McCathieNevile w3b at chaals.com
Thu Jul 12 04:08:43 PDT 2012

On Thu, 12 Jul 2012 01:23:07 +0200, Ojan Vafai <ojan at chromium.org> wrote:

> 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 something 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.

I'm not suggesting that we make it not work. Just that we don't make it a  
whole lot easier. Because it is (IMHO, obviously) harmful to the web and  
its ability to evolve.

One way to address it directly is to put our efforts into making better  
alternatives easier, rather than putting them into implementing things  
which reinforce the idea that the anti-pattern is the easiest way to  
achieve a goal.

>> (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?

Very roughly, because it is a passive declaration of intent that can be  
easily rewritten by the user agent in case of conflict. Javascript  
keyhandlers are an active intervention in what is often part of the user's  
expected interaction behaviour (specifically, in the case where they use  
the keyboard for some functionality). Thus it leads to surprises when a  
key does something unexpected.



>>> On Sat, May 26, 2012 at 5:16 PM, Adam Barth <w3c at adambarth.com> wrote:
>>>> 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>

Chaals - standards declaimer

More information about the whatwg mailing list