Re: positioned elements: center

David Woolley wrote:
>
> Andrew Fedoniouk wrote:
>
>> If you want to center something in the view then you
>> will prepare block that will (usually) fit in the view in the whole.
>> Thus, it is highly probable that your document will be contained
>> in the very first http buffer (4k or so) in the whole.
>
> The optimum TCP segment size on WANs is slightly less than 1500 bytes 
> and modern software should be using path MTU discovery to ensure this 
> is achieved.  On the other hand, yahoo.co.uk's home page is 100K.  
> Almost half of this is the embedded style sheet, and it is a bit 
> difficult to separate scripting from content.  (Note, whilst your web 
> browser may supply 4K buffers for its network reads, the typical 
> kernel support for TCP will return control when it runs out of 
> available segments, even if there is buffer space left.)
>
MTU size is usually not directly related to http client buffer size.
For example libcurl http client is using 16384 byte buffers. Apache can 
be configured through SendBufferSize. I've seen 4k-16k settings.

yahoo.co.uk's home page is not designed to be centered so this is a bad 
example.
http://www.google.ca/ is a better example of such page that ideally has 
to be centered.
And it has near the optimal size - 6k.

> Whilst good use of HTML, CSS, and external style and script files can 
> reduce the size of documents from competent authors, I'm more 
> concerned about the majority of documents, which are also likely to 
> have a lot of bloat from inline styling.  A TCP segment is likely to 
> be small compared with many home pages.
As I said majority of documents will exceed view size so this centering 
(and other forms of vertical alignment) will be in effect only for very 
first moment. Rest of the document will be loaded incrementally and 
rendered without any vertical alignment. No free space in the view - 
nothing to align.
>
> My concern with vertical centering arises partly from what happened 
> when the CENTER element was first introduced.  Ignoring my opinions 
> about the bad effect this has had on web page readability, the point 
> is that it illustrates that web authors love centering.  I suspect, 
> therefore that an easy to use vertical centering mechanism will get 
> heavily used.
I am not familiar with any problems with <center> other than aesthetic ones.

Let's imagine that auto works in vertical dimension too so following:

<body>
   <div style="margin:auto; width:50%; height:50%; 
min-height:intrinsic;"> the-content </div>
</body>

will position element in the view in the middle of the view.
What kind of problems with incremental rendering you will see here?

>
> That leaves the question of whether people will only use it for small 
> items that can reasonably have their rendering deferred.  My guess is 
> that most people will use it that way, but I still think a quite large 
> number will use it to centre the main part of their homepage.  
> Typically people try and get the home page onto one screen but they 
> also often try and cram large amounts on it (one of the reason for the 
> font size usability problems)
Take a look on markup above and imagine that the-content will be big 
enough to do not fit in the view.
margin-top and margin-bottom will not be in effect then. The page will 
behave as if margin-top and margin-bottom are both equal to zero.
Again, where you see the problem here?

If to think about "incremental loadabilty" in general I would rather 
consider use of  client side includes:
<body>
     <div style="margin:auto; width:50%; height:50%; overflow:auto">
          <include src="fragment.htm">
               Ooops, no <i>fragment.htm</i> on this server!
          </include>
     </div>
</body>

This short document will establish layout in the view so  fragment.htm 
can be loaded incrementally without animating and rebuilding the whole 
page again and again.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Wednesday, 9 January 2008 00:38:41 UTC