Variable length scrolling <div> or <iframe>?

[Jim M]

I have had great success with using <iframe> with overflow-y set to auto. I
can get a similar look with the <iframe> tag.

BUT... In all cases I need to have fixed heights. Is there a way to put
either tag inside an HTML <TD> and have the same kind of scrolling effect.

This would allow me to fill the screen and have the size of the scrolling
box change on resize.

Thanks in advance.

Jim

 

[Chris Barber]

<table height="100%" width="100%" cellspacing="0" cellpadding="0">
<tr>
<td>
<div style="width: 100%; height: 100%; overflow: auto; border:
1px solid red">
A div with text in it that will stat at 100% of the holding block element
size and also allow scrolling for off screen content.
A div with text in it that will stat at 100% of the holding block element
size and also allow scrolling for off screen content.
A div with text in it that will stat at 100% of the holding block element
size and also allow scrolling for off screen content.
A div with text in it that will stat at 100% of the holding block element
size and also allow scrolling for off screen content. </div>
</td>
</tr>
</table>

Border added for effect.

Chris.

I have had great success with using <iframe> with overflow-y set to auto. I
can get a similar look with the <iframe> tag.

BUT... In all cases I need to have fixed heights. Is there a way to put
either tag inside an HTML <TD> and have the same kind of scrolling effect.

This would allow me to fill the screen and have the size of the scrolling
box change on resize.

Thanks in advance.

Jim

 

[Armin Zingler]

I have had great success with using <iframe> with overflow-y set to
auto. I can get a similar look with the <iframe> tag.

BUT... In all cases I need to have fixed heights. Is there a way to
put either tag inside an HTML <TD> and have the same kind of
scrolling effect.

This would allow me to fill the screen and have the size of the
scrolling box change on resize.

I don't know what you mean. I think it is not a VB.NET language related
question.

 

[Allard]

<table height="100%" width="100%" cellspacing="0" cellpadding="0">
<tr>
<td>
<div style="width: 100%; height: 100%; overflow: auto;
border:
1px solid red">
A div with text in it that will stat at 100% of the holding block
element size and also allow scrolling for off screen content.
A div with text in it that will stat at 100% of the holding block
element size and also allow scrolling for off screen content.
A div with text in it that will stat at 100% of the holding block
element size and also allow scrolling for off screen content.
A div with text in it that will stat at 100% of the holding block
element size and also allow scrolling for off screen content.
</div>
</td>
</tr>
</table>

Border added for effect.

This only works in IE, but not in Mozilla browsers. (in mozilla the
scrollbar never appears, because the element with height:100% seems to
grow automatically.)

Anyone knows how to do this in a uniform way?

Allie

 

[Chris Barber]

Brilliant

I am beginning to despair with HTML and browser specific implementations.

Chris.


<snipped/>

This only works in IE, but not in Mozilla browsers. (in mozilla the
scrollbar never appears, because the element with height:100% seems to
grow automatically.)

Anyone knows how to do this in a uniform way?

Allie

 

[Dave Anderson]

Brilliant

I am beginning to despair with HTML and browser specific
implementations.

First of all, it's a style issue, not an HTML one**. And this seems worthy
of mention:

"CSS1 core: UAs may ignore the 'height' property (i.e.,
treat it as 'auto') if the element is not a replaced
element."
http://www.w3.org/TR/CSS1#height

Since a DIV is not a replaced element, I don't see how you can reasonably
expect uniformity.

And that's just as well. Consider what the W3C says about style sheets:

"By attaching style sheets to structured documents on the
Web (e.g. HTML), authors and readers can influence the
presentation of documents without sacrificing device-
independence or adding new HTML tags."
http://www.w3.org/Style/

To me, the key word in that passage is INFLUENCE. I wouldn't get too worked
up about standards-compliant discrepancies between implementations. This is
a technology that should be *embraced* for its flexibility, not cursed.


**Even if you want to consider the HTML HEIGHT attribute on your table, you
have a problem. For one thing, the TABLE element has none. And for cells,
it's deprecated:
http://www.w3.org/TR/1998/REC-html40-19980424/struct/tables.html#edef-TABLE
http://www.w3.org/TR/1998/REC-html40-19980424/struct/tables.html#adef-height-TH

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Allard]

First of all, it's a style issue, not an HTML one**. And this seems
worthy of mention:

"CSS1 core: UAs may ignore the 'height' property (i.e.,
treat it as 'auto') if the element is not a replaced
element."
http://www.w3.org/TR/CSS1#height

Since a DIV is not a replaced element, I don't see how you can
reasonably expect uniformity.

