Re: Mutation events replacement

2011-07-05 Thread Ryosuke Niwa
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 simple case. Then all
 three can be accommodated.


 If such a restriction were feasible, it might be worth looking into.  It
 would involve not passing any DOM nodes to the mutation listener, I suspect.


We'll also need to make window and other objects inaccessible from the
mutation listener.  Even then, the script may have a global reference to
some DOM node.  Frankly, I don't think such a restriction is feasible to
implement, and I don't want to discuss about pre-mutation events or observer
callbacks any more at this point.

Instead, let us focus on Jonas' proposal about replacing existing mutation
events by post-mutation observer callbacks.  So far, I've seen the following
complaints and suggestions about Jonas' proposals:

   - *Information is not complete* - Some apps want to know exactly what
   happened so that they can sync data, create an inverse operator, etc...
   - *Pseudo-sync/async is confusing* - In Joans' proposal, outer most
   mutation calls observers synchronously after the mutation took place whereas
   inner ones call observers asynchronously. This behavior might be confusing
   because the code that expects mutation observers be called synchronously
   works fine outside of observers but doesn't work inside observers.
   - *Call observer once with a list of mutations instead of calling
   observers for each mutation?*

Anything to add?  Does anyone have a revised proposal that addresses the
above points?

- Ryosuke


Re: Mutation events replacement

2011-07-05 Thread Olli Pettay

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 that if someone tries to do a mutation the mutation _will_
happen and will complete. _Then_ listeners, if any, will be notified.
What are you worried about working or failing?


According to Olli, some functions in mutation listeners will fail.

What? I don't understand this at all.

Sorry, it was actually in Jonas' post you quoted:


The only undesirable feature is that code that mutates the DOM from
inside a callback, say by calling setAttribute, can't rely on that by
the time that setAttribute returns, all callbacks have been notified.
This is unfortunately required if we want the second desirable
property listed above.



If I understand correctly, this description understates the problem.
Isn't it the case that all DOM mutations will act differently in
mutation listeners?

DOM mutations will not act differently, but mutation listeners
will be called later.


Code tested outside of mutation listeners can fail
inside of mutation listeners, correct?

If the code relies on mutation listeners, then yes.




This is indeed an undesirable feature and I don't believe it is
necessary. We can achieve the second desirable property, which is really
about avoiding mutation in mutation listeners, in other ways. Instead of
special case asynchrony, make it explicit asynchrony.
There are no real async operations, there is just the queue of mutation 
notifications. But sure, it can look like async.

But you propose that all the mutation notifications are done
asynchronously? One could easily add a small JS layer over the proposed
API to get fully async behavior.



Developers will
hate it, just like they hate XHR asynchrony,

(They do? Hmm, and I'll propose to deprecate sync XHR, since it is
bad for UX. But this topic has nothing to do with mutation events.)



-Olli


but it's better than
unreliable programs.


The

list of functions is not specified directly, but is implicit in the
algorithm: some function's actions become asynchronous.

No. Change notifications are queued, and the listeners handling the
queue will called at the time when the outermost DOM mutation is about
to return.

How can I reconcile your answer with the idea that setAttribute() does
not work synchronously in my mutation listener? Can my mutation listener
mutate the DOM and expect those mutations to act the way they do outside
of the listeners? My understanding is no: the API works differently
inside of mutation listeners.

jjb






Re: Mutation events replacement

2011-07-05 Thread Sean Hogan

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 mutation.

Why do you need to get notified before the mutation?  Again, this is
exactly the sort of usage that causes us headaches and what we want to
avoid because scripts can then modify DOM before we make mutations.


Another reason for notifying before mutation (only applies to 
DOMNodeRemoved):


Some javascript libraries such as reglib 
(http://code.google.com/p/reglib/) use event delegation and CSS 
selectors to apply behavior to elements in a document.


If these libs wanted to take actions when an element is removed from the 
document they would need notification to occur before the element is 
removed, as this would allow element.matchesSelector() or equivalent to 
be called. Being notified after removal would require more complex code.


This is a fairly weak use-case. In general, if you need to know that an 
element is removed from the document then you already responded to it 
being in the document, at which time you could attach a mutation 
listener on the element.


Sean




Re: Mutation events replacement

2011-07-05 Thread Adam Klein
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
 mailto:bzbar...@mit.edu wrote:

    That may be ok, if the use cases that incur this cost are rare and
    the common case can be better served by a different approach.

    Or put another way, if 1% of consumers want the full list because it
    makes them 4x faster and the other 99% don't want the full list, and
    the full list is 3x slower for the browser to build than just
    providing the information the 99% want, what's the right tradeoff?


 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 once, for nearly all use-cases,
 should be faster than frequent, semi-synchronous callbacks.

 The only bit that might be slower is what data you include in the
 mutation list. I believe that all the data you'd need is cheap except
 for possibly the following two:
 -The index of the child that changed for ChildListChanged (is this
 actually expensive?)

 You may need more than just an index. element.innerHTML = null removes
 all the child nodes.
 And element.inserBefore(some_document_fragment, element.lastChild)
 may insert several child nodes.
 Depending on whether we want to get notified for each mutation
 or batch the mutations, simple index may or may not be enough.

Would a node reference be better (nextSibling)?  Assuming the
listeners have access to all inserted/removed nodes along the way,
using another as an anchor seems like it would work properly (though
the innerHTML case may need something special).


 -The old value of an attribute/text node. I know this is expensive in
 Gecko's engine at least.

 Shouldn't be that slow.

 Mutation listener could easily
 implement old/new value handling itself, especially if it knows which
 attributes it is interested in.

This only works if listeners don't care about intermediate values,
since all they'll have access to is the last value they saw and the
current value in the DOM. If it was set several times during a single
mutation event (whether that be your or Rafael's definition of a
transaction), they'll miss those in-between values.  Also, while
this would be acceptable for some use cases, the editing/undo use case
would need to keep values of all attributes at all nodes, which seems
likely to be worse than having the UA take care of this.

 I'd be fine with excluding that information by default, but having a
 flag you pass at some point saying to include those. That way, only
 sites that need it take the performance hit.

Given that different use cases seem to have wildly different
requirements (some probably only care about one or two attributes
while others care about the entire document), this approach to
handling the availability of oldValue/newValue is appealing.

- Adam




Re: Mutation events replacement

2011-07-05 Thread Adam Klein
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 in the
 mutation list. I believe that all the data you'd need is cheap except
 for possibly the following two:
 -The index of the child that changed for ChildListChanged (is this
 actually expensive?)

 You may need more than just an index. element.innerHTML = null removes
 all the child nodes.
 And element.inserBefore(some_document_fragment, element.lastChild)
 may insert several child nodes.
 Depending on whether we want to get notified for each mutation
 or batch the mutations, simple index may or may not be enough.

 Would a node reference be better (nextSibling)?  Assuming the
 listeners have access to all inserted/removed nodes along the way,
 using another as an anchor seems like it would work properly (though
 the innerHTML case may need something special).

 Where would the node reference be?
 What would the API look like?

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., 'ChildListChanged', 'AttributeChanged'
  readonly attribute DOMString type;
  // element whose childNodes changed, or whose attribute was changed
  readonly attribute Node target;
  readonly attribute NodeListinsertedNodes;
  readonly attribute NodeListremovedNodes;
  // reference to the node before which the above nodes were removed/inserted
  readonly attribute Node nextSibling;
};

With your API, I think you'd want to change from passing nodes to the
callback to using something like the above, analogous to the
information hanging off of MutationEvent in the current spec.

- Adam




Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1

2011-07-05 Thread Arthur Barstow
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 rough estimate re when you can 
address this bug?


All - if anyone is willing to submit a fix for this bug, please send the 
fix to the list or add the fix to the bug.


-AB

On 6/24/11 7:33 AM, ext Arthur Barstow wrote:

Hixie, All,

Ian responded [1] to the last set of Server-Sent Events comments I had 
noted, and Bugzilla now reports Zarro Boogs [2] for this spec 
(11835/Fixed, 11836/WontFix, 12411/Fixed, 12883/WontFix).


As such, this raises the question if the spec is ready for Last Call 
Working Draft publication (see [3] for information about what it means 
for the spec to be LC ready). If you have any feedback on this 
question, please send it by July 1.


The latest Editor's Draft is:

  http://dev.w3.org/html5/eventsource/

-AB

[1] 
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1079.html
[2] 
http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=WebAppsWGcomponent=Server-Sent+Events+%28editor%3A+Ian+Hickson%29longdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailtype1=substringemail1=emailtype2=substringemail2=bug_id_type=anyexactbug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=
[3] 
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0695.html






Re: Publishing From-Origin Proposal as FPWD

2011-07-05 Thread Arthur Barstow

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 Status of the Document section may be explicit on this point. We try 
to employ a publish early, publish often to encourage early and 
frequent comments and I think a FPWD will help stimulate comments.


Anne - please add some text re the consensus of the contents point and 
then I'll start the CfC.


-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0012.html

On 7/1/11 1:52 PM, ext Hill, Brad wrote:

The new WebAppSec WG charter draft does include a deliverable for secure 
mashups built with cross-domain framing, with the specific intent to put 
forward a proposal for anti-clickjacking in this space.

However, I have concerns with nearly every aspect of this draft.

