On Tue, May 10, 2011 at 06:49, Olli Pettay olli.pet...@helsinki.fi wrote:
On 05/10/2011 01:44 AM, Aryeh Gregor wrote:
On Mon, May 9, 2011 at 3:49 PM, Boris Zbarskybzbar...@mit.edu wrote:
This does mean firing tens of thousands of events during load on some
pages
(e.g. wikipedia article
On Mon, May 2, 2011 at 5:25 PM, Marcos Caceres marcosscace...@gmail.com wrote:
On Friday, April 29, 2011 at 8:19 PM, frederick.hir...@nokia.com wrote:
Marcos
I'd suggest you first send an email with the top 10 substantive changes to
the list, e.g. which algorithms change from mandatory to
Is there an appropriate next step to advance this proposal? It seems
like there is interest in this approach. Does it need to be written up
in a more formal spec?
Thanks,
Kris
On 2/18/2011 10:03 AM, Sean Eagan wrote:
Very exciting proposal! I hope my comments below can help move it along.
Hi, Hallvord-
The testing we did on this issue was inconsistent between different
implementations in combination with different IMEs. So, we did add a
note mentioning possible key suppression.
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#key-IME-suppress
Please
On Tue, May 10, 2011 at 1:42 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
Something like that might be better. Do you have the exact API in mind?
Well, just the same as I originally proposed, except with arrays
instead of scalars. But Hironori Bono's reply has mooted this idea
anyway.
The people working on the DOM 3 Events spec have resolved all the
issues we believe are critical for DOM3 Events vis-à-vis the September
2010 LCWD [LC-2010], and have addressed the issues regarding
discrepancies between D3E and DOM Core [Mins]. As such, they now propose
the WG publish a new
2011/5/11 Aryeh Gregor simetrical+...@gmail.com:
Here's an alternative suggestion that addresses the issues I had
above, while (I think) still addressing all your use-cases. Create a
new interface:
interface SpellcheckRange {
readonly unsigned long start;
readonly unsigned long length;
2011/5/11 timeless timel...@gmail.com:
With this model, i'd want the UA to provide instances for words which
are misspelled according to its standard dictionary but which are in
its user's custom dictionary. The web page can try to make
suggestions, but generally the UA will choose to ignore
The Editor's Draft of the FileAPI --
http://dev.w3.org/2006/webapi/FileAPI/ -- has had some updates. These
are the notable changes:
1. Blob.slice behavior has changed to more closely match
String.prototype.slice from ECMAScript (and Array.prototype.slice
semantically). I think we're the
On 05/12/2011 01:29 AM, Aryeh Gregor wrote:
2011/5/11 timelesstimel...@gmail.com:
With this model, i'd want the UA to provide instances for words which
are misspelled according to its standard dictionary but which are in
its user's custom dictionary. The web page can try to make
suggestions,
I think I have raised my concern before but what should happen if script
calls getData() within a copy/cut event handler? Should it return the
clipboard content after taking account the values set by setData? Or should
it always return the same value? Or should script be banned from calling
I've grouped responses to bits of this thread so far below:
Glenn said:
If *this API's* concept of filenames is case-insensitive, then IMAGE.JPG
and image.jpg represent the same file on English systems and two different
files on Turkish systems, which is an interop problem.
Timeless replied:
On Thu, May 12, 2011 at 2:08 AM, Eric U er...@google.com wrote:
Timeless replied:
no, if the api is case insensitive, then it's case insensitive
*everywhere*, both on Turkish and on English systems. Things could
only be case sensitive when serialized to a real file system outside
of the API.
On Wed, May 11, 2011 at 7:08 PM, Eric U er...@google.com wrote:
*everywhere*, both on Turkish and on English systems. Things could
only be case sensitive when serialized to a real file system outside
of the API. I'm not proposing a case insensitive system which is
locale aware, i'm
On Wed, May 11, 2011 at 4:47 PM, timeless timel...@gmail.com wrote:
On Thu, May 12, 2011 at 2:08 AM, Eric U er...@google.com wrote:
Timeless replied:
no, if the api is case insensitive, then it's case insensitive
*everywhere*, both on Turkish and on English systems. Things could
only be case
On Wed, May 11, 2011 at 4:52 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, May 11, 2011 at 7:08 PM, Eric U er...@google.com wrote:
*everywhere*, both on Turkish and on English systems. Things could
only be case sensitive when serialized to a real file system outside
of the API. I'm not
On Wed, May 11, 2011 at 8:13 PM, Eric U er...@google.com wrote:
So it's not locale-sensitive unless it is, but nobody does that
anyway, so don't worry about it? I'm a bit uneasy about that in
general, but Windows not supporting it is a good point.
It's not locale-sensitive at all, unless
On Wed, May 4, 2011 at 2:46 PM, Daniel Cheng dch...@chromium.org wrote:
From my understanding, we are trying to protect against [1] hidden data
being copied without a user's knowledge and [2] XSS via pasting hostile
HTML. In my opinion, the algorithm as written is either going to remove too
On Wednesday, May 11, 2011, Eric U er...@google.com wrote:
I've grouped responses to bits of this thread so far below:
Glenn said:
If *this API's* concept of filenames is case-insensitive, then IMAGE.JPG
and image.jpg represent the same file on English systems and two different
files on
On Wed, May 11, 2011 at 7:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wednesday, May 11, 2011, Eric U er...@google.com wrote:
I've grouped responses to bits of this thread so far below:
Glenn said:
If *this API's* concept of filenames is case-insensitive, then IMAGE.JPG
and image.jpg
Greetings Aryeh, et al,
Thank you for your alternative suggestion.
In my honest opinion, I do not stick to my interfaces so much if there
are better alternatives. My proposal is just based on my prototype,
which has been uploaded to http://webkit.org/b/59693, and I wish
someone in this ML
21 matches
Mail list logo