And that's just as well. Consider what the W3C says about style
sheets:

"By attaching style sheets to structured documents on the
Web (e.g. HTML), authors and readers can influence the
presentation of documents without sacrificing device-
independence or adding new HTML tags."
http://www.w3.org/Style/

To me, the key word in that passage is INFLUENCE. I wouldn't get too
worked up about standards-compliant discrepancies between
implementations. This is a technology that should be *embraced* for
its flexibility, not cursed.


**Even if you want to consider the HTML HEIGHT attribute on your
table, you have a problem. For one thing, the TABLE element has none.
And for cells, it's deprecated:
http://www.w3.org/TR/1998/REC-html40-19980424/struct/tables.html#edef- T
h
eight-TH

That's all great, but how to do what we want then?

 

[Dave Anderson]

That's all great, but how to do what we want then?

By "do what we want", do you mean "force the browser to display exactly as
we desire"? If so, abandon that notion. You cannot reasonably expect the UA
to even support styles, as some people turn them off (for accessibility or
other reasons). Ditto for scripting.

Consider the MSDN JScript Language Reference:
http://msdn.microsoft.com/library/en-us/script56/html/js56jslrfjscriptlanguagereference.asp

When viewed in IE, the tree can be navigated without page reloads. When
viewed in Mozilla, the tree navigation, while still possible, requires that
the whole frameset reload. In Opera, there isn't even a frameset -- you see
only the content pages, but no tree.

And although site look and navigation is different for each browser, the
core purpose of the JScript reference is still served. Isn't that the
important thing?


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Allard]

By "do what we want", do you mean "force the browser to display
exactly as we desire"? If so, abandon that notion. You cannot
reasonably expect the UA to even support styles, as some people turn
them off (for accessibility or other reasons). Ditto for scripting.

Consider the MSDN JScript Language Reference:
http://msdn.microsoft.com/library/en- us/script56/html/js56jslrfjscriptl
anguagereference.asp

When viewed in IE, the tree can be navigated without page reloads.
When viewed in Mozilla, the tree navigation, while still possible,
requires that the whole frameset reload. In Opera, there isn't even a
frameset -- you see only the content pages, but no tree.

And although site look and navigation is different for each browser,
the core purpose of the JScript reference is still served. Isn't that
the important thing?

Correct, that is a nice example of browser specific implementations. For
example, in Mozilla the handling (and code) is different than for a IE
browser. I am sure they spent a lot of effort to make this in a uniform
way.

But the problem here is that we want to display something in the browser
that does not seem to be possible: if you have a table with two rows,
the first row is of fixed height, the second row should fill up the rest
of the screen. The content displayed in the second row should
automatically show scrollbars to be able to display all. The first row
should never scroll off screen. This in contrast of a big part of the
internet, where navigation buttons are scrolled off screen, which is
terribly ugly and user unfriendly. You must first scroll to navigate to
another page!?!?

Using the same approach as the example you gave, we could make a
different implementation for Mozilla browsers (using a frameset or so),
but of course this is not very easy to maintain.

Instead, how to display something like this on both browsers using HTML
and CSS?

The funny thing is that although IE might be inconsistent with the
specifications, it looks like it's the only browser that is capable of
showing user interfaces like the example earlier in this thread.

Appreciate your help,
Allie

 

[Dave Anderson]

Using the same approach as the example you gave, we could
make a different implementation for Mozilla browsers (using
a frameset or so), but of course this is not very easy to
maintain.

I intentionally chose an example that would highlight this point. I rigidly
oppose browser detection and the associated parallel development. But
choosing to write one version is necessarily a compromise. If I can't make
the application look and feel *exactly* the way I want to, then so be it.
Content is king, not design.

Instead, how to display something like this on both browsers
using HTML and CSS?

If you are so bound to the "full-window" model that you cannot budge, you
can always accomplish it with frames:

The funny thing is that although IE might be inconsistent with
the specifications, it looks like it's the only browser that
is capable of showing user interfaces like the example earlier
in this thread.

It's the only browser you TESTED that does what you want within your a
priori established boundaries (no frames, for example).



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Allard]

so....

according to the CSS specs, there is no general solution to do it with a
single HTML page? (if so, that would make me highly unsatisfied...)

A fullscreen solution indeed has my (and many ordinary users)
preference. In fact, only Internet websites have this browsing dilemma,
normal applications never have scrolling full screens. (I believe)

A frameset is possible, but would use multiple html pages, which is a
more difficult environment for scripts. What if I have a clientside
class that generated the HTML code, then I would need to put this code
in two frames, AND set the stylesheets in each frame.