First, I am concerned about mixed goals in the problem statement.  It's definitely not in 
the proposed charter scope for the WebAppSec WG to address issues like bandwidth 
theft and license enforcement.   Even for the WebApps WG, it is arguable that 
some of these goals go against core Web Architecture principles. 
(http://www.w3.org/TR/webarch/)

Secondly, several of the goals, even if couched in terms of security, aren't in 
the interest of the user.  If I go to a page, I want to see images, fonts and 
videos on it.  Policies that prevent that from working are actually adversarial 
to the user.From a basic security principles perspective, the client-side 
UA is not the place for such restrictions to be enforced, as they can be easily 
disabled.Further, conflating mechanisms to protect the user 
(anti-clickjacking) with mechanisms adversarial to the user (font licensing) 
encourages the user to disable even the protections that they should want.

Finally, don't think the proposed mechanism here for user-protection is adequate for many/most use cases at 
risk of clickjacking that web application owners would like to deploy.  A binary frame/no-frame policy based 
on a whitelist of origins is both very limiting and not terribly secure.   Consider a like, 
+1 or pay button.  These may be framed on tens of thousands of origins, making a 
whitelist unmanageable.  Or they may be framed-by-permission on an origin with tens of thousands of 
resources/pages/applications (forum, auction site, etc.)  where an XSS or similar in any one of which would 
expose the framed content to clickjacking again.

I think it's preferable to work towards a mechanism where resources can declare 
they can be framed, but only subject to some policy or set of capabilities 
which guarantee clickjacking protection, visibility, etc.

Brad Hill

-Original Message-
From: public-web-security-requ...@w3.org 
[mailto:public-web-security-requ...@w3.org] On Behalf Of Anne van Kesteren
Sent: Thursday, June 30, 2011 7:23 AM
To: WebApps WG
Cc: public-web-secur...@w3.org
Subject: Publishing From-Origin Proposal as FPWD

Hi hi,

Is there anyone who has objections against publishing 
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD.
The idea is mainly to gather more feedback to see if there is any interest in 
taking this forward.

(Added public-web-security because of the potential for doing this in CSP 
instead. Though that would require a slight change of scope for CSP, which I'm 
not sure is actually desirable.)

Cheers,


--
Anne van Kesteren
http://annevankesteren.nl/





Re: Publishing From-Origin Proposal as FPWD

2011-07-05 Thread Anne van Kesteren
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 necessarily reflect the  
consensus of the Working Group. which I think is redundant with  
Publication as a Working Draft does not imply endorsement by the W3C  
Membership. but moving on is more interesting.




On 7/1/11 1:52 PM, ext Hill, Brad wrote:
The new WebAppSec WG charter draft does include a deliverable for  
secure mashups built with cross-domain framing, with the specific  
intent to put forward a proposal for anti-clickjacking in this space.


However, I have concerns with nearly every aspect of this draft.

First, I am concerned about mixed goals in the problem statement.  It's  
definitely not in the proposed charter scope for the WebAppSec WG to  
address issues like bandwidth theft and license enforcement.   Even  
for the WebApps WG, it is arguable that some of these goals go against  
core Web Architecture principles. (http://www.w3.org/TR/webarch/)


Secondly, several of the goals, even if couched in terms of security,  
aren't in the interest of the user.  If I go to a page, I want to see  
images, fonts and videos on it.  Policies that prevent that from  
working are actually adversarial to the user.From a basic security  
principles perspective, the client-side UA is not the place for such  
restrictions to be enforced, as they can be easily disabled. 
Further, conflating mechanisms to protect the user (anti-clickjacking)  
with mechanisms adversarial to the user (font licensing) encourages the  
user to disable even the protections that they should want.


Finally, don't think the proposed mechanism here for user-protection is  
adequate for many/most use cases at risk of clickjacking that web  
application owners would like to deploy.  A binary frame/no-frame  
policy based on a whitelist of origins is both very limiting and not  
terribly secure.   Consider a like, +1 or pay button.  These may  
be framed on tens of thousands of origins, making a whitelist  
unmanageable.  Or they may be framed-by-permission on an origin with  
tens of thousands of resources/pages/applications (forum, auction site,  
etc.)  where an XSS or similar in any one of which would expose the  
framed content to clickjacking again.


I think it's preferable to work towards a mechanism where resources can  
declare they can be framed, but only subject to some policy or set of  
capabilities which guarantee clickjacking protection, visibility, etc.


I agree we should look at this more, but I think having a published draft  
helps. The background of this work is actually not clickjacking, but  
specifically @font-face (web font embedding mechanism) where a default  
same-origin restriction is considered. This was drafted as an alternative,  
opt-out mechanism, though can potentially be used for a number of other  
things as well.



--
Anne van Kesteren
http://annevankesteren.nl/



[Bug 13146] New: hola como estan

2011-07-05 Thread bugzilla
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
-abstractworker-abstract-interface
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Workers (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification:
http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html
Multipage: http://www.whatwg.org/C#the-abstractworker-abstract-interface
Complete: http://www.whatwg.org/c#the-abstractworker-abstract-interface

Comment:
hola como estan

Posted from: 201.139.0.169
User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.30 (KHTML, like
Gecko) Chrome/12.0.742.100 Safari/534.30

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



RE: Publishing From-Origin Proposal as FPWD

2011-07-05 Thread Hill, Brad
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 seen any discussion of these concerns yet.   

-Brad

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Tuesday, July 05, 2011 7:30 AM
To: Hill, Brad; Anne van Kesteren
Cc: WebApps WG; public-web-secur...@w3.org; Daniel Veditz
Subject: Re: Publishing From-Origin Proposal as FPWD

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 Status of the Document section may be explicit on this point. We try to 
employ a publish early, publish often to encourage early and frequent 
comments and I think a FPWD will help stimulate comments.

Anne - please add some text re the consensus of the contents point and then 
I'll start the CfC.

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0012.html

On 7/1/11 1:52 PM, ext Hill, Brad wrote:
 The new WebAppSec WG charter draft does include a deliverable for secure 
 mashups built with cross-domain framing, with the specific intent to put 
 forward a proposal for anti-clickjacking in this space.

 However, I have concerns with nearly every aspect of this draft.

 First, I am concerned about mixed goals in the problem statement.  It's 
 definitely not in the proposed charter scope for the WebAppSec WG to address 
 issues like bandwidth theft and license enforcement.   Even for the WebApps 
 WG, it is arguable that some of these goals go against core Web Architecture 
 principles. (http://www.w3.org/TR/webarch/)

 Secondly, several of the goals, even if couched in terms of security, aren't 
 in the interest of the user.  If I go to a page, I want to see images, fonts 
 and videos on it.  Policies that prevent that from working are actually 
 adversarial to the user.From a basic security principles perspective, the 
 client-side UA is not the place for such restrictions to be enforced, as they 
 can be easily disabled.Further, conflating mechanisms to protect the user 
 (anti-clickjacking) with mechanisms adversarial to the user (font licensing) 
 encourages the user to disable even the protections that they should want.

 Finally, don't think the proposed mechanism here for user-protection is 
 adequate for many/most use cases at risk of clickjacking that web application 
 owners would like to deploy.  A binary frame/no-frame policy based on a 
 whitelist of origins is both very limiting and not terribly secure.   
 Consider a like, +1 or pay button.  These may be framed on tens of 
 thousands of origins, making a whitelist unmanageable.  Or they may be 
 framed-by-permission on an origin with tens of thousands of 
 resources/pages/applications (forum, auction site, etc.)  where an XSS or 
 similar in any one of which would expose the framed content to clickjacking 
 again.

 I think it's preferable to work towards a mechanism where resources can 
 declare they can be framed, but only subject to some policy or set of 
 capabilities which guarantee clickjacking protection, visibility, etc.

 Brad Hill

 -Original Message-
 From: public-web-security-requ...@w3.org 
 [mailto:public-web-security-requ...@w3.org] On Behalf Of Anne van 
 Kesteren
 Sent: Thursday, June 30, 2011 7:23 AM
 To: WebApps WG
 Cc: public-web-secur...@w3.org
 Subject: Publishing From-Origin Proposal as FPWD

 Hi hi,

 Is there anyone who has objections against publishing 
 http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD.
 The idea is mainly to gather more feedback to see if there is any interest in 
 taking this forward.

 (Added public-web-security because of the potential for doing this in 
 CSP instead. Though that would require a slight change of scope for 
 CSP, which I'm not sure is actually desirable.)

 Cheers,


 --
 Anne van Kesteren
 http://annevankesteren.nl/




[Bug 13146] hola como estan

2011-07-05 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13146

Anne ann...@opera.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@opera.com
 Resolution||INVALID

--- Comment #1 from Anne ann...@opera.com 2011-07-05 15:56:15 UTC ---
Noob.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



Re: Publishing From-Origin Proposal as FPWD

2011-07-05 Thread Marcos Caceres
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, cannot be meaningfully accomplished by the proposed 
 mechanism, or both, and I haven't seen any discussion of these concerns yet.


Publication will enable wider discussion - particularly wrt the issues
you have raised. Not publishing it is tantamount to saying I OBJECT
TO PROGRESS!. If you are correct, more people will see it and the
proposal will be shot down. Otherwise, other opinions will flourish
that may sway your position (or a new perspective will emerge all
together). In any case, calling for a spec not to be published, no
matter how bad it is, is not the right way to do this. Publishing a
spec is just a formality which can lead to discussion.

-- 
Marcos Caceres
http://datadriven.com.au



CfC: publish FPWD of Cross-Origin Resource Embedding Exclusion; deadline July 12

2011-07-05 Thread Arthur Barstow
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 requirement to record the group's  
decision to request advancement.


By publishing this FPWD, the group sends a signal to the community to  
begin reviewing the document. The FPWD reflects where the group is on 
this spec at the time of publication; it does _not_ necessarily mean 
there is consensus on the spec's contents.


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreement with the proposal. The deadline for 
comments is July 12. Please send all comments to:


public-webapps@w3.org

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1380.html





Re: Mutation events replacement

2011-07-05 Thread Ryosuke Niwa
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., 'ChildListChanged', 'AttributeChanged'
   readonly attribute DOMString type;
   // element whose childNodes changed, or whose attribute was changed
   readonly attribute Node target;
   readonly attribute NodeListinsertedNodes;
   readonly attribute NodeListremovedNodes;
   // reference to the node before which the above nodes were
 removed/inserted
   readonly attribute Node nextSibling;
 };


 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 should the lists be
 updated to reflect what has actually changed?


All remaining listeners should get the same list of MutationRecords but we
should add new MutationRecord to the list for the mutation made by the first
listener.

If the notification just tells that something has changed, it would be
 up to the JS side to implement the kind of list handling it wants.


So when the flag is off, we won't have insertedNodes, removedNodes, and
nextSibling but still have type and element, right?

- Ryosuke


Re: Mutation events replacement

2011-07-05 Thread Aryeh Gregor
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 spec authors get to use
pseudocode that skips over inconvenient details if they don't seem
important, and we don't have to care as much about performance.
Actually, the way I'm writing specs right now maps almost line-to-line
to a JS implementation I write in parallel.

 Jokes aside. I think the way to do this is that the spec should
 introduce the concept of a compound mutating function. Functions
 like insertBefore, removeChild and the innerHTML setter should claim
 to be such functions. Any other function can also be defined to be
 such a function, such as your execCommand function.

 Whenever a mutation happens, the notifications for it is put on a
 list. Once the outermost compound mutation function exits, all
 notifications are fired.

That makes sense.  It will look close to sync in some cases, but there
will be lots of common things that make it look closer to async
(parser insertions, innerHTML, etc.), so hopefully it won't be too
confusing for authors.

 The problem is that there is no good way to do this. The only API that
 we could expose to JS is something like a beginBatch/endBatch pair of
 functions. But what do we do if the author never calls endBatch?

 This is made especially bad by the fact that JavaScript uses
 exceptions which makes it very easy to miss calling endBatch if an
 exception is thrown unless the developer uses finally, which most
 don't.

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.  I don't know if it would be useful enough
to be worth creating, but it should work fine in principle, right?

 Maybe this is a stupid question, since I'm not familiar at all with
 the use-cases involved, but why can't we delay firing the
 notifications until the event loop spins? . . .

 To enable things like widget libraries which want to keep state
 up-to-date with a DOM.

I'm inferring from other posts in the thread that this is specifically
because they want to be able to respond to mutations before the
document is repainted or becomes responsive to user interaction.  Is
this right, or are there other reasons it can't be fully async?
Specifically, could we make a new pre-event loop that runs right
before the regular event loop, therefore before the page responds to
user input but after the currently running script has completed?  Or
would this be a problem because the page might be repainted before the
event loop spins, and we don't want the intermediate DOM to be
user-visible?  Are there other concerns?

If it turns out one of the constraints here is that we want mutation
events to finish before the page is repainted, we should explicitly
specify that UAs must not update the display of the page due to DOM
mutations between the time when a compound mutating function starts
running and when all corresponding mutation handlers have run, or
something like that.  That makes sense: we don't want the page to be
repainted halfway through an execCommand() execution anyway, for
instance.



[Bug 12234] [IndexedDB] Integrate with the HTML5 event loop

2011-07-05 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12234

Eliot Graff eliot...@microsoft.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Eliot Graff eliot...@microsoft.com 2011-07-05 16:59:16 
UTC ---
I fixed this with the checkin on 6/9 but forgot to resolve the bug. Sorry.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



[Bug 9653] How to handle nullable violations is not specified.

2011-07-05 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9653

Eliot Graff eliot...@microsoft.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||eliot...@microsoft.com
 Resolution||FIXED

--- Comment #3 from Eliot Graff eliot...@microsoft.com 2011-07-05 17:31:34 
UTC ---
From mail [1]:

]]
Based on this conversation, we agreed that we wanted to throw a TypeError when
a non-nullable parameter was passed a null argument.  This implies to me, for
example, that if we were to pass a null value for the key parameter of
IDBObjectStore.put we will throw a TypeError (i.e. InvalidArgument).  We're
assuming this Exception takes precedence over any IDB Exceptions (i.e.
DATA_ERR).
[[

I believe that this satisfies the request in this bug, so I am resolving it as
fixed.

[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0917.html

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



Re: Mutation events replacement

2011-07-05 Thread Olli Pettay

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 Sickingjo...@sicking.ccwrote:


This new proposal solves both these by making all the modifications
first, then firing all the events. Hence the implementation can
separate implementing the mutating function from the code that sends
out notifications.

Conceptually, you simply queue all notifications in a queue as you're
making modifications to the DOM, then right before returning from the
function you insert a call like flushAllPendingNotifications(). This
way you don't have to care at all about what happens when those
notifications fire.


So when exactly are these notifications going to be fired?  In
particular, I hope non-DOM Core specifications are going to have
precise control over when they're fired.  For instance, execCommand()
will ideally want to do all its mutations at once and only then fire
the notifications (which I'm told is how WebKit currently works).  How
will this work spec-wise?  Will we have hooks to say things like
remove a node but don't fire the notifications yet, and then have to
add an extra line someplace saying to fire all the notifications?
This could be awkward in some cases.  At least personally, I often say
things like call insertNode(foo) on the range in the middle of a
long algorithm, and I don't want magic happening at that point just
because DOM Range fires notifications before returning from
insertNode.

Also, even if specs have precise control, I take it the idea is
authors won't, right?  If a library wants to implement some fancy
feature and be compatible with users of the library firing these
notifications, they'd really want to be able to control when
notifications are fired, just like specs want to.  In practice, the
only reason this isn't an issue with DOM mutation events is because
they can say don't use them, and in fact people rarely do use them,
but that doesn't seem ideal -- it's just saying library authors
shouldn't bother to be robust.


In working on Model Driven Views (http://code.google.com/p/mdv), we've
run into exactly this problem, and have developed an approach we think
is promising.

The idea is to more or less take Jonas's proposal, but instead of
firing callbacks immediately before the outer-most mutation returns,
mutations are recorded for a given observer and handed to it as an
in-order sequence at the end of the event.


What is the advantage comparing to Jonas' proposal?


You guys did the conceptual heavy lifting WRT this problem. Jonas's
proposal solves the main problems with current mutation events: (1)
they fire too often, (2) they are expensive because of event
propagation, (3) they are crashy WRT some DOM operations.

If Jonas's proposal is the ultimate solution, I think it's a good
outcome and a big improvement over existing spec or tearing out
mutation events. I'm asking the group to consider a few changes which
I'm hoping are improvements.

I'll be happy if I fail =-).

---

My concern with Jonas's proposal is that its semantics depend on
context (inside vs. outside of a mutation notification). I feel like
this is at least a conceptual problem. That, and I kind of shudder
imagining trying to explain to a webdev why and when mutation
notifications are sync vs async.

The place it seems likely to fall down is when someone designs an
abstraction using mutation events and depends on them firing
synchronously -- then they or someone else attempt to use it inside
another abstraction which uses mutation events. How likely is that? I
don't even have a guess, but I'm pretty surprised at the crazy things
people did with current mutation events.

Our proposal's semantics aren't dependent on context.

Additionally, our proposal makes it clear that handling a mutation
notification is an exercise in dealing with an arbitrary number of
ways the DOM could have changed since you were last called. I.e.
providing the list of changes.

In short, I feel like our proposal is just a small tweak on Jonas's.
It is more direct in its form and API about the actually difficultly
of being a mutation observer.

Also, I'll just note a difference in view: We view it as fundamentally
a bad thing to have more than one actor operating at a time (where
actor == event handler, or abstraction which observes mutations). It
seems as though you guys view this as a good thing (i.e. All other
problems aside, mutation events *should* be synchronous).

The example I keep using internally is this: an app which uses

a) A constraint library which manages interactions between form values
(observes data mutations, makes data mutations)
b) A templating library (like MDV) which maps data to DOM (observes
both DOM and data mutations, makes both DOM and data mutations)
c) A widget library 

Re: Mutation events replacement

2011-07-05 Thread Boris Zbarsky

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 concept when 
http://wiki.ecmascript.org/doku.php?id=harmony:generators are involved, 
say.


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 inlining you have to turn that off or instrument it for 
functions that contain that call) without realizing it.



but it should work fine in principle, right?


maybe.  ;)


I'm inferring from other posts in the thread that this is specifically
because they want to be able to respond to mutations before the
document is repainted or becomes responsive to user interaction.  Is
this right, or are there other reasons it can't be fully async?
Specifically, could we make a new pre-event loop that runs right
before the regular event loop, therefore before the page responds to
user input but after the currently running script has completed?


The page can get repainted before the currently running script has 
completed: think sync XHR or alert() calls.  Note that the event loop 
will run in those cases too, in some UAs; not sure what the spec says 
about it right now (or even whether what the spec says is web-compatible).



If it turns out one of the constraints here is that we want mutation
events to finish before the page is repainted, we should explicitly
specify that UAs must not update the display of the page due to DOM
mutations between the time when a compound mutating function starts
running and when all corresponding mutation handlers have run, or
something like that.  That makes sense: we don't want the page to be
repainted halfway through an execCommand() execution anyway, for
instance.


So if halfway through the mutation listeners for an execCommand one of 
the listeners does a showModalDialog(), should the page the dialog comes 
from stop painting until that dialog is dismissed?


-Boris




Re: Mutation events replacement

2011-07-05 Thread David Flanagan

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 should the lists be
updated to reflect what has actually changed?
Questions like these are why I agree with jjb and think that it is a 
no-brainer that DOM modifications should be forbidden in mutation 
listeners.  Earlier in this thread, I proposed that the document tree 
should be put into read-only mode while mutation events are fired, and 
that any attempt to modify the tree from a mutation listener should 
throw NO_MODIFICATION_ALLOWED_ERR.  The exception code and the notion of 
readonly nodes are already defined (but unused, as far as I know) in DOM 
Level 2 Core.


I can't help pointing out one non-trivial benefit of forbidding 
mutations from mutation listeners:  it makes it impossible for 
developers to create inifinitely recursive mutations.


Boris wrote:


By restricting mutation listeners to explicitly avoid DOM mutation, the
most sophisticated case is no different than the simple case. Then all
three can be accommodated.


If such a restriction were feasible, it might be worth looking into.  
It would involve not passing any DOM nodes to the mutation listener, I 
suspect. 


I think this is worth looking into to figure out if it is feasible.

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 gotten into the details of 
HTML yet, so I don't understand what these problems are.  Could you 
provide more detail?


Note that this isn't a capability system: we don't have to prevent the 
listener from having any access to the DOM.  That wouldn't be possible 
and the listeners need read access to the document and its nodes.  We 
just need to make any modification attempts fail.


David




Re: Mutation events replacement

2011-07-05 Thread Boris Zbarsky

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 gotten into the details of
HTML yet, so I don't understand what these problems are. Could you
provide more detail?


The problem is that web developers don't have a firm grasp on what's 
part of the DOM and what's part of ECMAScript.  And libraries that hide 
underlying things don't help it any.


So in practice, a web developer looking at code that involves a set call 
has no way to tell whether it will work in a given web browser in a 
mutation listener if listeners disable DOM mutations.  A web developer 
looking at a function call has no way to tell either.


The only way to make it possible to tell without learning every inch of 
the specs is to not give any access to DOM objects at all from mutation 
listeners.  Then any code you write there will work.



Note that this isn't a capability system: we don't have to prevent the
listener from having any access to the DOM. That wouldn't be possible
and the listeners need read access to the document and its nodes. We
just need to make any modification attempts fail.


And I'm saying that this will lead to hard-to-diagnose bustage due to 
unintended DOM modifications that the caller doesn't even realize are 
DOM modifications.


-Boris




Re: [eventsource] Is Server-Sent Events ready for LC? ; deadline July 1

2011-07-05 Thread Daniel Veditz
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 the end of the file is reached, the user agent must
   dispatch the event one final time, as defined below.

For clarity something explicit could be added

   If the end of the file is reached while collecting
   data and before encountering a blank line the incomplete
   event must not be dispatched.

-Dan Veditz

On 7/5/11 5:49 AM, Arthur Barstow wrote:
 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 rough estimate re when you can
 address this bug?
 
 All - if anyone is willing to submit a fix for this bug, please send
 the fix to the list or add the fix to the bug.
 
 -AB
 
 On 6/24/11 7:33 AM, ext Arthur Barstow wrote:
 Hixie, All,

 Ian responded [1] to the last set of Server-Sent Events comments I
 had noted, and Bugzilla now reports Zarro Boogs [2] for this spec
 (11835/Fixed, 11836/WontFix, 12411/Fixed, 12883/WontFix).

 As such, this raises the question if the spec is ready for Last
 Call Working Draft publication (see [3] for information about what
 it means for the spec to be LC ready). If you have any feedback
 on this question, please send it by July 1.

 The latest Editor's Draft is:

   http://dev.w3.org/html5/eventsource/

 -AB

 [1]
 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1079.html

 [2]
 http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=WebAppsWGcomponent=Server-Sent+Events+%28editor%3A+Ian+Hickson%29longdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailtype1=substringemail1=emailtype2=substringemail2=bug_id_type=anyexactbug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=

 [3]
 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0695.html


 



Re: Mutation events replacement

2011-07-05 Thread David Flanagan

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 the perspective of DOM Core and haven't gotten into the details of
HTML yet, so I don't understand what these problems are. Could you
provide more detail?


The problem is that web developers don't have a firm grasp on what's 
part of the DOM and what's part of ECMAScript.  And libraries that 
hide underlying things don't help it any.


So in practice, a web developer looking at code that involves a set 
call has no way to tell whether it will work in a given web browser in 
a mutation listener if listeners disable DOM mutations.  A web 
developer looking at a function call has no way to tell either.
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 impractical.




The only way to make it possible to tell without learning every inch 
of the specs is to not give any access to DOM objects at all from 
mutation listeners.  Then any code you write there will work.
But that option is completely impossible, right? Not an avenue to 
investigate.



Note that this isn't a capability system: we don't have to prevent the
listener from having any access to the DOM. That wouldn't be possible
and the listeners need read access to the document and its nodes. We
just need to make any modification attempts fail.


And I'm saying that this will lead to hard-to-diagnose bustage due to 
unintended DOM modifications that the caller doesn't even realize are 
DOM modifications.


At least the bustage would fail fast with an exception.  We could define 
a new RECURSIVE_MUTATION_ERR exception code that would make it easy to 
diagnose the problem.


I have to agree with jjb: developers won't like a readonly DOM in 
mutation listeners, but the problems that it will cause are not as bad 
as those that arise when recursive mutations are allowed.


David


-Boris






Re: Mutation events replacement

2011-07-05 Thread Boris Zbarsky

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 impractical.


There may well be those too; I'd have to examine all the quirky DOM 
stuff really carefully to tell



The only way to make it possible to tell without learning every inch
of the specs is to not give any access to DOM objects at all from
mutation listeners. Then any code you write there will work.

But that option is completely impossible, right? Not an avenue to
investigate.


I don't think it's very _useful_, but it's quite _possible_.  You would 
have to register the source for the listeners and they would need to be 
compiled and run in some sort of sandbox, etc.



I have to agree with jjb: developers won't like a readonly DOM in
mutation listeners, but the problems that it will cause are not as bad
as those that arise when recursive mutations are allowed.


And they seem just as bad to me _plus_ require a lot more work on the 
part of the UA and spec authors (e.g. specs would need to define the 
exact set of modifications and actions that are not allowed).


-Boris



AUTO: Alain Vagner is out of the office. (returning 18/07/2011)

2011-07-05 Thread alain . vagner

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 receive while this person is away.




Re: Mutation events replacement

2011-07-05 Thread Aryeh Gregor
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 opinion on how much effort
it would be to address the corner-cases.  But *if* authors would be
given the ability to suspend mutation events, in the model Jonas
proposed, something like I described seems like the way to do it.
Explicit suspend/restore calls are clearly much worse -- they fail
even in the regular case if the author forgets the restore call.
Maybe we don't want to give authors the ability to suspend mutation
events at all, though, sure.

 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
 inlining you have to turn that off or instrument it for functions that
 contain that call) without realizing it.

You'd have to add some extra instructions at every exit point of the
function when you inline it, yes.  You'd have to do the same if you
don't inline it, too.  This doesn't seem prohibitive by itself,
particularly given that functions where you'd use this will be doing
multiple DOM modifications.

 The page can get repainted before the currently running script has
 completed: think sync XHR or alert() calls.  Note that the event loop will
 run in those cases too, in some UAs; not sure what the spec says about it
 right now (or even whether what the spec says is web-compatible).

As far as I can see, the page can get repainted (meaning visually
updated in response to DOM changes, not sure if my terminology is
correct) in most browsers even when regular old scripts are running.
When I write tests in JavaScript that do many seconds of DOM
manipulation and add results to a table as they go, IE/Firefox/Opera
all visibly start displaying results long before the tests are done
running.  But they probably don't want to do this in the middle of
execCommand() execution, when the DOM is in some transient state that
will display oddly for a moment and then flicker away.

 So if halfway through the mutation listeners for an execCommand one of the
 listeners does a showModalDialog(), should the page the dialog comes from
 stop painting until that dialog is dismissed?

I wouldn't say so, no.  HTML5 seems to say that things like that
should cause the UA to pause, and the definition of that includes
updating the rendering:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#pause

I'm not familiar enough with the specs or implementations on this
issue to answer tricky questions, though.  I'm following along because
this is relevant to some specs I edit, but I'm not going to be
involved in speccing the new mutation listener system itself.



Re: Mutation events replacement

2011-07-05 Thread Boris Zbarsky

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
inlining you have to turn that off or instrument it for functions that
contain that call) without realizing it.


