- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Tue, 7 Jun 2011 13:47:52 -0700
- To: "sird@rckc.at" <sird@rckc.at>
- Cc: public-web-security@w3.org
> Yes, so making this configurable from within the feature > (force-visibility: none | Ns) would make this better? Possibly. This is a bit more tricky, because you also need to handle moving frames / windows, etc, but in general, yup. > Also, I read the previous conversation in WHATWG, but couldn't find > anything regarding this, you mean the solution (2)? or (3)? I haven't proposed on-top attribute, but proposal (3) had similar considerations in terms of ensuring that the element is not obstructed (instead of force-on-top, it had something like only-work-if-on-top), and in terms of the need to ensure some amount of uninterrupted screen time, sufficient dimensions, etc. I suspect that these aspects were one of the reasons why people hated it back then. Now, arguably, neither of the proposals is strictly hard: IIRC, Flash is already doing "am I visible" checks by scraping the screen (or so I was told, haven't looked at their implementation). PS. I wouldn't dismiss keyboard input too quickly. Some webpages auto-focus certain buttons or form fields, and you can focus() on the container frame itself first. In such a situation, a single <space> or <return> keypress may have some unintended consequences. Perhaps not for existing "like" buttons, though. /mz
Received on Tuesday, 7 June 2011 20:48:39 UTC