- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 06 Jul 2011 12:47:12 +0300
- To: James Robinson <jamesr@google.com>
- CC: Ojan Vafai <ojan@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, Rafael Weinstein <rafaelw@google.com>, Olli@pettay.fi, Aryeh Gregor <Simetrical+w3c@gmail.com>, Adam Klein <adamk@google.com>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, Webapps WG <public-webapps@w3.org>
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