If you use css you can use print style sheets to ensure your document prints just as well as it displays. And if you use the @import rule, you can ensure it renders it's content to old browsers.
In a world without walls and fences - who needs Windows and Gates?! - Unknown Author
"And there's Bill Gates, the...most...famous...man in the...ah...Microsoft." -- A TV commentator for the 2000 Olympics.
Hi everyone, I so very much appreciate all the help you have offered. I apologize for the lack of reply.
I live in the Houma area of Southern Louisiana, and was effected by Hurricane Katrina, so have not had much ability to get online and back to this thread!
I apologize also, but I'll have to put all this on hold for a while, as in the meantime I'm working on helping out and reaching out to those worse affected by this devastating storm, and the aftermath of it all.
I'll return to this thread though, after all this is largely finished (well, after handling some other things). Thank you all again, so much, for your help, and your future help as well
I know you're helping out, HS77, and good luck with that. I hope all your family members are safe. But for when you come back to this, here's a little explanation about tables and DIVs.
The table algorithm is extremely complex. If a box is too big to fit in the current cell, that cell, and all containing cell widths have to be recalculated, as do all the other block elements inside those cells if those block elements are not given a width. So there can be a LOT of recursive calculations. This means loads of processor time. On top of that, the problem you mentioned of the content not appearing until all of it has been downloaded stems from an inate behavior with tables.
Remember that no matter how you use a table, it represents something logically, and that's data separated into rows, or records. Logically, since each row is a record, and therefore a separate entity, it makes no sense to display the cells individually. Usually, only after all the data in a row has been downloaded will that row display. Some browsers do this on a cell-by-cell basis too.
Using DIVs, rather using non-table elements and CSS to generate the layout of a page, is a MUCH simpler algorithm. Things fit or they don't. Unless you set certain CSS properties, there are no width recalculations. Non-table elements also appear quicker because there is no logical connection between a containing block and the blocks it contains. Headings, images and paragraphs will all appear after those individual elements are downloaded, not after the entire DIV is downloaded.
Since any whole element appears as it's being downloaded, DIV + CSS layouts appear quicker in addition to having the visual formatting information in a separate file that gets cached by the browser and used on multiple pages.
Hope that gives you an insight as to how tables are often slower.
100k of text probably needs to be broken up into about 10 pages if you are putting it on the web. You can then put a second copy all in one page for people to print out when they want a printed copy of the whole thing.
Splitting a page is one of the most annoying things you can do - I hate it when I come across an interesting article, but don't have time to read it. Of course I print it, and read it at home, or on the bus or something, but not if I only got one page out of five, or worse still, all but the last paragraph. The latter often happens when an automated system splits the pages.
What is the point of having print stylesheets if you have to find a tiny icon on the page, and load a new page to be able to print?
Here is the Rule of Thumb for page loading. If you want your pages to download and render in 10 seconds or less for users on a 56k dial-up connection, your page weight (total size in bytes for all code, images and objects) must be lass than 60k. More than 40% of USA home users are still on slow dial-up connections. The numbers are quite different for businesses, most of which have adopted broadband.
If you decide to stick with tables, there is a benefit to breaking the page up into seperate header, content and footer tables. The header table will render first, giving the user a visual clue that the page is loading, rather than staring at a blank screen or the last page they viewed.
CSS is clearly a benefit for improving both page loading and rendering for anyone using a fairly current browser. One more tip for perfromance: validate your code using the W3C online validator. Pages render faster when the code is error-free.
I decided to start back on this, though I'm still helping out with other things too.
I considered many options as to how I can get these pages loading as fast as possible, from CSS to tables alike, as well as separating them into different pages. But the last, really isn't something I wanted to do because I don't want to interrupt someone from reading straight through.
Ultimately, I tried something that I thought of doing for a different page on the website . . . stripping the page of all images (except one), and nearly all code too . . .
A simple option there . . . When I made the page, it loaded very quickly, but again I have a high-speed connection.
Is it loading quickly for anyone else? Or loading at least at a decent speed?