You'd have to add some extra instructions at every exit point of the
function when you inline it, yes.  You'd have to do the same if you
don't inline it, too.


Not necessarily; in the non-inlining case, removing the stack frame can 
just automatically do the work.


Unless you tail-recurse, in which case you don't remove the stackframe, 
of course



This doesn't seem prohibitive by itself, particularly given that functions 
where you'd use this will be doing
multiple DOM modifications.


Maybe.  Maybe not.


As far as I can see, the page can get repainted (meaning visually
updated in response to DOM changes, not sure if my terminology is
correct) in most browsers even when regular old scripts are running.
When I write tests in JavaScript that do many seconds of DOM
manipulation and add results to a table as they go, IE/Firefox/Opera
all visibly start displaying results long before the tests are done
running.


Unless your tests are explicitly yielding via setTimeout, that's quite 
odd in at least the Firefox case.



But they probably don't want to do this in the middle of
execCommand() execution, when the DOM is in some transient state that
will display oddly for a moment and then flicker away.


It's not a moment if something happens in the middle of the 
execCommand that takes a while to complete and hits the network in the 
process.


The goal would be to not have such things happening in the middle of 
execCommand.



So if halfway through the mutation listeners for an execCommand one of the
listeners does a showModalDialog(), should the page the dialog comes from
stop painting until that dialog is dismissed?