I like your statement "content is kind, not design"... but in my opinion
it's not the way it should be... You should as a developer always be
able to show the content in a way you want, by simply defining the view.
If the view is the second row in a table like I described, then so be
it. That it will not be displayed 100% exactly the way you defined it on
every browser, ok, I can live with that, but at least a little bit close
would already be great...



Allie

 

[Jim M]

Thanks for all the details, looks like I can try it tonight.

 

[Jim M]

I did want to add a few header title rows to your example. Thanks for the
example.

Is it correct to assume that there is no way to have 100px of header, and
then a scrolling <div> tag taking up "100% - 100px". It think this is the
root of my original question.

Or is there some way to set the <div> tag to be height = 100% or the size of
the <TD> container?

I am assuming there is no way based on ...

But the problem here is that we want to display something in the browser
that does not seem to be possible: if you have a table with two rows,
the first row is of fixed height, the second row should fill up the rest
of the screen. The content displayed in the second row should
automatically show scrollbars to be able to display all. The first row
should never scroll off screen. This in contrast of a big part of the
internet, where navigation buttons are scrolled off screen, which is
terribly ugly and user unfriendly. You must first scroll to navigate to
another page!?!?

 

[Chris Barber]

OK,

I'll be the first to admit that I'm not an expert web designer / developer
but I have produced web 'applications' for intranet and internet where the
vagaries of different browser (whether or not they are HTML / CSS compliant)
becomes a minefield that can produce very strange and worrying effects. I
had
at least one instance on a MAC where the page returned as a complete blank
with full source still visible (eg. View Source).

I don't even know what a 'replaced' element is and certainly I don't have
the time, energy, or inclination to go and check every usage on an HTML
element, attribute or CSS application whether it be a stylesheet or style
attribute.

Now, please don;t get me wrong, I'm not ranting, nor am I flaming your
response. I'm merely trying to show the level of frustration that
accompanies any form of web based development no matter how experienced one
might be. I'd probably put myself across as an 'Advanced' web developer
given that I've successfully done DHTML, XSLT,. XML, Javascript, and fairly
complex layouts with attendant CSS. However, it still pi**es me off when my
best efforts turn out to be garbage on anything other than IE 5.5+ or
Mozilla (I *like* Mozilla a lot). Certainly trying to get anything even
remotely complex or interactive to work
with Netscape or the Mac (Safari) is almost impossible.

Regards,

Chris.

Brilliant

I am beginning to despair with HTML and browser specific
implementations.

First of all, it's a style issue, not an HTML one**. And this seems worthy
of mention:

"CSS1 core: UAs may ignore the 'height' property (i.e.,
treat it as 'auto') if the element is not a replaced
element."
http://www.w3.org/TR/CSS1#height

Since a DIV is not a replaced element, I don't see how you can reasonably
expect uniformity.

And that's just as well. Consider what the W3C says about style sheets:

"By attaching style sheets to structured documents on the
Web (e.g. HTML), authors and readers can influence the
presentation of documents without sacrificing device-
independence or adding new HTML tags."
http://www.w3.org/Style/

To me, the key word in that passage is INFLUENCE. I wouldn't get too worked
up about standards-compliant discrepancies between implementations. This is
a technology that should be *embraced* for its flexibility, not cursed.


**Even if you want to consider the HTML HEIGHT attribute on your table, you
have a problem. For one thing, the TABLE element has none. And for cells,
it's deprecated:
http://www.w3.org/TR/1998/REC-html40-19980424/struct/tables.html#edef-TABLE
http://www.w3.org/TR/1998/REC-html40-19980424/struct/tables.html#adef-height-TH

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Allard]

I can seen nothing else than: " I totally agree..."

I am still curious though to know what the h*ll a replaced element is ....


Allie

 

[Chris Barber]

Ahh ...

<quote>
Replaced element
An element for which the CSS formatter knows only the intrinsic dimensions.
In HTML, IMG, INPUT, TEXTAREA, SELECT, and OBJECT elements can be examples
of replaced elements. For example, the content of the IMG element is often
replaced by the image that the "src" attribute designates. CSS does not
define how the intrinsic dimensions are found.
</quote>

Found that in:

http://tinyurl.com/23snc

Chris.

I can seen nothing else than: " I totally agree..."

I am still curious though to know what the h*ll a replaced element is ....


Allie

 

[Dave Anderson]

I had at least one instance on a MAC where the page
returned as a complete blank with full source still
visible (eg. View Source).

