Stylesheets - How do you vertically center an html table in css.

Author

How do you vertically center an html table in css.

john T

2004-02-19, 12:29 am

Is there anyway to vertically center a html table using css in such a
way it does not alter the html table. When I tryied it just screws up.

Els

2004-02-19, 4:28 am

john T wrote:

> Is there anyway to vertically center a html table using css in such a
> way it does not alter the html table. When I tryied it just screws up.

As far as I know there are only two ways:
One is with absolute positioning it at 50% from the top,
with a negative margin of half the height of the table.
this way you lose sight of half the table in a smaller
window, with no way of accessing it by using scrollbars.
So don't use that one :-)

The other is by placing it in another table. One cell table
even.

--
Els

Mente humana é como pára-quedas; funciona melhor aberta.

Christoph Paeper

2004-02-19, 7:29 am

*john T*:
>
> Is there anyway to vertically center a html table using css in such a
> way it does not alter the html table.

table {display: inline-table; vertical-align: middle}

I've never seen any need to do such a thing, so I have never tried that, but
"display: inline-table" will probably not work in a lot of browsers,
although the overall result would be the same.

To vertical align something the renderer has to know two heights, the one of
the box to be aligned and the one of the containing box. The boxes 'html'
and 'body' generate are not as high as the available viewport (i.e. the
browser window's inner height), but only as high as they need to be. With
some hackery you can get all recent browsers to make them at least 100%
high, though.

--
Useless Fact #4:
Coca Cola was originally green.

2004-02-19, 12:29 pm

Els wrote:
>
>
> john T wrote:
>
>
>
> As far as I know there are only two ways:
> One is with absolute positioning it at 50% from the top, with a negative
> margin of half the height of the table.

According to the specs, you will center that table within the middle of
the document, not within the middle of the browser viewport. Both MSIE 6
and Mozilla 1.x have bugs regarding %tage with pos. abs.:

Bug 105286: viewport used as containing block for absolutely positioned
elements instead of root (percentage height, %, bottom)
http://bugzilla.mozilla.org/show_bug.cgi?id=105286

> this way you lose sight of half the table in a smaller window, with no
> way of accessing it by using scrollbars.

I wonder why you say that the browser viewport then would not provide
any scrollbars.

> So don't use that one :-)
>
> The other is by placing it in another table. One cell table even.
>

Nested tables are definitively NOT a solution; it's a worse solution.

Assuming this code:

#idTable
{
position: fixed;
top: 50%;
margin-top: -125px;
height: 250px;
}

(...)

<table id="idTable" ...>

then it should work perfectly in Mozilla 1.3+ and in Opera 7.x.

DU

PeterMcC

2004-02-19, 1:30 pm

DU <drunclear@hotWIPETHISmail.com> wrote in
<c12ocp$13$1@news.eusc.inter.net>

> Els wrote:
>
> According to the specs, you will center that table within the middle
> of the document, not within the middle of the browser viewport. Both
> MSIE 6 and Mozilla 1.x have bugs regarding %tage with pos. abs.:
>
> Bug 105286: viewport used as containing block for absolutely
> positioned elements instead of root (percentage height, %, bottom)
> http://bugzilla.mozilla.org/show_bug.cgi?id=105286
>
>
> I wonder why you say that the browser viewport then would not provide
> any scrollbars.

When using the half-the-width/height-negative-margin trick, if the viewport
is narrower than the contents, the left-hand side of the contents is off the
left-hand side of the screen and the scrollbar won't go backwards.
Similarly, if the contents won't fit vertically, you can't scroll up to see
the stuff that's off the top of viewport.

IMHO, the dubious benefits of vertical centring are simply not worth the
efforts needed to achieve a result that doesn't work once the viewport is
smaller than the content. Since most page content takes up a large portion
of the viewport - or there's very little content in which case why bother -
it will probably not take much of a reduction in the viewport to trigger the
problem.

--
PeterMcC
If you feel that any of the above is incorrect,
inappropriate or offensive in any way,
please ignore it and accept my apologies.

Els

2004-02-19, 1:30 pm

DU wrote:

> Els wrote:
>
>
> According to the specs, you will center that table within the middle of
> the document, not within the middle of the browser viewport.

The OP didn't state it had to be in the middle of the
browser viewport, neithe did I.

> Both MSIE 6
> and Mozilla 1.x have bugs regarding %tage with pos. abs.:
>
> Bug 105286: viewport used as containing block for absolutely positioned
> elements instead of root (percentage height, %, bottom)
> http://bugzilla.mozilla.org/show_bug.cgi?id=105286
>
>
> I wonder why you say that the browser viewport then would not provide
> any scrollbars.

I didn't say it wouldn't provide any scrollbars.
I said you wouldn't be able to access the top of the table
using those scrollbars.

But I made a little test:
http://www.mediatech.nl/~rachel/temp-test/testDU.html
And indeed, no scrollbars at all in Firefox, and unusable
ones in Opera 7.23.
IE at least lets the bottom half of the table get accessed
by the scrollbar.

>
> Nested tables are definitively NOT a solution; it's a worse solution.
>
> Assuming this code:
>
> #idTable
> {
> position: fixed;
> top: 50%;
> margin-top: -125px;
> height: 250px;
> }
>
> (...)
>
> <table id="idTable" ...>
>
> then it should work perfectly in Mozilla 1.3+ and in Opera 7.x.

Except for not being able to access part of the table in
smaller windows. :-D

--
Els

Mente humana é como pára-quedas; funciona melhor aberta.

Lauri Raittila

2004-02-19, 2:30 pm

In article john T wrote:
> Is there anyway to vertically center a html table using css in such a
> way it does not alter the html table. When I tryied it just screws up.

Very important question is where your table is. There is lots of ways to
vertically center things in CSS. None of them works well.

Ways to vertically center something in some defined container:
http://www.student.oulu.fi/~laurirai/www/css/middle/

AFAIK there is no good reference on centering on viewport (and I have no
time to write one). There is even more methods to do that
(position:fixed). None work on IE. I would try absolute/fixed positioning
with auto margins, it don't work on IE, but propably degrades well.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

2004-02-21, 2:29 pm

Els wrote:

> DU wrote:
>
>
>
> The OP didn't state it had to be in the middle of the browser viewport,
> neithe did I.

Then I do not understand why one would want to remove a table from
normal flow and then center that table in the middle of the document. It
does not make sense. Can you provide me with an example of demonstrating
the usefulness that I fail to see?

>
>
>
> I didn't say it wouldn't provide any scrollbars.
> I said you wouldn't be able to access the top of the table using those
> scrollbars.
>
> But I made a little test:
> http://www.mediatech.nl/~rachel/temp-test/testDU.html
> And indeed, no scrollbars at all in Firefox, and unusable ones in Opera
> 7.23.
> IE at least lets the bottom half of the table get accessed by the
> scrollbar.
>

You really should not mention MSIE on this: MSIE has many specs
violation, bugs and flaws regarding their implementation of root element
versus I.C.B. and versus the viewport.

I examined your testDU.html page and I think that page has many problems:

- there is absolutely nothing beside the fixed table in that document.
Now, if you fixed an element in a document, it is because you want such
element to be fixed in the viewport while you're scrolling the rest of
your document. Here, there is nothing to scroll for: that does not make
sense.
- The content of that fixed table is enormous and very long. If you make
any fixed element bigger than the viewport, then you are defeating the
purpose of fixing such element to begin with. A fixed element should
take, use a part of the browser viewport, not exceed it. Now, if your
fixed element is very large *and* very long, then you should examine the
usability and purpose of your webpage.
- You even made sure the font-size would be 40% bigger than normal for
no reason here.
- There is no tabular data in that table. The whole content goes into a
single cell.
For several reasons, your demopage is not realistic.

>
>
> Except for not being able to access part of the table in smaller
> windows. :-D
>

How small should the window be regarding the document to be scrolled? If
the window is 200px by 200px (or 300px by 300px), it sure is small: such
dimensions are not realistic for testing an element which is fixed.

Here is are 2 fine webpages with a fixed element (the first one uses a
table if I'm not wrong):

http://mozillanews.org/ (click the yellow padlock)

http://www.texturizer.net/firefox/index.html (choose a style at the end
of the page)

Finally, here's one of mine in the post-scriptum.

DU
-----------

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html lang="en">

<head profile="http://www.ietf.org/rfc/rfc2731.txt">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Content-Language" content="en">
<meta http-equiv="Content-Style-Type" content="text/css">
<meta name="DC.title" content="Vertically centering a table">
<meta name="DC.date.created" content="2004-02-21T09:54:03+11:00"
scheme="W3CDTF">
<meta name="DC.date.modified" content="2004-02-21T09:54:03+11:00"
scheme="W3CDTF">

<title>Vertically centering a table</title>

<style type="text/css" media="screen,tv,projection">
#idTable
{
position:fixed;
width:200px;
height:300px;
top:50%;
margin-top:-150px;
}
#idContent {margin-left:220px; padding:8px; border:2px solid green;}

</style>

</head>

<body>

<h1>Descriptive page title</h1>

<table id="idTable" frame="border" rules="all" summary="Weather
predictions for snow for next week" cellpadding="8">
<tr><th>Date</th><th>Value</th></tr>
<tr><td>Feb. 23rd</td><td>5cm</td></tr>
<tr><td>Feb 24th</td><td>0cm</td></tr>
<tr><td>Feb 25th</td><td>4cm</td></tr>
<tr><td>Feb 26th</td><td>3cm</td></tr>
<tr><td>Feb 27th</td><td>8cm</td></tr>
<tr><td>Feb 28th</td><td>2cm</td></tr>
</table>

<div id="idContent">
Some fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome filling
Some fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome filling
Some fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome filling
Some fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome filling
Some fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome fillingSome fillingSome
fillingSome filling
</div>

<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401.png" style="width:88px;
height:31px;" title="Verify this page compliance to the strict
definition of HTML 4.01" alt="HTML 4.01 Strict DTD compliant"></a>

</body></html>

Els

2004-02-21, 2:29 pm

DU wrote:

> Els wrote:
>
>
> Then I do not understand why one would want to remove a table from
> normal flow and then center that table in the middle of the document. It
> does not make sense. Can you provide me with an example of demonstrating
> the usefulness that I fail to see?

I don't think I was talking about usefulness. I was saying
that the negative margin has really bad side effects, which
are reason enough not to use that method.

>
> You really should not mention MSIE on this: MSIE has many specs
> violation, bugs and flaws regarding their implementation of root element
> versus I.C.B. and versus the viewport.

:-D
I know IE is buggy, but I mention MSIE when I want to;
especially when it does something different than other
browsers, I think it's worth mentioning. After all, most
people want the same results in most browsers.

> I examined your testDU.html page and I think that page has many problems:

I agree. I should have made a better one.

> - there is absolutely nothing beside the fixed table in that document.

Because it is a test page.

> Now, if you fixed an element in a document, it is because you want such
> element to be fixed in the viewport while you're scrolling the rest of
> your document.

Not necessarily, I may want it fixed in the document.

> Here, there is nothing to scroll for: that does not make
> sense.
> - The content of that fixed table is enormous and very long. If you make
> any fixed element bigger than the viewport, then you are defeating the
> purpose of fixing such element to begin with. A fixed element should
> take, use a part of the browser viewport, not exceed it. Now, if your
> fixed element is very large *and* very long, then you should examine the
> usability and purpose of your webpage.
> - You even made sure the font-size would be 40% bigger than normal for
> no reason here.

The reason is, that it's a test page, and I just wanted to
make sure you don't have to resize your window to 100px wide
to see the effect of not being able to reach the content.

> - There is no tabular data in that table. The whole content goes into a
> single cell.
> For several reasons, your demopage is not realistic.

I'll remember next time I make a demo page for you, I'll
make it as realistic as possible. However, that may clutter
up the code too much for other people to easily see why and
where things go wrong.

>
> How small should the window be regarding the document to be scrolled? If
> the window is 200px by 200px (or 300px by 300px), it sure is small: such
> dimensions are not realistic for testing an element which is fixed.

Unless you're on a pda.
Webcontent doesn't have to be laid out perfectly for all
browsing environments, but sure has to be within reach. If
it's off the screen, I feel the designer failed.

> Here is are 2 fine webpages with a fixed element (the first one uses a
> table if I'm not wrong):
>
> http://mozillanews.org/ (click the yellow padlock)

Too much code to see if it uses negative margin. But I see
no reason why they should, so what's the example for?
Clicking the yellow padlock only makes the menu scroll
seperately from the content of the page.

> http://www.texturizer.net/firefox/index.html (choose a style at the end
> of the page)

Excellent example. Try reaching the content of the menu on a
800x600 screen, using the style 'Modern with Locked Menu'.
I can't reach anything below 'Links'. Scrollbar doesn't go
there. Luckily, I can choose the style, and this way avoid
the problem.

> Finally, here's one of mine in the post-scriptum.
>
> DU
> -----------
[snip code]
I just copied and pasted that code and uploaded it:
http://home.tiscali.nl/~elizabeth/examplebyDU.html
I don't see a vertically centered table, but I do see
something fixed in the top left corner, which has lost it's
top line 'Weather predictions for snow for next week' in
Netscape, and also the next 'Date' and 'Value' in IE.

These examples show better what I meant to say than mine did
:-)

