Layout: Full-screen table w/ scrollable content? Cross-browser problems...

[Matt Kruse]

This is a typical layout, but I have specific requirements. I'm trying to
figure out a) if it's possible to meet the requirements and b) if so, how.

+---------------+
| header |
+---------------+
| body |
| (scrollable) |
+---------------+
| footer |
+---------------+

I want a static header, static footer, and scrollable content inbetween.
Requirements:
* Content must be scrollable in IE6/Win. That is, a valid solution
_must_ include static header/footer and scrollable content for IE6.
* For any other browsers, the content should either be scrollable as
with IE6, or the entire table should expand and the whole page should be
scrollable (including back to NN4). Either way, whatever works.
* Must not cause any display problems in IE5.5/Mac

If IE6 support wasn't required, I could use overflow:auto on a tbody or even
on the content td itself. Most solutions I come up with work in almost all
browsers, but fail in one or two. Specifically, this version fails in NN6:
http://www.mattkruse.com/temp/scroll_content.html

Can anyone suggest a technique which will meet all the requirements? Or say
that it is absolutely not possible to meet all the requirements?

(Using pure CSS layout doesn't degrade nicely enough to look correctly in
older browsers... unless some of you who know more about css can do it that
way, then feel free to show me ;)

Thanks

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

I want a static header, static footer, and scrollable content
inbetween. Requirements:
* Content must be scrollable in IE6/Win. That is, a valid solution
_must_ include static header/footer and scrollable content for IE6.
That's almost a non-starter. IE/Win does not support position: fixed.
You can work around it, but the kludge is ugly.

More importantly, this is not usually desirable in a context where you
don't know the display resolutions. To remove space at the top *and*
bottom of the viewport can leave very little space for scrollable
content. The obvious answer is to "stop wanting that." Why is this
particular presentation required?
* For any other browsers, the content should either be scrollable
as with IE6, or the entire table should expand and the whole page
should be scrollable (including back to NN4). Either way, whatever
works.
NN4's css support is very broken. But it is a capable HTML browser in
many circumstances. If you have no unusual demands (e.g., non-western
character repertoire), then be nice and hide that which it cannot
handle, i.e., css. Plain HTML may be a bit ugly, but it does "work"
and will be scrollable as necessary.
* Must not cause any display problems in IE5.5/Mac
IE/Mac was quite good for its time, but it's been overshadowed by
newcomers like Safari. It has its own problems with fixed positioning.
Fortunately, it is trivial to hide only those rules it cannot handle
via @media rules.
If IE6 support wasn't required, I could use overflow:auto on a
tbody or even on the content td itself.
This is only for <table>? Or are you using <table> for layout?
Most solutions I come up with work in almost all browsers, but fail
in one or two. Specifically, this version fails in NN6:
NN6 was quite impressive, but, in retrospect, it was released too
soon. There were some bugs that should have been released. What
problems are you having?
http://www.mattkruse.com/temp/scroll_content.html

Can anyone suggest a technique which will meet all the
requirements? Or say that it is absolutely not possible to meet all
the requirements?

It is probably not possible to meet your requirements. You need to let
go a little, and be willing to accept that browsers have different
abilities, and thus will render your documents differently.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Matt Kruse]

Brian wrote:

* Content must be scrollable in IE6/Win. That is, a valid solution
_must_ include static header/footer and scrollable content for IE6. That's almost a non-starter. IE/Win does not support position: fixed.
You can work around it, but the kludge is ugly.

My example URL works fine in IE6, though.
I'm using tables for layout, not pure CSS (because I couldn't find a pure
css solution which met the requirements)
More importantly, this is not usually desirable in a context where you
don't know the display resolutions. To remove space at the top *and*
bottom of the viewport can leave very little space for scrollable
content. The obvious answer is to "stop wanting that." Why is this
particular presentation required?
Since the top and bottom will be relatively small in size, it won't be much
of an issue. And in the context where this will be used, it won't be an
issue anyway. Just trust me on that one. ;)
This is only for <table>? Or are you using <table> for layout?
I'm using one big table for the layout, because I couldn't come close to
meeting the requirements with pure css.
NN6 was quite impressive, but, in retrospect, it was released too
soon. There were some bugs that should have been released. What
problems are you having?

http://www.mattkruse.com/temp/scroll_content.html

The example URL, in NN6, doesn't display the content at all.
I hate NN6. It's horrible. All NN6 users should have their computers die!
It is probably not possible to meet your requirements.
That might be true, but I'll wait to see what others might say... Since my
example solution only fails in NN6 (of the browsers I've tested) it seems
like it's awfully close.
You need to let go a little, and be willing to accept that browsers have different abilities, and thus will render your documents differently.

I've been working with HTML for over 10 years, so I'm quite familiar with
the general concepts of web design :)

