I'd like to see if I can move this forward a bit. Let's drop some of
my original suggestions and break the solution into two separate
simple features that we can discuss independently. Firstly, of the
problems with overlays listed in my original email ([1]), I think the
following are the most
an overlay/infobar would opt to use a method that
forces the overlay/infobar to be displayed, even if that means continuing
with their current implementations.
On Wed, Feb 10, 2010 at 2:00 AM, Martin Atkins m...@degeneration.co.uk
wrote:
Rowan Nairn wrote:
Hi,
In the spirit of paving some cow
Hi,
In the spirit of paving some cow paths I'd like to put forward a
proposal for a future version of HTML. The behavior I'm addressing is
sites that replace links to external content with a framed version of
that content, along with their own overlay of information and links.
I think with some
On Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/5/10 5:40 PM, Rowan Nairn wrote:
- don't introduce new security issues like susceptibility to phishing
attacks
- The main URL bar should display the framed URL i.e.
http://destination-site.com/
I'm having
On Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/5/10 5:40 PM, Rowan Nairn wrote:
- don't introduce new security issues like susceptibility to phishing
attacks
- The main URL bar should display the framed URL i.e.
http://destination-site.com/
I'm having
On Sun, Oct 18, 2009 at 4:30 AM, Ian Hickson ian at hixie.ch wrote:
My recomendation would be to follow the process for adding features:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
In particular the bit about experimental
Hi, I'm new to the list so I'm not sure if this is beyond scope or not
but has anybody thought about what kind of mouse events we would like
to get, say the iPhone (or similar) passes all the touches on to the
DOM?
I'm thinking the minimal helpful API change would be a new field for
the Event