My experience with Mac browsers has been somewhat limited for the last three
years, though I used one quite extensively until 2001. And on the occasions
when the above occurred, I was inevitably able to trace the problem to tags
that were opened but never closed (especially TABLE tags). But that is not
to say you never had this happen with valid HTML. I obviously could not know
that.

...it still pi**es me off when my best efforts turn out
to be garbage on anything other than IE 5.5+ or Mozilla
(I *like* Mozilla a lot).

But it isn't that difficult to identify subsets of HTML/DOM/CSS that are
implemented fairly uniformly. And once you identify the land mines, your
future development efforts are greatly simplified (if somewhat limited in
flexibility).

If you have the luxury of setting the bar, things are also greatly
simplified. This is obviously harder to do for public sites, but on our
intrant, for example, we are able to be picky. We code to HTML4, DOM1 (and
some of 2), CSS1 (and some of 2), and full ECMA-262v3 as minima. This
approach does not especially limit our developers OR our users.

Our public web site is another matter. For that, I share your pain, though
my philosophic approach is somewhat minimalist**. I would not try to fill
the window, for example, because I don't believe it is important.

Just don't get me started on vendor-supplied applications that work in only
specific browsers with specific JVMs. Some of our departments are big enough
and isolated enough to think they can purchase web applications without
consulting the development groups or without causing conflicts. And while
this approach is fine for many users, it can force very specific software
versions (browser or plug-in) onto our Citrix systems, which almost always
leads to problems with other vendor-supplied web applications.

Certainly trying to get
anything even remotely complex or interactive to work
with Netscape or the Mac (Safari) is almost impossible.

That depends on your bias toward DHTML and against round-trips.


**Simple HTML, simple CSS. I lean toward round-trips and away from DHTML.
Though I am capable of nuanced and attractive design, I have access to a
marketing team with highly skilled artists -- and they are far more willing
than I to "uglify" the source code by using such tools as Dreamweaver. I try
not to think about what they do to the *valid* HTML I hand them.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Allard]

Our public web site is another matter. For that, I share your pain,
though my philosophic approach is somewhat minimalist**. I would not
try to fill the window, for example, because I don't believe it is
important.

I have seen too many sites where clicking on a link refreshes the whole
screen, reloading all navigation buttons/links again that were already
there. I have seen too many pages where you must scroll to the top of
the page (after reading to the bottom) to go to another page. I have
seen too many flashy screens (aspx), that refreshes a whole document,
when only a little thing changes on the screen. I have spent too much
time waiting for a page to reload, when it could have been twice as fast
because all that redundant information didn't need to be transferred
again...

This is only an attempt to make an improvement, to make better user
interfaces, and yes, I do think this is very important. Many Internet
websites simply look too primitive, and could be improved (a lot!) by
offering such a interface that fills the window.

Allie

 

[Dave Anderson]

I have seen too many sites where clicking on a link refreshes
the whole screen, reloading all navigation buttons/links again
that were already there. I have seen too many pages where you
must scroll to the top of the page (after reading to the bottom)
to go to another page. I have seen too many flashy screens
(aspx), that refreshes a whole document, when only a little
thing changes on the screen. I have spent too much time waiting
for a page to reload, when it could have been twice as fast
because all that redundant information didn't need to be
transferred again...

None of these issues represents fallout of minimalist design. What exactly
is the point here?

I note, by the way, that each of the above problems can be diminished
through the use of FRAMEs or IFRAMEs, not to mention making forms that are
"wizard-like" rather than all-inclusive.

This is only an attempt to make an improvement, to make better
user interfaces, and yes, I do think this is very important.
Many Internet websites simply look too primitive, and could be
improved (a lot!) by offering such a interface that fills the
window.

Why would filling a screen improve an interface? Would the Windows
Calculator (calc.exe) be a better application if you could maximize its
window? You are proposing to do essentially the same thing. If the
form/app/page has enough content to fill the screen, then it will. Why force
it to if it doesn't have to?


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Jim M]

The purpose of the original post was for a weekly calendar, ie.. this would
take 7 <iframes>, 7 hits to the server. Next, I will go after a monthly
calendar with scrolling days... 31 <iframes>. The problem is that a large
screen is a great advantage when looking at a monthly calendar. It seems so
silly to be stuck with fixed sized days in my calendar to get scrolling.

I do not think it is unusual of late for business applications to require IE
to run in order to get functionality. In these very challenging times,
many users would rather pay less and get a good GUI and accept the
limitation of having to run in IE only. The alternative is to pay more in
development costs or get less in GUI.

Just some thoughts from another late night programmer.