I wouldn't say so, no.  HTML5 seems to say that things like that
should cause the UA to pause, and the definition of that includes
updating the rendering:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#pause


OK, that much I agree on.  But then I can't tell what you're proposing.

-Boris



Re: Mutation events replacement

2011-07-05 Thread Rafael Weinstein
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, Aryeh Gregorsimetrical+...@gmail.com
  wrote:

 On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sickingjo...@sicking.cc
  wrote:

 This new proposal solves both these by making all the modifications
 first, then firing all the events. Hence the implementation can
 separate implementing the mutating function from the code that sends
 out notifications.

 Conceptually, you simply queue all notifications in a queue as you're
 making modifications to the DOM, then right before returning from the
 function you insert a call like flushAllPendingNotifications(). This
 way you don't have to care at all about what happens when those
 notifications fire.

 So when exactly are these notifications going to be fired?  In
 particular, I hope non-DOM Core specifications are going to have
 precise control over when they're fired.  For instance, execCommand()
 will ideally want to do all its mutations at once and only then fire
 the notifications (which I'm told is how WebKit currently works).  How
 will this work spec-wise?  Will we have hooks to say things like
 remove a node but don't fire the notifications yet, and then have to
 add an extra line someplace saying to fire all the notifications?
 This could be awkward in some cases.  At least personally, I often say
 things like call insertNode(foo) on the range in the middle of a
 long algorithm, and I don't want magic happening at that point just
 because DOM Range fires notifications before returning from
 insertNode.

 Also, even if specs have precise control, I take it the idea is
 authors won't, right?  If a library wants to implement some fancy
 feature and be compatible with users of the library firing these
 notifications, they'd really want to be able to control when
 notifications are fired, just like specs want to.  In practice, the
 only reason this isn't an issue with DOM mutation events is because
 they can say don't use them, and in fact people rarely do use them,
 but that doesn't seem ideal -- it's just saying library authors
 shouldn't bother to be robust.

 In working on Model Driven Views (http://code.google.com/p/mdv), we've
 run into exactly this problem, and have developed an approach we think
 is promising.

 The idea is to more or less take Jonas's proposal, but instead of
 firing callbacks immediately before the outer-most mutation returns,
 mutations are recorded for a given observer and handed to it as an
 in-order sequence at the end of the event.

 What is the advantage comparing to Jonas' proposal?

 You guys did the conceptual heavy lifting WRT this problem. Jonas's
 proposal solves the main problems with current mutation events: (1)
 they fire too often, (2) they are expensive because of event
 propagation, (3) they are crashy WRT some DOM operations.

 If Jonas's proposal is the ultimate solution, I think it's a good
 outcome and a big improvement over existing spec or tearing out
 mutation events. I'm asking the group to consider a few changes which
 I'm hoping are improvements.

 I'll be happy if I fail =-).

 ---

 My concern with Jonas's proposal is that its semantics depend on
 context (inside vs. outside of a mutation notification). I feel like
 this is at least a conceptual problem. That, and I kind of shudder
 imagining trying to explain to a webdev why and when mutation
 notifications are sync vs async.

 The place it seems likely to fall down is when someone designs an
 abstraction using mutation events and depends on them firing
 synchronously -- then they or someone else attempt to use it inside
 another abstraction which uses mutation events. How likely is that? I
 don't even have a guess, but I'm pretty surprised at the crazy things
 people did with current mutation events.

 Our proposal's semantics aren't dependent on context.

 Additionally, our proposal makes it clear that handling a mutation
 notification is an exercise in dealing with an arbitrary number of
 ways the DOM could have changed since you were last called. I.e.
 providing the list of changes.

 In short, I feel like our proposal is just a small tweak on Jonas's.
 It is more direct in its form and API about the actually difficultly
 of being a mutation observer.

 Also, I'll just note a difference in view: We view it as fundamentally
 a bad thing to have more than one actor operating at a time (where
 actor == event handler, or abstraction which observes mutations). It
 seems as though you guys view this as a good thing (i.e. All other
 problems aside, mutation events *should* be synchronous).

 The example I keep using internally is this: an app which uses

 a) A constraint library which manages interactions between form values
 (observes data mutations, makes data 

Re: Publishing From-Origin Proposal as FPWD

2011-07-05 Thread David Singer

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 inconsistent with the basic 
 architecture of the web, cannot be meaningfully accomplished by the proposed 
 mechanism, or both, and I haven't seen any discussion of these concerns yet.
 
 
 Publication will enable wider discussion - particularly wrt the issues
 you have raised. Not publishing it is tantamount to saying I OBJECT
 TO PROGRESS!. If you are correct, more people will see it and the
 proposal will be shot down. Otherwise, other opinions will flourish
 that may sway your position (or a new perspective will emerge all
 together). In any case, calling for a spec not to be published, no
 matter how bad it is, is not the right way to do this. Publishing a
 spec is just a formality which can lead to discussion.
 

I guess this raises two questions...

a) I would obviously like to hear more about Marcos's objections, and I suppose 
that I will

b) probably not in this forum, I'd be curious to know what the valid reasons 
might be to objecting to publication at all, if I don't think this spec. 
should exist is not one of them. If there are no valid grounds for objection, 
we wouldn't bother asking for consensus.  Personally, I think publishing a WD 
indicates some consent that work in a given area should be considered and is 
relevant.

