RE: WebKit Incremental Layout

2008-02-14 Thread josh.soref
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of ext Alp Toker
 Sent: February 13, 2008 5:01 PM
 To: David Carson
 Cc: maemo-developers; [EMAIL PROTECTED]
 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.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: WebKit Incremental Layout

2008-02-13 Thread Alp Toker
zaheer ahmad wrote:
 hi,
 can somebody suggest websites where we can see a considerable difference 
 using LOW_BANDWIDTH_DISPLAY or the FOUC  problem.  i dont seem to see 
 the difference  with  most  links i have tried.

The WebKit FOUC with LOW_BANDWIDTH_DISPLAY is quite distracting to me 
both on the desktop and on mobile devices, so much so that I don't think 
it's even worth supporting as an official configure flag right now.

If you didn't notice it, the only possibility I can think of is that you 
passed the wrong CPPFLAGS. It needs to be precisely:

-DWTF_USE_LOW_BANDWIDTH_DISPLAY=1

So, if you are using the configure script and compiling for the Maemo 
mobile platform:

CPPFLAGS=-DMOBILE=1 -DWTF_USE_LOW_BANDWIDTH_DISPLAY=1 ./configure 
--prefix=/opt/webkit --enable-video --disable-xslt --with-hildon

I actually think a throbber or other load notification system is much 
more effective. When users see unstyled content (HTML without CSS), they 
immediately consider it a bug in the browser. Not good.

So in summary, -DMOBILE=1 is good, -DWTF_USE_LOW_BANDWIDTH_DISPLAY=1 is 
not so good. The loader in current builds is significantly faster and 
better at scheduling than those in other mobile browsers so I don't 
think we need hacks like this. Try it out and see what you think :-)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: WebKit Incremental Layout

2008-02-13 Thread Alp Toker
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)

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.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers