[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.
[...]
cheers
Chaals
>>> 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