I just get frustrated with CSS sometimes... so good in theory, but in
practice in often presents many compatability issues!

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

Brian wrote:

* Content must be scrollable in IE6/Win. That is, a valid
solution _must_ include static header/footer and scrollable
content for IE6.
That's almost a non-starter. IE/Win does not support position:
fixed. You can work around it, but the kludge is ugly.

My example URL works fine in IE6, though.

It does not work in Firefox 0.8/WinXP. There's no fixed section of page.
I'm using tables for layout
Which is more important, your content, or its presentation?
not pure CSS (because I couldn't find a pure css solution which met
the requirements)
The point is, why do those requirements exist?

http://www.mattkruse.com/temp/scroll_content.html

Have a look here: http://validator.w3.org/

You have no doc type declared, and your server does not send a charset
header.
The example URL, in NN6, doesn't display the content at all. I hate
NN6. It's horrible. All NN6 users should have their computers die!

On balance, it's better than any version of IE/Win. For one thing, it
respects the http protocol; for another, it does not screw up caching.
(See ciwa.site-design for a new thread on IE/Win and caching.)

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Matt Kruse]

Brian wrote:

My example URL works fine in IE6, though. It does not work in Firefox 0.8/WinXP. There's no fixed section of
page.

It works fine for me in that it displays the entire content as one big
table, with the entire body scrollable. Which meets the requirements.
Since 94% of the users will be using IE6 on Windows, having Firefox users
(if there are any) see the whole body as scrollable is no problem at all.

I'm using tables for layout

Which is more important, your content, or its presentation?

That's irrelevant.

not pure CSS (because I couldn't find a pure css solution which met
the requirements)

The point is, why do those requirements exist?

Again, irrelevant. I wasn't asking for a discussion on whether the
requirements were valid.
I asked a purely technical question.
Have a look here: http://validator.w3.org/
You have no doc type declared, and your server does not send a charset
header.

This was a simple _example_. Must you be so anal?
I know about doctypes, I know what they do and why to use them, and I know
how they affect browsers' display of html and css.
If adding a specific doctype would affect the presentation of the example
page, I would have added one.

The example URL, in NN6, doesn't display the content at all. I hate
NN6. It's horrible. All NN6 users should have their computers die!

On balance, it's better than any version of IE/Win. For one thing, it
respects the http protocol; for another, it does not screw up caching.
(See ciwa.site-design for a new thread on IE/Win and caching.)

No browser is perfect. And having a browser war would completely take this
thread off-topic from the original question.
Personally, I like IE but I prefer Firefox. And I despise NN6. *shrugs*

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

Brian wrote:

Since 94% of the users will be using IE6 on Windows,
94% precisely? You know that how?

Which is more important, your content, or its presentation?

That's irrelevant.

A telling response.
Again, irrelevant. I wasn't asking for a discussion on whether the
requirements were valid. I asked a purely technical question.
This is not your personal help desk.

You have no doc type declared, and your server does not send a
charset header.

This was a simple _example_. Must you be so anal?

Must you be so difficult? If you want help, the least you can do is
present a valid document.
*shrugs*

*shrugs* back.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Matt Kruse]

Brian wrote:

That's irrelevant.

A telling response.

I was just informing you that your questions are irrelevant, because I
already understand the background issues very well, and I'm not concerned
about addressing them here. With over a decade of web experience, I'm not
new to this. I'm smart enough to know what my real question is. You're being
obtuse by assuming I'm stupid and don't understand what I want or what I'm
doing.

Any issues such as browser share (for you to question the % of IE users
without even knowing the context of the application is being purely
argumentative on your part) or whether or not it's a valid way to do layout
have already been addressed by me. All too often, people without answers or
enough knowledge to address the real question instead direct their focus
towards picking apart the original question, trying to find something wrong
with it to invalidate it. To me, that's annoying and unproductive, so I
won't continue addressing your irrelevant nitpicking of the original
question.

If you do have an answer to the question, or wish to discuss issues related
to it, I'd welcome that.

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

All too often, people without answers or enough knowledge to
address the real question instead direct their focus towards
picking apart the original question, trying to find something wrong
with it to invalidate it.
All too often, authors want a quick fix, but don't want to meet us
half-way by validating their document.

http://diveintomark.org/archives/200..._wont_help_you
To me, that's annoying and unproductive, so I won't continue
addressing your irrelevant nitpicking of the original question.

That's super. Bye.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/