On Mon, Jul 4, 2011 at 8:40 PM, John J. Barton
johnjbar...@johnjbarton.comwrote:
On 7/4/2011 6:39 PM, Boris Zbarsky wrote:
On 7/4/11 12:23 PM, John J. Barton wrote:
By restricting mutation listeners to explicitly avoid DOM mutation, the
most sophisticated case is no different than the
On 07/04/2011 09:14 PM, John J. Barton wrote:
On 7/4/2011 9:38 AM, Olli Pettay wrote:
On 07/04/2011 07:23 PM, John J. Barton wrote:
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model is
On 3/07/11 5:36 AM, Ryosuke Niwa wrote:
On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton
johnjbar...@johnjbarton.com wrote:
2) element transformation. The replacement fires after a mutation.
Library or tools that want to transform the application dynamically want
to get notification before the
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
Apologies in advance if my comment makes no sense. This is a long
thread, I tried to digest it all. :)
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu
On Mon, Jul 4, 2011 at 1:45 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/04/2011 08:16 PM, Adam Klein wrote:
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
The only bit that might be slower is what data you include
Since this thread was started, bug 13071 was filed against this spec
(the only open bug):
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13071
Any comments re the priority of this bug, in particular if it must be
addressed before publishing a new LCWD?
Hixie - would you please provide a
Hi Brad, Anne,
As I mentioned in [1], I think there is sufficient support for WebApps
to publish this spec as a FPWD and I will start a Call for Consensus to
more formally determine WebApps' level of support.
A WG may publish a FPWD without consensus on the _contents_ of the spec.
The
On Tue, 05 Jul 2011 16:30:26 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
Anne - please add some text re the consensus of the contents point and
then I'll start the CfC.
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
Now has The contents of this document do not
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13146
Summary: hola como estan
Product: WebAppsWG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#the
Well, my disagreement is not with its content; I think we should not move
forward with this spec at all.
I feel that the goals of this draft are either inconsistent with the basic
architecture of the web, cannot be meaningfully accomplished by the proposed
mechanism, or both, and I haven't
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13146
Anne ann...@opera.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hi Brad,
On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad bh...@paypal-inc.com wrote:
Well, my disagreement is not with its content; I think we should not move
forward with this spec at all.
I feel that the goals of this draft are either inconsistent with the basic
architecture of the web,
As discussed in [1], Anne would like to publish a First Public Working
Draft (FPWD) of Cross-Origin Resource Embedding Exclusion (From-Origin)
and this a Call for Consensus (CfC) to do so:
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
This CfC satisfies the group's
On Mon, Jul 4, 2011 at 2:22 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/05/2011 12:02 AM, Adam Klein wrote:
In Rafael's API, each mutation is represented by an object, so I'd
simply put it there with its own key, something like:
interface MutationRecord {
// e.g.,
On Wed, Jun 29, 2011 at 9:11 PM, Jonas Sicking jo...@sicking.cc wrote:
Heh. It's like spec people has to deal with the same complexities as
implementors has had for years. Revenge at last!!
:) Yeah, as specs get more detailed, writing them is kind of like
writing a mini-implementation. Except
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12234
Eliot Graff eliot...@microsoft.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9653
Eliot Graff eliot...@microsoft.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 06/30/2011 12:54 AM, Rafael Weinstein wrote:
On Wed, Jun 29, 2011 at 7:13 AM, Aryeh Gregorsimetrical+...@gmail.com
wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas
On 7/5/11 12:30 PM, Aryeh Gregor wrote:
Why not have a function like suspendMutationEvents() that just makes
the current JavaScript function a compound mutating function? That
is, when you call that function, all mutation events are suspended
until the function exits.
That's a pretty fuzzy
On 7/4/11 2:22 PM, Olli Pettay wrote:
Handling of insertedNodes/removedNodes becomes tricky if there are
several listeners and the first one of those adds or removes child
nodes. Should the listeners which will be called later get the same
insertedNodes/removedNodes as the first listener, or
On 7/5/11 3:00 PM, David Flanagan wrote:
Boris, you have hinted that making the DOM readonly would cause all
kinds of problems, such as: a mutation listener that attempted to set
certain global variables would throw an exception. I'm coming at this
from the perspective of DOM Core and haven't
FWIW I'm going to push for the Mozilla implementation to dispatch
only when an event is clearly terminated with a blank line (I filed
the bug). If EOF is encountered w/out a blank line it should be
considered an incomplete/corrupted event.
The fix for the spec would be to drop the line
Once
On 7/5/11 12:12 PM, Boris Zbarsky wrote:
On 7/5/11 3:00 PM, David Flanagan wrote:
Boris, you have hinted that making the DOM readonly would cause all
kinds of problems, such as: a mutation listener that attempted to set
certain global variables would throw an exception. I'm coming at this
from
On 7/5/11 3:45 PM, David Flanagan wrote:
I've assumed that mutation events are an advanced feature that will
mostly be used by sophisticated developers and library authors. But I
see your point. I was worried you were saying that there quirks to the
DOM itself that made a read-only mode
I am out of the office until 18/07/2011.
I will respond to your message when I return.
Note: This is an automated response to your message CfC: publish FPWD of
Cross-Origin Resource Embedding Exclusion; deadline July 12 sent on
05/07/2011 18:07:30.
This is the only notification you will
On Tue, Jul 5, 2011 at 2:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
That's a pretty fuzzy concept when
http://wiki.ecmascript.org/doku.php?id=harmony:generators are involved, say.
Yes, granted, there will be corner-cases. I don't know enough about
ES5 (let alone Harmony) to have an informed
On 7/5/11 4:25 PM, Aryeh Gregor wrote:
Maybe we don't want to give authors the ability to suspend mutation
events at all, though, sure.
Indeed.
It would also be a good way to deoptimize jits (e.g. you have to actually
_have_ the function around to detect when it exits, so if your jit does
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 06/30/2011 12:54 AM, Rafael Weinstein wrote:
On Wed, Jun 29, 2011 at 7:13 AM,
On Jul 5, 2011, at 8:57 , Marcos Caceres wrote:
Hi Brad,
On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad bh...@paypal-inc.com wrote:
Well, my disagreement is not with its content; I think we should not move
forward with this spec at all.
I feel that the goals of this draft are either
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 06/30/2011 12:54 AM, Rafael
On Mon, Jul 4, 2011 at 6:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/4/11 12:28 PM, Ojan Vafai wrote:
I'm not sure there really is a performance tradeoff. I believe that the
proposal Rafael put forward should almost always be faster. Storing the
list of changes and doing a JS callback
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
Apologies in advance if my comment makes no sense. This is a long
thread, I tried to digest it all. :)
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu
On 7/5/11 5:21 PM, Rafael Weinstein wrote:
For ChildlistChanged, the potential data to be included:
-Target node*
-Removed nodes*
-Added nodes
-one of nextSibling or previousSibling*
My belief is that including the starred (*) data above would be
sufficient to meet David's test of mirroring a
On Tue, Jul 5, 2011 at 2:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/5/11 5:21 PM, Rafael Weinstein wrote:
For ChildlistChanged, the potential data to be included:
-Target node*
-Removed nodes*
-Added nodes
-one of nextSibling or previousSibling*
My belief is that including the
On 07/06/2011 12:18 AM, Olli Pettay wrote:
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi
On Tue, Jul 5, 2011 at 2:29 PM, Rafael Weinstein rafa...@google.com wrote:
On Tue, Jul 5, 2011 at 2:27 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/5/11 5:21 PM, Rafael Weinstein wrote:
For ChildlistChanged, the potential data to be included:
-Target node*
-Removed nodes*
-Added nodes
On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/06/2011 12:18 AM, Olli Pettay wrote:
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 07/01/2011 02:17 AM, Rafael
On 07/06/2011 12:48 AM, Rafael Weinstein wrote:
On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 07/06/2011 12:18 AM, Olli Pettay wrote:
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi
On Mon, Jul 4, 2011 at 5:47 AM, Rich Tibbett ri...@opera.com wrote:
We currently define tests in test suites for SHOULD requirements. A problem
occurs when those tests are used to gauge the overall compliance of an
implementation to the full test suite. An implementation could theoretically
be
On Tue, Jul 5, 2011 at 3:24 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/06/2011 12:48 AM, Rafael Weinstein wrote:
On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettayolli.pet...@helsinki.fi**
wrote:
What is the reason to require a new mechanism for async handling? Could
listeners be
* Marcos Caceres wrote:
On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad bh...@paypal-inc.com wrote:
I feel that the goals of this draft are either inconsistent with the
basic architecture of the web, cannot be meaningfully accomplished
by the proposed mechanism, or both, and I haven't seen any
What do you think about NOT allowing IDBFactorySync.deleteDatabase and
IDBDatabaseSync.close to be called from within the transaction callback method
of IDBDatabaseSync.transaction or IDBDatabaseSync.setVersion? This will reduce
the number of possible deadlocks inside the transaction callback.
On Tue, Jul 5, 2011 at 3:55 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 3:24 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/06/2011 12:48 AM, Rafael Weinstein wrote:
On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettayolli.pet...@helsinki.fi
wrote:
What is the reason to
On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.com wrote:
It seems like these are rarified enough cases that visual artifacts
are acceptable collateral damage if you do this. [Put another way, if
you care enough about the visual polish of your app that you will put
energy
On Tue, Jul 5, 2011 at 4:41 PM, Israel Hilerio isra...@microsoft.com wrote:
What do you think about NOT allowing IDBFactorySync.deleteDatabase and
IDBDatabaseSync.close to be called from within the transaction callback
method of IDBDatabaseSync.transaction or IDBDatabaseSync.setVersion? This
On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.comwrote:
It seems like these are rarified enough cases that visual artifacts
are acceptable collateral damage if you do this. [Put another way, if
you care
On Tuesday, July 05, 2011 5:46 PM, Jonas Sicking wrote:
On Tue, Jul 5, 2011 at 4:41 PM, Israel Hilerio isra...@microsoft.com wrote:
What do you think about NOT allowing IDBFactorySync.deleteDatabase and
IDBDatabaseSync.close to be called from within the transaction callback
method of
To the procedural points:
I am not a member of the Web Applications WG. I do not have standing to block
or make a formal objection to this moving forward as a FPWD. Responsibility to
measure consensus and the decision to move forward within that WG rests with
Art.
The opinion of the
On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.comwrote:
It seems like these are rarified enough cases that visual artifacts
are
49 matches
Mail list logo