David Singer
Multimedia and Software Standards, Apple Inc.




Re: Mutation events replacement

2011-07-05 Thread Olli Pettay

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 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 Sickingjo...@sicking.cc
  wrote:


This new proposal solves both these by making all the modifications
first, then firing all the events. Hence the implementation can
separate implementing the mutating function from the code that sends
out notifications.

Conceptually, you simply queue all notifications in a queue as you're
making modifications to the DOM, then right before returning from the
function you insert a call like flushAllPendingNotifications(). This
way you don't have to care at all about what happens when those
notifications fire.


So when exactly are these notifications going to be fired?  In
particular, I hope non-DOM Core specifications are going to have
precise control over when they're fired.  For instance, execCommand()
will ideally want to do all its mutations at once and only then fire
the notifications (which I'm told is how WebKit currently works).  How
will this work spec-wise?  Will we have hooks to say things like
remove a node but don't fire the notifications yet, and then have to
add an extra line someplace saying to fire all the notifications?
This could be awkward in some cases.  At least personally, I often say
things like call insertNode(foo) on the range in the middle of a
long algorithm, and I don't want magic happening at that point just
because DOM Range fires notifications before returning from
insertNode.

Also, even if specs have precise control, I take it the idea is
authors won't, right?  If a library wants to implement some fancy
feature and be compatible with users of the library firing these
notifications, they'd really want to be able to control when
notifications are fired, just like specs want to.  In practice, the
only reason this isn't an issue with DOM mutation events is because
they can say don't use them, and in fact people rarely do use them,
but that doesn't seem ideal -- it's just saying library authors
shouldn't bother to be robust.


In working on Model Driven Views (http://code.google.com/p/mdv), we've
run into exactly this problem, and have developed an approach we think
is promising.

The idea is to more or less take Jonas's proposal, but instead of
firing callbacks immediately before the outer-most mutation returns,
mutations are recorded for a given observer and handed to it as an
in-order sequence at the end of the event.


What is the advantage comparing to Jonas' proposal?


You guys did the conceptual heavy lifting WRT this problem. Jonas's
proposal solves the main problems with current mutation events: (1)
they fire too often, (2) they are expensive because of event
propagation, (3) they are crashy WRT some DOM operations.

If Jonas's proposal is the ultimate solution, I think it's a good
outcome and a big improvement over existing spec or tearing out
mutation events. I'm asking the group to consider a few changes which
I'm hoping are improvements.

I'll be happy if I fail =-).

---

My concern with Jonas's proposal is that its semantics depend on
context (inside vs. outside of a mutation notification). I feel like
this is at least a conceptual problem. That, and I kind of shudder
imagining trying to explain to a webdev why and when mutation
notifications are sync vs async.

The place it seems likely to fall down is when someone designs an
abstraction using mutation events and depends on them firing
synchronously -- then they or someone else attempt to use it inside
another abstraction which uses mutation events. How likely is that? I
don't even have a guess, but I'm pretty surprised at the crazy things
people did with current mutation events.

Our proposal's semantics aren't dependent on context.

Additionally, our proposal makes it clear that handling a mutation
notification is an exercise in dealing with an arbitrary number of
ways the DOM could have changed since you were last called. I.e.
providing the list of changes.

In short, I feel like our proposal is just a small tweak on Jonas's.
It is more direct in its form and API about the actually difficultly
of being a mutation observer.

Also, I'll just note a difference in view: We view it as fundamentally
a bad thing to have more than one actor operating at a time (where
actor == event handler, or abstraction which observes mutations). It
seems as though you guys view this as a good thing (i.e. All other
problems aside, mutation events *should* be synchronous).

The example I keep using internally is this: an app which uses

a) A constraint library which manages interactions between form values
(observes data mutations, makes data mutations)
b) A templating 

Re: Mutation events replacement

2011-07-05 Thread Rafael Weinstein
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 once, for nearly all use-cases,
 should be faster than frequent, semi-synchronous callbacks.

 That depends on whether your list of changes gets big enough that your start
 swapping, for example.

Just to be clear here (since there's been some discussion of a flag
which would cause fine-grain notifications) -- I don't believe
there's any need to describe *more* mutations. I.e. My proposal is
*not* to record more than one mutation record for a call to innerHTML
which affects more than one element. That case would still be a single
'ChildlistChanged' mutation. This is a key part of Jonas's proposal
that we want to keep: It is (I think) optimally succinct, while still
containing (nearly -- see below) all the bits of information that you
need.

I.e. The set of mutation records during any given event should be more
or less on the order of the number of DOM *operations* -- not affected
nodes. Also note that it seems like the multiple observers can share
the same mutation record (just like multiple event listeners share the
same event object).

The question is how much data is contained in the mutation record.
Here's my sense:

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 tree *without* a ton of
processing or O(N) memory.

If people think it's worth while seeing example js code that
implements this properly and it'll convince the group that this data
is sufficient, I'll sign up for implementing it.


 The only bit that might be slower is what data you include in the
 mutation list.

 That's one of the things that could get slower, yes.  It's not the only one.

 -The index of the child that changed for ChildListChanged (is this
 actually expensive?)

 It could be.  In Gecko's case it's cheap right now because kids are stored
 in arrays, but WebKit uses doubly linked lists with a cache of some sort for
 indices last I checked.  So for some access patterns this could be pretty
 expensive in WebKit.

 -The old value of an attribute/text node. I know this is expensive in
 Gecko's engine at least.

 This can be expensive in all engines, if they do it right.  Consider having
 to serialize out values of the 'style' attribute (possibly twice) on every
 .style.foo set.  Or having to serialize out path attributes as the SVG DOM
 is mutating paths.  This is not a Gecko-specific issue.

 I'd be fine with excluding that information by default, but having a
 flag you pass at some point saying to include those. That way, only
 sites that need it take the performance hit.

 This would be a lot more palatable to me, yes.  This brings us back to
 having ways to ask for different levels of detail in mutation notifications.

 -Boris