--
Els

Mente humana é como pára-quedas; funciona melhor aberta.

2004-02-21, 4:29 pm

Els wrote:

> DU wrote:
>
>
>
> I don't think I was talking about usefulness. I was saying that the
> negative margin has really bad side effects, which are reason enough not
> to use that method.

Well, if it's true that it has bad side effects, it had to affect some
real webpage situation.

>
>
>
> :-D
> I know IE is buggy, but I mention MSIE when I want to; especially when
> it does something different than other browsers, I think it's worth
> mentioning. After all, most people want the same results in most browsers.
>

Of course. Agreed. But then, you will not be able to apply the same
code. And you'll have to point out that you may be coding according to a
bug in MSIE if that's the case.

>
>
> I agree. I should have made a better one.
>
>
>
> Because it is a test page.
>

So?

>
>
> Not necessarily, I may want it fixed in the document.
>

If there is nothing to scroll in a document, then there is no point for
fixing an element. If you need to reduce a browser viewport to
unrealistic dimensions to highlight a "bug", then I'm not sure this is a
bug after all.

>
>
> The reason is, that it's a test page, and I just wanted to make sure you
> don't have to resize your window to 100px wide to see the effect of not
> being able to reach the content.
>
>
>
> I'll remember next time I make a demo page for you, I'll make it as
> realistic as possible. However, that may clutter up the code too much
> for other people to easily see why and where things go wrong.
>

