Total amount of data required to load a page

[Leo Savernik]

Am Donnerstag, 25. August 2005 18:22 schrieb Paulo Moura Guedes:
> > Well, the progress bar is just a hint, and it jumps around wildly as new
> > descendants become known. While it is impossible to predict the total
> > size of a document at the beginning, you possibly *could* predict the
> > total size after you've parsed the principal and all descendants
> > recursively.
>
> There are any specs telling which descendants should be considered?

Well, many.
 First html/xhtml, to tell you which elements may include external content (<img>, <link>, <script>, <iframe>, <object> etc.)
Then the specs of the descendants like css, which can in turn include other css rules by @import etc
xml-based markup (like svg). This becomes more important when khtml supports compound documents.
scripting-languages which can dynamically make content available at load time. You cannot even draw a definite line which part of dynamical loading can be attributed to the "initial" phase (and hence the total size), or the "interactive" phase.

Short: You cannot determine the exact total size unless you parse every object recursively in the same manner as the browser. Every "shortcut" is only an estimation.

>
> > However, as soon as one get/post-operation doesn't deliver a content-size
> > header, you're lost.
>
> A job signal like "totalSize" wouldn't do it?

Afaik kio_http emits content-size as totalSize iff it is encountered.

mfg
	Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050826/a8d0320d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050826/a8d0320d/attachment.sig>