[maemo-developers] WebKit Incremental Layout

[From: josh.soref at nokia.com]

> -----Original Message-----
> From: maemo-developers-bounces at maemo.org 
> [mailto:maemo-developers-bounces at maemo.org] On Behalf Of ext Alp Toker
> Sent: February 13, 2008 5:01 PM
> To: David Carson
> Cc: maemo-developers; webkit-dev at lists.webkit.org
> Subject: Re: WebKit Incremental Layout
> 
> David Carson wrote:
> > the main issue that it tries to address is that on really 
> really slow 
> > networks, the user goes to a site and takes a long time to 
> load, and 
> > they think the browser has stopped working or is not doing 
> anything and 
> > give up and cancel the load.
> > By showing some content, some progress, the user can see 
> that there is 
> > activity and will continue to wait for the page to load.
> > Again, this is for slow network connections (ie low bandwidth)

If this is the actual problem you want to solve, I would hope there are
better ways that we could solve it.

> I used this on a real mobile device with a slow connection 
> for a couple 
> of weeks to get a feel for it.
> 
> As a browser developer, the feature at first seemed neat. But 
> as an end 
> user I found that the appearance of styling up to ~10/20 
> seconds later 
> was annoying, since by that point I'd already started reading the 
> unstyled content and was getting the information I needed. The 
> subsequent CSS load often meant I had to find the 
> newly-styled paragraph 
> and start reading it all over again.
> 
> Maybe it's subjective, and maybe there's a technical solution to make 
> the transition from unstyled to styled content less distracting. I've 
> pinged some other mobile browser developers to get their 
> thoughts on this.

I've heard a lot of people complain about the style jump problem, and I
experience it too. It'd be less of an issue if:
1. the user was prevented from accidentally clicking as things moved
(this requires disabling input for a couple of seconds before/after a
rendering) - and this is almost certainly going to annoy someone, but
perhaps not as much as accidentally clicking on the wrong thing. On
mobile devices, accidental clicks are very expensive as you lose the
current page, have to wait for a new page, and going back can result in
you waiting again.
2. somehow enable the user to indicate exactly which element they're
looking at (this is impossible with most input methods today - eye
scanning being the only exception), plus distinguishing between
overlapping elements :)

Given that both 1 and 2 are expensive, 1 is hard and 2 is impossible, I
think the blocking approach on CSS is better.

I think basically that Opera got a press win for this behavior, but
overall we'd be better off with everyone refusing to do this form of
incremental rendering, as it'd encourage sites to design content where
the css is not expensive and is designed to be preloaded+cached for
future pages.

Note: I'm replying to a cross posted entry to maemo-developers. I would
not normally comment to webkit-dev and suspect that they might find this
offensive, I'm sorry and do not intend to send any further comments.