I did a page which was realistic, where all elements involved in our
discussion were there. The whole code was posted in my previous post:
tabular data, fixed table, content, document scroll view, etc.

>
>
> Unless you're on a pda.

The style code said
media="screen,tv,projection"
not handheld.

> Webcontent doesn't have to be laid out perfectly for all browsing
> environments, but sure has to be within reach. If it's off the screen, I
> feel the designer failed.
>

This might be debatable: I certainly did not want that file to be for
small rendering screen devices.

>
>
> Too much code to see if it uses negative margin. But I see no reason why
> they should, so what's the example for?

That example was for showing a realistic webpage situation where a table
can be fixed into the viewport.

> Clicking the yellow padlock only makes the menu scroll seperately from
> the content of the page.
>
>
>
> Excellent example. Try reaching the content of the menu on a 800x600
> screen, using the style 'Modern with Locked Menu'.
> I can't reach anything below 'Links'. Scrollbar doesn't go there.
> Luckily, I can choose the style, and this way avoid the problem.
>
>
> [snip code]
> I just copied and pasted that code and uploaded it:
> http://home.tiscali.nl/~elizabeth/examplebyDU.html
> I don't see a vertically centered table, but I do see something fixed in
> the top left corner, which has lost it's top line 'Weather predictions
> for snow for next week' in Netscape,

