On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: > On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein <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. - Ryosuke >
Received on Wednesday, 6 July 2011 00:52:22 UTC