Re: Mutation events replacement

On 07/06/2011 08:14 AM, James Robinson wrote:
> On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai <ojan@chromium.org
> <mailto:ojan@chromium.org>> wrote:
>
>     On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa <rniwa@webkit.org
>     <mailto:rniwa@webkit.org>> wrote:
>
>         On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein
>         <rafaelw@google.com <mailto:rafaelw@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.
>
>
>     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.


Sync XHR is one case when at least some browsers do repainting.
And yes, sync XHR is probably as user-hostile as showModalDialog(), but
unfortunately it is used quite often.



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

Received on Wednesday, 6 July 2011 09:48:09 UTC