Els wrote:
[color=blue]
> DU wrote:
>[color=green]
>> Els wrote:
>>[color=darkred]
>>> DU wrote:
>>>
>>>> Els wrote:
>>>>
>>>>> 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.
>>>>
>>>>
>>>> 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.[/color]
>>
>>
>> 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?[/color]
>
>
> 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.[/color]
Well, if it's true that it has bad side effects, it had to affect some
real webpage situation.
[color=blue]
>[color=green][color=darkred]
>>>> 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.[/color]
>>
>>
>> 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.[/color]
>
>
> :-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.
>[/color]
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.
[color=blue][color=green]
>> I examined your testDU.html page and I think that page has many problems:[/color]
>
>
> I agree. I should have made a better one.
>[color=green]
>> - there is absolutely nothing beside the fixed table in that document.[/color]
>
>
> Because it is a test page.
>[/color]
So?
[color=blue][color=green]
>> 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.[/color]
>
>
> Not necessarily, I may want it fixed in the document.
>[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
>
> 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.
>[color=green]
>> - There is no tabular data in that table. The whole content goes into
>> a single cell.
>> For several reasons, your demopage is not realistic.[/color]
>
>
> 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.
>[/color]
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.
[color=blue][color=green][color=darkred]
>>>> 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[/color]
>>
>>
>> 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.[/color]
>
>
> Unless you're on a pda.[/color]
The style code said
media="screen,tv,projection"
not handheld.
[color=blue]
> 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.
>[/color]
This might be debatable: I certainly did not want that file to be for
small rendering screen devices.
[color=blue][color=green]
>> 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)[/color]
>
>
> Too much code to see if it uses negative margin. But I see no reason why
> they should, so what's the example for?[/color]
That example was for showing a realistic webpage situation where a table
can be fixed into the viewport.
[color=blue]
> Clicking the yellow padlock only makes the menu scroll seperately from
> the content of the page.
>[color=green]
>>
http://www.texturizer.net/firefox/index.html (choose a style at the
>> end of the page)[/color]
>
>
> 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.
>[color=green]
>> Finally, here's one of mine in the post-scriptum.
>>
>> DU
>> -----------[/color]
>
> [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,[/color]
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[color=blue]
> 'Value' in IE.
>
> These examples show better what I meant to say than mine did :-)
>[/color]
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