> 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. /mzReceived on Tuesday, 7 June 2011 20:48:39 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 June 2011 20:48:40 GMT