Drop down menu vs scrollable detail rows vs frames techniques

[Keimo Repo]

Hello

I would need some advice, even just speculations...

A customer of ours insists on a couple of customer specific design
features for our existing multi-customer web application:

- A top header with a dropdown menu which does not scroll when the page
is scrolled.
- A lower detail part of the screen (table) where the headers stay, and
the detail rows scroll. Or a detail part where the headers and the
details can be scrolled is also acceptable
- IE6 and Firefox. (I think IE5.5 should also work but this is not a
requirement).

Our requirements:
- No fixed scrollable area width or height, i.e. the browser size must
be dynamic
- No fixed td widths
- Must work (somehow) for all screen resolutions and all browser window
sizes
- We have only one version of source code, which can where necessary be
adjusted to different customers or browsers with effectively
if-statements in the code

I have not been able to find a feasible way to do this.

Problems:
- Tbody with overflow and height works for Firefox, not for IE, and
this solution would need a fixed height at least
- With frames I can scroll the whole lower part, but the dropdown
javascript menu does not show in both frames very easily. By copying
the JS-navi to both frames I can make it work, but I have a feeling it
may not work 100% of situations.
- I have found some scrollable tbody scripts for multiple browsers but
they all rely on at least fixed scrollable area height and/or fixed
td-widths
- With the table headers and table data in separate tables the columns
do not align unless I define fixed td-widths or at least fixed relative
td-widths
Can anyone suggest what I should do, or tell me what we are doing
wrong. What approach, or what kind of a compromise, should we take and
why? The heart of our system is identical for all customers, but the
visual front and the structure can easily be modified per customer -
until now. Until now we have had no frames and the whole page has
scrolled in the browser.

The application is dynamic and it is behind a login, so search engines
are not an issue.

Any thoughts appreciated. Thanks.

Keimo

[hug]

"Keimo Repo" <kk***@hotmail.com> wrote:

Hello

I would need some advice, even just speculations...

A customer of ours insists on a couple of customer specific design
features for our existing multi-customer web application:

- A top header with a dropdown menu which does not scroll when the page
is scrolled.
- A lower detail part of the screen (table) where the headers stay, and
the detail rows scroll. Or a detail part where the headers and the
details can be scrolled is also acceptable
- IE6 and Firefox. (I think IE5.5 should also work but this is not a
requirement).

Our requirements:
- No fixed scrollable area width or height, i.e. the browser size must
be dynamic
- No fixed td widths
- Must work (somehow) for all screen resolutions and all browser window
sizes
- We have only one version of source code, which can where necessary be
adjusted to different customers or browsers with effectively
if-statements in the code

I have not been able to find a feasible way to do this.

Problems:
- Tbody with overflow and height works for Firefox, not for IE, and
this solution would need a fixed height at least
- With frames I can scroll the whole lower part, but the dropdown
javascript menu does not show in both frames very easily. By copying
the JS-navi to both frames I can make it work, but I have a feeling it
may not work 100% of situations.
- I have found some scrollable tbody scripts for multiple browsers but
they all rely on at least fixed scrollable area height and/or fixed
td-widths
- With the table headers and table data in separate tables the columns
do not align unless I define fixed td-widths or at least fixed relative
td-widths
Can anyone suggest what I should do, or tell me what we are doing
wrong. What approach, or what kind of a compromise, should we take and
why? The heart of our system is identical for all customers, but the
visual front and the structure can easily be modified per customer -
until now. Until now we have had no frames and the whole page has
scrolled in the browser.

The application is dynamic and it is behind a login, so search engines
are not an issue.

Any thoughts appreciated. Thanks.

Keimo

When a customer demands that you do something against the way you
prefer to do things, you have reached a decision point. There are all
kinds of slick'n'fancy ways of doing things that are basically crap
for one reason or another... browser dependencies and download times
being high on that list. You can always "just say no" but there are
repercussions. Good luck, you're in a spot. I don't do frames, I
don't do javascript, I don't do cookies; my dropdowns are produced by
server-side code, and the data delivered is basic html that virtually
any broser can handle regardless of user preferences. Your customer
wants you to do something you don't want to do (probably for good
reasons), so it's time to choose between technical integrity and
money. Ugh, better thee than me.

--
http://www.ren-prod-inc.com/hug_soft...action=contact