Re: positioned elements: center

Andrew Fedoniouk wrote:

>>
> 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.

I covered that in my original by pointing out that operating systems 
will normally return control before the buffer is full when reading from 
networks.  On most platforms (Windows, Unix, at least) the browser will 
be going out of its way to slow down rendering if it forces the buffer 
to be completely filled before it is processed.

> 
> 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.

But that is a page that has been designed for efficiency.  Most home 
pages are extremely bloated, and it is home pages where most design 
effort is expended.


> I am not familiar with any problems with <center> other than aesthetic 
> ones.

Although not relevant here, the readability problem particularly affects 
skimming.  Centering, especially in the beginning, was particularly 
fashionable for menus, but it makes it difficult to skim the list for a 
particular entry.  It's another example where, because something became 
doable every one did it, even though it was also doable in traditional 
media, but rarely used. (The problem for CSS, I think, is that it 
combines block centering with centre justification, whereas one may well 
want the former without the latter.)

> 
> 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?

There are two principles at work here.  You only avoid the incremental 
rendering problem by introducing a cascade problem, as this will no 
longer work well if the font isn't the exact one that the author chose. 
  (Brad's Drip... title demonstrates that even switching operating 
systems can compromise designs that are too dependent on font 
selections.  Firefox uses minimum font size rather than completely 
disabling font sizes to get round font size problems, and only the 
footer on that pate went below my minimum.)

I am sure that it is possible to find examples that don't have 
incremental rendering problems, but in its historic role of protecting 
content consumers, particularly those without a strong voice themselves, 
needs to cover what average designers will do when coding from book shop 
CSS cook books and copy and paste of other sites.

> Take a look on markup above and imagine that the-content will be big 
> enough to do not fit in the view.]

Fitting in the view is not sufficient to mitigate incremental rendering 
problems.  Incremental rendering is about making text (preferably that 
the the user is most likely to want to read) available as early as 
possible, without subsequently moving it around.  Text justification 
means that that should be in units of single lines (always subject to 
TCP segmentation).  Although it is a different issue, namely using table 
  based layout with out used table-layout:fixed, and unsized images, 
even on my 6Mb/s connection, many single page homepages get severely 
delayed because they won't incrementally render.

Incidentally, there are some web applications, although I cannot think 
of a specific one at the moment, that grow an indefinitely large page in 
real time.  Those will not work well with any browser that doesn't 
process TCP segments as soon as it can (on the sending side, TCP 
implementations will truncate segments when the previously transmitted 
segment has been transmitted, and maybe a short timeout has expired).


-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Received on Wednesday, 9 January 2008 08:22:21 UTC