Hi Dimitri,
On Feb 7, 2012, at 18:26 , Dimitri Glazkov wrote:
Robin, this is a pretty interesting and thoughtful treatise and while
I am still digesting parts of it, I can't help but think that the key
in identifying precise boundaries and relative position of these two
universes is defining
This is a Call for Consensus to publish a new WD of the Clipboard API
and events spec using the latest ED as the basis (Hallvord has not yet
prepared it for publication in /TR/):
http://dev.w3.org/2006/webapi/clipops/clipops.html
Agreement to this proposal: a) indicates support for
On Wednesday, February 8, 2012 at 10:33 PM, Adrienne Porter Felt wrote:
I agree that the current UI is not great. However, I disagree about
everyone clicking through permission grants. I've done two user studies
and found that about ~18% of people look at permissions for a given
Hi Hallvord,
At
http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interface,
a reference to DOM *2* Events is made; it should be updated.
Also, the initClipboardEvent method should be removed in favour of a
constructor, as described at
Anne van Kesteren ann...@opera.com skreiv Fri, 09 Sep 2011 16:48:36 +0200
As a high-level comment it seems to me the organization of the
specification needs some changing. The processing model is about how to
deal with a copy/paste/cut operation it is not about firing an event
(that is
Ms2ger ms2...@gmail.com skreiv Thu, 09 Feb 2012 13:26:39 +0100
http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interface,
a reference to DOM *2* Events is made; it should be updated.
Well, I guess it should.
On the other hand..what should it be updated to?
AFAIK DOM3
Ms2ger,
the same old issue with referencing a released spec or not... that was heavily
discussed!
Or am I wrong?
Is there any reason that makes that sentence obsolete in DOM 2?
I would have no issue that the clipboard document references both but it would
become unreleasable if it had to rely
On Wed, 08 Feb 2012 22:38:51 +0100, Robin Berjon ro...@berjon.com wrote:
On Feb 8, 2012, at 13:29 , Charles McCathieNevile wrote:
thanks to Mike and the Google guys, we have
http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html
which explains what an IME API would do and
On Thursday, February 9, 2012 at 4:18 AM, Andres Riofrio wrote:
Regarding the checklist: perhaps these things are only relevant if there are
Christian/Jewish/Muslim people in the group. And if there are people that
prefer not to meet on Saturday. It seems to me more reasonable to expect
Hey everyone,
I've been following the HTML Parsing and the template element
thread/conversation since it began yesterday and it's very interesting, but
one thing keeps coming to mind - has anyone working on template spent any
significant time using the existing web template systems and practices?
On 2/9/12 1:21 PM, Marcos Caceres w...@marcosc.com wrote:
On Wednesday, February 8, 2012 at 10:33 PM, Adrienne Porter Felt wrote:
I agree that the current UI is not great. However, I disagree about
everyone clicking through permission grants. I've done two user
studies and found that about
On Thursday, February 9, 2012 at 3:17 PM, Tobie Langel wrote:
The correlation between the number of permissions requested by the app and
the percentage of users which will avoid using the app altogether is
strong, so much so that we're warning devs against asking for too many
permissions
I've been working with cross-domain iframes. This technology has a lot
of potential, but the current API is very difficult to use. Just
search the web for cross-domain iframe info and you can read how many
developers are confused.
I believe a simple change could make a huge difference. My
On 2/9/12 12:04 PM, John J Barton wrote:
As far as I can tell, a cross-domain iframe contentWindow has only one
valid property, postMessage(). By no stretch of anyone's imagination
is the object a window. Calling this thing we get a contentWindow
is a mean lie to developers; it forces us into
On Thu, Feb 9, 2012 at 9:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/9/12 12:04 PM, John J Barton wrote:
As far as I can tell, a cross-domain iframe contentWindow has only one
valid property, postMessage(). By no stretch of anyone's imagination
is the object a window. Calling this thing
On 2/9/12 12:43 PM, John J Barton wrote:
The drawback is that your fallback behavior in UAs without support for the
new feature is quite different. Is that a problem? Developer feedback
definitely needed there.
Extending the API on iframe would make fallback easy even though it
lacks
On Thu, Feb 9, 2012 at 10:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/9/12 12:43 PM, John J Barton wrote:
The drawback is that your fallback behavior in UAs without support for
the
new feature is quite different. Is that a problem? Developer feedback
definitely needed there.
Recently I've been working with iframe messaging. The postMessage
solution has a lot of advantages and good traction across iframes,
WebWorkers, and browser extensions, with lots of overlap with Web
Sockets.
However the technology has two significant problems. First is the
contentWindow that is
On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote:
On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
== IDEA 1: Keep template contents parsing in the tokenizer ==
Not this!
Here's why:
Making something look like markup but then not tokenizing
On 2/9/12 1:15 PM, John J Barton wrote:
This leads developers to look for events that will tell them about
'load' on iframes, and that leads them to try
iframe.contentWindow.addEventListener(). It works fine for same-domain
iframes, but fails for cross-domain.
Adding a load listener to the
As you are saying, we seem to be talking of different things, even if I
have a problem seeing how different.
You make a difference between apps using web technologies accessed by
HTTP or not, which I thought close to installed or not.
You postulate the absence of a safe and usable way of
On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/9/12 1:15 PM, John J Barton wrote:
This leads developers to look for events that will tell them about
'load' on iframes, and that leads them to try
iframe.contentWindow.addEventListener(). It works fine for
On Thu, Feb 9, 2012 at 6:56 AM, Rick Waldron waldron.r...@gmail.com wrote:
Hey everyone,
I've been following the HTML Parsing and the template element
thread/conversation since it began yesterday and it's very interesting, but
one thing keeps coming to mind - has anyone working on template
On Thu, Feb 9, 2012 at 11:49 AM, Boris Zbarsky bzbar...@mit.edu wrote:
That doesn't help with the second problem, of course
Ok here are some ideas, riffing off the web messaging doc
1 To iframe element add:
readonly attribute MessagePort port;
'message' events from the iframe to the
On Wed, 18 May 2011, Daniel Cheng wrote:
On Wed, May 18, 2011 at 16:54, Hallvord R. M. Steen hallv...@opera.comwrote:
Not 100% sure what you mean by concerns - do you mean for example if
I drag a selection that embeds local images from my local word
processing application to an online
On Thu, 9 Feb 2012, John J Barton wrote:
However the solution has two significant problems:
1. There is no way to know if portToOtherWindow is connected before
you issue postMessage()
Just have the target message you when it's ready.
2. All iframes send messages to the same handler.
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
However the solution has two significant problems:
1. There is no way to know if portToOtherWindow is connected before
you issue postMessage()
Just have the target message you when
On Thu, 9 Feb 2012, John J Barton wrote:
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 9 Feb 2012, John J Barton wrote:
However the solution has two significant problems:
1. There is no way to know if portToOtherWindow is connected before
you issue
28 matches
Mail list logo
