in reply to Re: CGI Question
in thread CGI Question

Further re almut's fine reply, "And browsers vary as to when they actually render content."

Further, the html elements matter. If, for example, your page is formatted using a <table>, <tr>, <td> structure, and you fail to provide width="..." specifications (or the css equivalent), your browser will HAVE TO WAIT for the </table> element to arrive in order to calculate the cell widths to use in rendering. Thus, no matter what you do at the server end, you won't be able to have your table render at intermediate stages.

In this narrow case, you can improve the chance that you'll get intermediate elements rendered, row-by-row, by spec'ing the width of each cell in the first row, be that a <tr> of <th> elements or a row of <td> elements. Note, however the operative phrase here is "improve the chance...."

Even doing so (which is a commonly accepted "Good Practice" for webmonkeys) won't overcome the other possible issues noted by almut and others.

Update: Fixed spelling of almut; closed code tag after 'width="...."'.

Replies are listed 'Best First'.
Re^3: CGI Question
by ikegami (Patriarch) on Apr 02, 2009 at 22:29 UTC

    your browser will HAVE TO WAIT for the </table> element to arrive in order to calculate the cell widths to use in rendering.

    I'm sure I've seen browsers render the table before it had fully arrived, and re-render the table as more info arrived. Of course, the browser is by no means obligated to do so.

      Consider this crude (uses some deprecated elements; fails accessibility standards; other shortcomings) example:

      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http:/ +/www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>demo</title> <meta http-equiv="Content-Style-Type" content="text/css"> </head> <body> <table summary="your order"> <thead> <tr><th>Item</th> <th>Item #</th> <th>Shiping</th> <th>Unit Price</th> <th>Quantity</th> <th style="text-align:right;">Item Total</th> </tr> </thead> <tbody> <tr> <td>foo</td> <td>12345</td> <td>Post</td> <td>9.99</td> <td>10</td> <td style="text-align:right;">99.90</td> </tr> <tr> <td>bar</td> <td>123456</td> <td>Bicycle Messenger</td> <td>1.99</td><td>1000</td> <td style="text-align:right;">1999.00</td></tr> <tr><td>blivitz</td> <td>1234567</td> <td>Pony Express</td> <td>9.99</td><td>10</td> <td style="text-align:right;">9999.00</td> </tr> <tr><td colspan="6"> ...Many more rows with item totals of &lt; 10,000 +.00 .... </td></tr> <tr> <td colspan="5" style="text-align: right;">Order Total:</td><td style= +"text-align:right;">125,567,097.90</td></tr> </tbody> </table>

      Before the rendering engine can calculate a proper width for the last column, it must know the maximum width needed (ie, 14 characters for the last col of the last row), which it cannot know until all <table> (or, at least, all <tbody> in this case) has been received.

      Were it to start after receipt of the first <tbody> row, the width it allocated would be inadequate for the last cell in the row containing "Order Total:" and it would therefore have to re-render the rows above. It could, of course, be engineered to do it that way, but the consequence would be additional load on the processor and screen jitter for the viewer... which is why browsers (well, those with which I have any familiarity) do not render tables until they have width info, whether from complete receipt of the table or width info from the tags, as, for an even cruder example:

      <table width="90%" summary="Using widths (should use css these days)"> <tr> <td width="10%">something</td> <td width="50%">something longer</td> <td width="40%">middlin' long</td> </tr> </table> </body> </html>

      The second example allows the rendering engine to assign/allocate appropriate widths without waiting for all data.

        It could, of course, be engineered to do it that way, but the consequence would be additional load on the processor and screen jitter for the viewer...

        You use a timer. Start rendering the page if it's been X seconds since content started being received and if it's been Y seconds since it's last been rendered.

        That way, the page isn't dead and the brower isn't spending all its time repositioning everything.