Re: Mutation events replacement

On 07/06/2011 09:12 PM, James Robinson wrote:
> On Wed, Jul 6, 2011 at 2:47 AM, Olli Pettay <Olli.Pettay@helsinki.fi
> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>     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>
>         <mailto: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>
>         <mailto: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>
>         <mailto: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
>         <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
>         <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.
>
> What browser(s) do this?  That sounds like a bug in those
> implementation(s),
How so? I don't know any spec which disallows this.
Gecko may repaint while handling sync XHR - similar to alert or
other modal dialogs.


  and not something we should worry about standards-wise.
>
> - James
>
>

Received on Wednesday, 6 July 2011 18:30:10 UTC