Re: Mutation events replacement

2011-07-05 Thread Rafael Weinstein
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
 mailto:bzbar...@mit.edu wrote:

    That may be ok, if the use cases that incur this cost are rare and
    the common case can be better served by a different approach.

    Or put another way, if 1% of consumers want the full list because it
    makes them 4x faster and the other 99% don't want the full list, and
    the full list is 3x slower for the browser to build than just
    providing the information the 99% want, what's the right tradeoff?


 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 once, for nearly all use-cases,
 should be faster than frequent, semi-synchronous callbacks.

 The only bit that might be slower is what data you include in the
 mutation list. I believe that all the data you'd need is cheap except
 for possibly the following two:
 -The index of the child that changed for ChildListChanged (is this
 actually expensive?)

 You may need more than just an index. element.innerHTML = null removes
 all the child nodes.
 And element.inserBefore(some_document_fragment, element.lastChild)
 may insert several child nodes.
 Depending on whether we want to get notified for each mutation
 or batch the mutations, simple index may or may not be enough.

I think both of these can be a single ChildlistChanged mutation (not
a batch of mutations).



 -The old value of an attribute/text node. I know this is expensive in
 Gecko's engine at least.

 Shouldn't be that slow.

 Mutation listener could easily
 implement old/new value handling itself, especially if it knows which
 attributes it is interested in.




 I'd be fine with excluding that information by default, but having a
 flag you pass at some point saying to include those. That way, only
 sites that need it take the performance hit.

    The numbers above are made up, of course; it would be useful to have
    some hard data on the actual use cases.

    Maybe we need both sorts of APIs: one which generates a fine-grained
    change list and incurs a noticeable DOM mutation performance hit and
    one which batches changes more but doesn't slow the browser down as
    much...

    -Boris








Re: Mutation events replacement

2011-07-05 Thread Boris Zbarsky

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 tree *without* a ton of
processing or O(N) memory.


How is that not O(N) memory?

-Boris



Re: Mutation events replacement

2011-07-05 Thread Rafael Weinstein
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 starred (*) data above would be
 sufficient to meet David's test of mirroring a tree *without* a ton of
 processing or O(N) memory.

 How is that not O(N) memory?

Sorry - that was imprecise. What I meant was: the application script
wouldn't need to maintain more or less it's own copy of the DOM to
know for certain whether a node has effectively been added, removed,
or moved elsewhere in the document.


 -Boris




Re: Mutation events replacement

2011-07-05 Thread Olli Pettay

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
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 Sickingjo...@sicking.cc
wrote:


This new proposal solves both these by making all the modifications
first, then firing all the events. Hence the implementation can
separate implementing the mutating function from the code that
sends
out notifications.

Conceptually, you simply queue all notifications in a queue as
you're
making modifications to the DOM, then right before returning
from the
function you insert a call like
flushAllPendingNotifications(). This
way you don't have to care at all about what happens when those
notifications fire.