I see what you mean. NS 7.1 does not correctly position that table.
[Btw, the "Weather predictions for snow for next week" is just a summary
for text browsers and non-visual user agents. It's not supposed to be
rendered in visual browsers.]
I do see the table vertically centered in the viewport when viewing that
page with Mozilla 1.6 final (build 20040113); no problem with resizing.
I see more problems with K-meleon 0.8.2 (using Mozilla 1.5 codebase) as
the table is more off the viewport.
I see other problems when resizing the viewport under Opera 7.50 PR 2.

and also the next 'Date' and
> 'Value' in IE.
>
> These examples show better what I meant to say than mine did :-)
>

Obviously there are bugs somewhere in these browsers and browser
versions. I also have other test pages for pos. fixed. I'll look at this
again.

Later :)

DU

Els

2004-02-21, 5:29 pm

DU wrote:

> Of course. Agreed. But then, you will not be able to apply the same
> code. And you'll have to point out that you may be coding according to a
> bug in MSIE if that's the case.

> If there is nothing to scroll in a document, then there is no point for
> fixing an element. If you need to reduce a browser viewport to
> unrealistic dimensions to highlight a "bug", then I'm not sure this is a
> bug after all.

Well, actually, I personally don't see it as a bug.
I'd say, if I want to give something an absolute position of
let's say, 20px from the top, and then give it a negative
margin of 40px, I shouldn't be surprised if it goes off the
screen. After all, the specs are clear: position:absolute
lifts an element from it's place in the normal flow, and
places it wherever you put it. If that's off the screen, who
am I to blame the browser?

--
Els

Mente humana é como pára-quedas; funciona melhor aberta.