So when exactly are these notifications going to be fired? In
particular, I hope non-DOM Core specifications are going to have
precise control over when they're fired. For instance, execCommand()
will ideally want to do all its mutations at once and only then fire
the notifications (which I'm told is how WebKit currently works).
How
will this work spec-wise? Will we have hooks to say things like
remove a node but don't fire the notifications yet, and then
have to
add an extra line someplace saying to fire all the notifications?
This could be awkward in some cases. At least personally, I often
say
things like call insertNode(foo) on the range in the middle of a
long algorithm, and I don't want magic happening at that point just
because DOM Range fires notifications before returning from
insertNode.

Also, even if specs have precise control, I take it the idea is
authors won't, right? If a library wants to implement some fancy
feature and be compatible with users of the library firing these
notifications, they'd really want to be able to control when
notifications are fired, just like specs want to. In practice, the
only reason this isn't an issue with DOM mutation events is because
they can say don't use them, and in fact people rarely do use
them,
but that doesn't seem ideal -- it's just saying library authors
shouldn't bother to be robust.


In working on Model Driven Views (http://code.google.com/p/mdv),
we've
run into exactly this problem, and have developed an approach we
think
is promising.

The idea is to more or less take Jonas's proposal, but instead of
firing callbacks immediately before the outer-most mutation returns,
mutations are recorded for a given observer and handed to it as an
in-order sequence at the end of the event.


What is the advantage comparing to Jonas' proposal?


You guys did the conceptual heavy lifting WRT this problem. Jonas's
proposal solves the main problems with current mutation events: (1)
they fire too often, (2) they are expensive because of event
propagation, (3) they are crashy WRT some DOM operations.

If Jonas's proposal is the ultimate solution, I think it's a good
outcome and a big improvement over existing spec or tearing out
mutation events. I'm asking the group to consider a few changes which
I'm hoping are improvements.

I'll be happy if I fail =-).

---

My concern with Jonas's proposal is that its semantics depend on
context (inside vs. outside of a mutation notification). I feel like
this is at least a conceptual problem. That, and I kind of shudder
imagining trying to explain to a webdev why and when mutation
notifications are sync vs async.

The place it seems likely to fall down is when someone designs an
abstraction using mutation events and depends on them firing
synchronously -- then they or someone else attempt to use it inside
another abstraction which uses mutation events. How likely is that? I
don't even have a guess, but I'm pretty surprised at the crazy things
people did with current mutation events.

Our proposal's semantics aren't dependent on context.

Additionally, our proposal makes it clear that handling a mutation
notification is an exercise in dealing with an arbitrary number of
ways the DOM could have changed since you were last called. I.e.
providing the list of changes.

In short, I feel like our proposal is just a small tweak on Jonas's.
It is more direct in its form and API about the actually difficultly
of being a mutation observer.

Also, I'll just note a difference in view: We view it as fundamentally
a bad thing to have more than one actor operating at a time (where
actor == event handler, or abstraction which observes mutations). It
seems as though you guys view this as a good thing (i.e. All other
problems aside, mutation events *should* be synchronous).

The example I keep using internally is this: an app which uses

a) A constraint library which manages interactions between form values
(observes data mutations, makes 

Re: Mutation events replacement

2011-07-05 Thread Rafael Weinstein
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
 -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 tree *without* a ton of
 processing or O(N) memory.

Doh! Sorry. Just to note: if you omit Added Nodes, I think you'd need
AddedNodeCount.

Generally speaking, to avoid application script needing to make copies
of wholesale DOM structures, it needs to be given the old data and
the shape of the new data

E.g.:
For ChildlistChanged: removedNodes + addedNodeCount  next/previousSibling.
For AttributeChanged: added/removed/updated + oldValue
For TextChanged: oldValue.

This may be an unreasonable burden for UA's to deliver all the time.
If so, a give me old data flag seems worth considering.

Many use-cases will be aiming to minimize expensive work (typically
creating more DOM or writing to the wire) -- and it'll be tempting to
guarantee that work *has* to be done. Lacking old data, the
application will need to preemptively make a copy of all data that
*could* change.


 How is that not O(N) memory?

 Sorry - that was imprecise. What I meant was: the application script
 wouldn't need to maintain more or less it's own copy of the DOM to
 know for certain whether a node has effectively been added, removed,
 or moved elsewhere in the document.


 -Boris





Re: Mutation events replacement

2011-07-05 Thread Rafael Weinstein
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 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 Sickingjo...@sicking.cc
 wrote:

 This new proposal solves both these by making all the modifications
 first, then firing all the events. Hence the implementation can
 separate implementing the mutating function from the code that
 sends
 out notifications.

 Conceptually, you simply queue all notifications in a queue as
 you're
 making modifications to the DOM, then right before returning
 from the
 function you insert a call like
 flushAllPendingNotifications(). This
 way you don't have to care at all about what happens when those
 notifications fire.

 So when exactly are these notifications going to be fired? In
 particular, I hope non-DOM Core specifications are going to have
 precise control over when they're fired. For instance, execCommand()
 will ideally want to do all its mutations at once and only then fire
 the notifications (which I'm told is how WebKit currently works).
 How
 will this work spec-wise? Will we have hooks to say things like
 remove a node but don't fire the notifications yet, and then
 have to
 add an extra line someplace saying to fire all the notifications?
 This could be awkward in some cases. At least personally, I often
 say
 things like call insertNode(foo) on the range in the middle of a
 long algorithm, and I don't want magic happening at that point just
 because DOM Range fires notifications before returning from
 insertNode.

 Also, even if specs have precise control, I take it the idea is
 authors won't, right? If a library wants to implement some fancy
 feature and be compatible with users of the library firing these
 notifications, they'd really want to be able to control when
 notifications are fired, just like specs want to. In practice, the
 only reason this isn't an issue with DOM mutation events is because
 they can say don't use them, and in fact people rarely do use
 them,
 but that doesn't seem ideal -- it's just saying library authors
 shouldn't bother to be robust.

 In working on Model Driven Views (http://code.google.com/p/mdv),
 we've
 run into exactly this problem, and have developed an approach we
 think
 is promising.

 The idea is to more or less take Jonas's proposal, but instead of
 firing callbacks immediately before the outer-most mutation returns,
 mutations are recorded for a given observer and handed to it as an
 in-order sequence at the end of the event.

 What is the advantage comparing to Jonas' proposal?

 You guys did the conceptual heavy lifting WRT this problem. Jonas's
 proposal solves the main problems with current mutation events: (1)
 they fire too often, (2) they are expensive because of event
 propagation, (3) they are crashy WRT some DOM operations.

 If Jonas's proposal is the ultimate solution, I think it's a good
 outcome and a big improvement over existing spec or tearing out
 mutation events. I'm asking the group to consider a few changes which
 I'm hoping are improvements.

 I'll be happy if I fail =-).

 ---

 My concern with Jonas's proposal is that its semantics depend on
 context (inside vs. outside of a mutation notification). I feel like
 this is at least a conceptual problem. That, and I kind of shudder
 imagining trying to explain to a webdev why and when mutation
 notifications are sync vs async.

 The place it seems likely to fall down is when someone designs an
 abstraction using mutation events and depends on them firing
 synchronously -- then they or someone else attempt to use it inside
 another abstraction which uses mutation events. How likely is that? I
 don't even have a guess, but I'm pretty surprised at the crazy things
 people did with current mutation events.

 Our proposal's semantics aren't dependent on context.

 Additionally, our proposal makes it clear that handling a mutation
 notification is an exercise in dealing with an arbitrary number of
 ways the DOM could have changed since you were last called. I.e.
 providing the list of changes.

 In short, I feel like our proposal is just a small tweak on Jonas's.
 It is more direct in its form and API about the actually difficultly
 of being a mutation observer.

 Also, I'll just note a difference in view: We view it as fundamentally
 a bad thing to have more than one actor operating at a time (where
 actor == event handler, or abstraction which observes mutations). It
 seems as though you guys view this as a good thing (i.e. All other
 problems aside, mutation events *should* be synchronous).

 The 

Re: Mutation events replacement

2011-07-05 Thread Olli Pettay

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
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, Aryeh
Gregorsimetrical+...@gmail.com
wrote:


On Tue, Jun 28, 2011 at 5:24 PM, Jonas Sickingjo...@sicking.cc
wrote:


This new proposal solves both these by making all the modifications
first, then firing all the events. Hence the implementation can
separate implementing the mutating function from the code that
sends
out notifications.

Conceptually, you simply queue all notifications in a queue as
you're
making modifications to the DOM, then right before returning
from the
function you insert a call like
flushAllPendingNotifications(). This
way you don't have to care at all about what happens when those
notifications fire.


So when exactly are these notifications going to be fired? In
particular, I hope non-DOM Core specifications are going to have
precise control over when they're fired. For instance, execCommand()
will ideally want to do all its mutations at once and only then fire
the notifications (which I'm told is how WebKit currently works).
How
will this work spec-wise? Will we have hooks to say things like
remove a node but don't fire the notifications yet, and then
have to
add an extra line someplace saying to fire all the notifications?
This could be awkward in some cases. At least personally, I often
say
things like call insertNode(foo) on the range in the middle of a
long algorithm, and I don't want magic happening at that point just
because DOM Range fires notifications before returning from
insertNode.

Also, even if specs have precise control, I take it the idea is
authors won't, right? If a library wants to implement some fancy
feature and be compatible with users of the library firing these
notifications, they'd really want to be able to control when
notifications are fired, just like specs want to. In practice, the
only reason this isn't an issue with DOM mutation events is because
they can say don't use them, and in fact people rarely do use
them,
but that doesn't seem ideal -- it's just saying library authors
shouldn't bother to be robust.


In working on Model Driven Views (http://code.google.com/p/mdv),
we've
run into exactly this problem, and have developed an approach we
think
is promising.

The idea is to more or less take Jonas's proposal, but instead of
firing callbacks immediately before the outer-most mutation returns,
mutations are recorded for a given observer and handed to it as an
in-order sequence at the end of the event.


What is the advantage comparing to Jonas' proposal?


You guys did the conceptual heavy lifting WRT this problem. Jonas's
proposal solves the main problems with current mutation events: (1)
they fire too often, (2) they are expensive because of event
propagation, (3) they are crashy WRT some DOM operations.

If Jonas's proposal is the ultimate solution, I think it's a good
outcome and a big improvement over existing spec or tearing out
mutation events. I'm asking the group to consider a few changes which
I'm hoping are improvements.

I'll be happy if I fail =-).

---

My concern with Jonas's proposal is that its semantics depend on
context (inside vs. outside of a mutation notification). I feel like
this is at least a conceptual problem. That, and I kind of shudder
imagining trying to explain to a webdev why and when mutation
notifications are sync vs async.

The place it seems likely to fall down is when someone designs an
abstraction using mutation events and depends on them firing
synchronously -- then they or someone else attempt to use it inside
another abstraction which uses mutation events. How likely is that? I
don't even have a guess, but I'm pretty surprised at the crazy things
people did with current mutation events.

Our proposal's semantics aren't dependent on context.

Additionally, our proposal makes it clear that handling a mutation
notification is an exercise in dealing with an arbitrary number of
ways the DOM could have changed since you were last called. I.e.
providing the list of changes.

In short, I feel like our proposal is just a small tweak on Jonas's.
It is more direct in its form and API about the actually difficultly
of being a mutation observer.

Also, I'll just note a difference in view: We view it as fundamentally
a bad thing to have more than one actor operating at a time (where
actor == event handler, or abstraction which observes mutations). It
seems as though you guys view this as a good thing (i.e. All other
problems aside, mutation events *should* be synchronous).

The example I keep using internally is 

Re: Test suites and RFC2119

2011-07-05 Thread Aryeh Gregor
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 100% compliant without needing to pass non-MUST and non-MUST NOT tests.

 Perhaps we should introduce 'bonus' points for SHOULD/SHOULD NOT/MAY and
 RECOMMENDED tests and not have them contribute to overall compliance output,
 thereby allowing implementations to claim 100% compliance to MUST/MUST NOT
 tests. An implementation can then optionally collect any available, optional
 bonus points as available from requirements marked up with other keywords.

 Wondering if there is any set W3C thinking on this or a way of including
 SHOULD tests in test suites but clearly indicating that they are, basically,
 optional and do not count towards the overall compliance score? I couldn't
 find anything in [1].

The way HTML5 does it is define different conformance classes:

http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-classes

For instance, some requirements apply only to user agents that support
scripting, some only to user agents that support the default
rendering, etc.  In practice this means that there are few testable
should requirements.

Generally, if something is important enough for interop that we want
to test it, we don't want to make it a should requirement.  It
should be a must.  What examples do you have of should
requirements that you want to test?



Re: Mutation events replacement

2011-07-05 Thread Ryosuke Niwa
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 handled in a task?Basically, if DOM is mutated during task A, a
 new task, B, is scheduled and all the mutation listeners will be
 called there.


 It's too late by then. Most importantly, visual artifacts of incomplete
 DOM work may have been seen by the user.


 If that is the reason, I don't think it really holds. The script may force
 a layout flush right after DOM mutation and then cause some popup to shows
 up which may cause repainting in the main page.


Layout is different from paint at least in WebKit.

But I agree with you that if any observer calls alert, showModalDialog, and
other APIs that forces repaint, you can't really do anything about it.
 Also, UA vendors can decide to delay the repaint until all mutation
observers are called in common cases even if they were completely
asynchronous.

- Ryosuke


Re: Publishing From-Origin Proposal as FPWD

2011-07-05 Thread Bjoern Hoehrmann
* 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 discussion
 of these concerns yet.

I note that the Web Applications Working Group's Charter, if Brad Hill
is a member, does require the rest of the Working Group to duly consider
his points before moving on without consensus. If not, then the group is
not required to wait with publication, but not discussing the points in
a timely manner, without an argument how publication is urgent in some
way, does not inspire confidence that the arguments will be heard and
duly handled.

Publication will enable wider discussion - particularly wrt the issues
you have raised. Not publishing it is tantamount to saying I OBJECT
TO PROGRESS!. If you are correct, more people will see it and the
proposal will be shot down. Otherwise, other opinions will flourish
that may sway your position (or a new perspective will emerge all
together). In any case, calling for a spec not to be published, no
matter how bad it is, is not the right way to do this. Publishing a
spec is just a formality which can lead to discussion.

The more invested people are into something, the less likely they are
to cut their losses; by doing things, you frame the discussion in favour
of doing more. You get people to think more about how something can be
fixed rather than thinking about whether to abandon the work, or use a
very different approach. If you just propose an idea to me, we can talk
about it more freely than if you had already invested a lot of effort
on implementing the idea and asked me to review the idea after the fact.

(~ Die normative Kraft des Faktischen)

Realizing something is a bad idea early is therefore very important and
not objecting to progress. Not wasting time on bad ideas is certainly
progress, even if only indirectly as you'd work on other things instead.
As such it is quite important to react timely to design critique with
care and detail. Psychologically, if you press ahead, you communicate
that you care more about moving on than discussing details, which is
likely to turn away the people more interested in details and quality;
and the same is of course true for draft of genuinely bad quality.

Which is just to say this is actually an important matter; sometimes it
is best to go ahead and put your ideas into practise whatever others may
be saying, other times it turns out that you should have listened more.
That is why we allow people to block actions, not necessarily progress,
but only up to the point where arguments have been duly considered. And
here we have yet to do that. Until that happens, short of someone making
the case for urgency, I would agree the group should not publish and
talk about this instead.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 



[indexeddb] Using IDBDatabaseSync.close or IDBFactorySync.deleteDatabase inside transaction's callback method

2011-07-05 Thread Israel Hilerio
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.

We can throw an IDBDatabaseException with NOT_ALLOWED_ERR if a developer tries 
to do this.

Israel



Re: Mutation events replacement

2011-07-05 Thread Rafael Weinstein
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 require a new mechanism for async handling? Could
 listeners be handled in a task?Basically, if DOM is mutated during task A, 
 a
 new task, B, is scheduled and all the mutation listeners will be
 called there.

 It's too late by then. Most importantly, visual artifacts of incomplete
 DOM work may have been seen by the user.

 If that is the reason, I don't think it really holds. The script may force
 a layout flush right after DOM mutation and then cause some popup to shows
 up which may cause repainting in the main page.

 Layout is different from paint at least in WebKit.
 But I agree with you that if any observer calls alert, showModalDialog, and
 other APIs that forces repaint, you can't really do anything about it.
  Also, UA vendors can decide to delay the repaint until all mutation
 observers are called in common cases even if they were completely
 asynchronous.

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 into avoiding flickr, you probably aren't using alert and
showModalDialog anyway].

Also, it's up to the app when to do it, so it's entirely in its
control (and thus avoid visual artifacts).

Note that this is a problem with both proposals. Work done in (at
least some) mutation observers is delayed. If a sync paint occurs
before it, it's work won't be reflected on the screen.

 - Ryosuke




Re: Mutation events replacement

2011-07-05 Thread Ryosuke Niwa
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 into avoiding flickr, you probably aren't using alert and
 showModalDialog anyway].

 Also, it's up to the app when to do it, so it's entirely in its
 control (and thus avoid visual artifacts).


Given that we don't provide an API to control paint in general, I'm not
convinced that we should add such a requirement in the DOM mutation event
spec.

Note that this is a problem with both proposals. Work done in (at
 least some) mutation observers is delayed. If a sync paint occurs
 before it, it's work won't be reflected on the screen.


Right.  Maybe we can add a note saying that the user agents are recommended
not to paint before all mutation observers are called.  I don't think we
should make this a requirement.

- Ryosuke


Re: [indexeddb] Using IDBDatabaseSync.close or IDBFactorySync.deleteDatabase inside transaction's callback method

2011-07-05 Thread Jonas Sicking
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 
 will reduce the number of possible deadlocks inside the transaction callback.

 We can throw an IDBDatabaseException with NOT_ALLOWED_ERR if a developer 
 tries to do this.

Yes, this sounds like a good idea. Obviously this doesn't affect the
async API, right?

/ Jonas



Re: Mutation events replacement

2011-07-05 Thread Ojan Vafai
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 enough about the visual polish of your app that you will put
 energy into avoiding flickr, you probably aren't using alert and
 showModalDialog anyway].

 Also, it's up to the app when to do it, so it's entirely in its
 control (and thus avoid visual artifacts).


 Given that we don't provide an API to control paint in general, I'm not
 convinced that we should add such a requirement in the DOM mutation event
 spec.


Many of the use-cases for mutation events (e.g. model-driven views) are
poorly met if we don't give some assurances here.


  Note that this is a problem with both proposals. Work done in (at
 least some) mutation observers is delayed. If a sync paint occurs
 before it, it's work won't be reflected on the screen.


 Right.  Maybe we can add a note saying that the user agents are recommended
 not to paint before all mutation observers are called.  I don't think we
 should make this a requirement.


There may be a middle ground that isn't so hard to for browser vendors
implement interoperably. Can we require no repaint except in the presence of
a specific list synchronous API calls? I'm sure that's too simplistic, but
I'm hoping someone with more experience can chime in with something that
might actually be a plausible requirement.

- Ryosuke



RE: [indexeddb] Using IDBDatabaseSync.close or IDBFactorySync.deleteDatabase inside transaction's callback method

2011-07-05 Thread Israel Hilerio
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 IDBDatabaseSync.transaction or IDBDatabaseSync.setVersion?  This
 will reduce the number of possible deadlocks inside the transaction callback.
 
  We can throw an IDBDatabaseException with NOT_ALLOWED_ERR if a
 developer tries to do this.
 
 Yes, this sounds like a good idea. Obviously this doesn't affect the async 
 API,
 right?
 
 / Jonas

Correct! This will only impact the sync APIs, not the async APIs.

Israel



RE: Publishing From-Origin Proposal as FPWD

2011-07-05 Thread Hill, Brad
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 proposed Web Applications Security WG (currently in the 
process of being chartered and of which I am a proposed co-chair)  was 
solicited as to whether the work should move to that forum or be a joint 
deliverable with the Content Security Policy.  Additionally, one of the goals 
of the draft was to address concerns around clickjacking, an item under the 
proposed charter scope of the WebAppSec WG.  Wearing that (still phantom) hat, 
I can say is that there isn't consensus to move this proposed mechanism as a 
cross-domain framing security solution to FPWD, alone or as part of the CSP, in 
the WebAppSec WG, at this time.  Until AC approval, we can't move anything to 
FPWD at this time.  :)

My other concerns with the proposal are put forward only as an interested 
member of the community.  I expect there will be ample opportunity to discuss 
them.  If Art feels that moving forward to FPWD is the best next step to foster 
that and other discussions, I'm more than happy to participate there to the 
extent the WG welcomes my feedback and finds it useful.

Thanks,

Brad Hill

-Original Message-
From: public-web-security-requ...@w3.org 
[mailto:public-web-security-requ...@w3.org] On Behalf Of Bjoern Hoehrmann
Sent: Tuesday, July 05, 2011 4:38 PM
To: Marcos Caceres
Cc: WebApps WG; public-web-secur...@w3.org
Subject: Re: Publishing From-Origin Proposal as FPWD

* 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 discussion of 
 these concerns yet.

I note that the Web Applications Working Group's Charter, if Brad Hill is a 
member, does require the rest of the Working Group to duly consider his points 
before moving on without consensus. If not, then the group is not required to 
wait with publication, but not discussing the points in a timely manner, 
without an argument how publication is urgent in some way, does not inspire 
confidence that the arguments will be heard and duly handled.

Publication will enable wider discussion - particularly wrt the issues 
you have raised. Not publishing it is tantamount to saying I OBJECT TO 
PROGRESS!. If you are correct, more people will see it and the 
proposal will be shot down. Otherwise, other opinions will flourish 
that may sway your position (or a new perspective will emerge all 
together). In any case, calling for a spec not to be published, no 
matter how bad it is, is not the right way to do this. Publishing a 
spec is just a formality which can lead to discussion.

The more invested people are into something, the less likely they are to cut 
their losses; by doing things, you frame the discussion in favour of doing 
more. You get people to think more about how something can be fixed rather than 
thinking about whether to abandon the work, or use a very different approach. 
If you just propose an idea to me, we can talk about it more freely than if you 
had already invested a lot of effort on implementing the idea and asked me to 
review the idea after the fact.

(~ Die normative Kraft des Faktischen)

Realizing something is a bad idea early is therefore very important and not 
objecting to progress. Not wasting time on bad ideas is certainly progress, 
even if only indirectly as you'd work on other things instead.
As such it is quite important to react timely to design critique with care and 
detail. Psychologically, if you press ahead, you communicate that you care more 
about moving on than discussing details, which is likely to turn away the 
people more interested in details and quality; and the same is of course true 
for draft of genuinely bad quality.

Which is just to say this is actually an important matter; sometimes it is best 
to go ahead and put your ideas into practise whatever others may be saying, 
other times it turns out that you should have listened more.
That is why we allow people to block actions, not necessarily progress, but 
only up to the point where arguments have been duly considered. And here we 
have yet to do that. Until that happens, short of someone making the case for 
urgency, I would agree the group should not publish and talk about this instead.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am 
Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 




Re: Mutation events replacement

2011-07-05 Thread James Robinson
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 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 into avoiding flickr, you probably aren't using alert and
 showModalDialog anyway].

 Also, it's up to the app when to do it, so it's entirely in its
 control (and thus avoid visual artifacts).


 Given that we don't provide an API to control paint in general, I'm not
 convinced that we should add such a requirement in the DOM mutation event
 spec.


 Many of the use-cases for mutation events (e.g. model-driven views) are
 poorly met if we don't give some assurances here.


  Note that this is a problem with both proposals. Work done in (at
 least some) mutation observers is delayed. If a sync paint occurs
 before it, it's work won't be reflected on the screen.


 Right.  Maybe we can add a note saying that the user agents are
 recommended not to paint before all mutation observers are called.  I don't
 think we should make this a requirement.


 There may be a middle ground that isn't so hard to for browser vendors
 implement interoperably. Can we require no repaint except in the presence of
 a specific list synchronous API calls? I'm sure that's too simplistic, but
 I'm hoping someone with more experience can chime in with something that
 might actually be a plausible requirement.


HTML specifies to a limited extent when painting can happen with regard to
what it defines as tasks:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2

See step 5 - update the rendering is equivalent to painting.  Ignoring
step (2) which relates to the storage mutex, this description is accurate.
 No browser updates the rendering after invoking every single task, but I'm
pretty sure that no modern browser updates the rendering at any other time.
 Note that a few APIs such as showModalDialog() invoke this algorithm:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop

which effectively starts up a second event loop within the processing of a
task, meaning that the browser can paint while the task that resulted in the
showModalDialog() call is still running.  Authors who are using
showModalDialog() are being extremely user-hostile so I don't think we need
to accomodate them.

One question I have with regards to the proposed processing model is whether
to define this in terms of entering script or in terms of 'tasks' in the
HTML sense.  For example, asynchronous DOM events are typically set up by
queueing a single task to fire the event, but there might be multiple event
listeners registered for that one event that would all be fired as part of
the same task.  If we were to define things in terms of tasks, then I think
Rafael's proposal is similar to extending step 4 provide a stable state of
the event loop algorithm in order to notify observers before proceeding to
step 5.  This would mean that if multiple click handlers were registered on
an element and the user clicked on it, all of the event handlers would run,
then the mutation observers would run, then the browser would be free to
paint if it chose to.  An alternative approach would be to hook on calling
in to script (
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts)
and run the observers after each script invocation.  This means that if
multiple handlers were registered for an event then the first handler would
be invoked, then observers notified, then the second handler invoked, etc.
 It would still have the property that the observers would always run before
the browser painted so long as no script spun the event loop.

I hope this helps.  This has been a long thread and I haven't had a chance
to fully digest all of it, but I'm really happy that people are taking a
serious look at this problem.
- James



 - Ryosuke