Javascript problem in Firefox

[Karin Jensen]

Hi - I am trying to use Javascript to put material inside a table
(i.e. alongside the previous material) if the user's screensize is
big enough and outide the table (beneath table) if it isn't.

The following code (tag properties and other extraneous material
removed) works in IE but not Firefox:
<table>
<tr><td>
first set of material
</td>
<script language="text/javascript">
<!--
if ((screen.width>=1024) && (screen.height>=768))
{
document.write("<td>");
}
else
{
document.write("</tr></table>");
}
</script>
second set of material
<script language="text/javascript">
<!--
if ((screen.width>=1024) && (screen.height>=768))
{
document.write("</td></tr></table>");
}
</script>

If you "view source" in Firefox, you can see that it is treating
this as a single piece of script, with only the first opening script
tag and second closing script tag highlighted in purple.

Can anybody help?

Thanks!

Karin

P.S.
This is the effect it's meant to produce for high resolution
screens:
<table>
<tr><td>
first set of material goes here
</td>
<td>
second set of material goes here inside table
</td></tr></table>

And for low ones:
<table>
<tr><td>
first set of material goes here
</td>
</tr></table>
second set of material goes here outside table

 

[Martin Honnen]

Karin Jensen wrote:

<script language="text/javascript">

Use
<script type="text/javascript">
or

<!--

^^^^
Simply remove that, or if you think there is any need to comment out
script code then do it properly and insert the comment closer
//-->

</script>

before the closing </script>.

 

[Jim Davis]

Hi - I am trying to use Javascript to put material inside a table
(i.e. alongside the previous material) if the user's screensize is
big enough and outide the table (beneath table) if it isn't.

There are actually a coupla basic problems with your script which may, or
may not be causing the problems - but fixing them first should be a priority
just to get them off the suspects list. ;^)

There may be others but what I see off the top of my head is:

1) You've got the "language" attribute mixed up with the "type" attribute.
Change " language="text/javascript" " to " type="text/javascript" ". You
can happily not include the "language" attribute at all.

2) Your "hiding" comments are broken - you're beginning the comments
("<!--") but never ending them ("// -->"). This is probably causing the
color-coding issues you're seeing in FireFox (that's a guess). Personally I
would remove the comments completely - it's an archaic technique that
doesn't really offer anything today (although I'll admit it's a hard habit
to break).

Fix those and see where you are.

Lastly, and I apologize in advance for waxing philosophic here (feel free to
ignore me), some thoughts:

I think that you're concept is flawed. You don't want the screen size- you
want to the browser size. It's wrong to assume that the user will always
run their browser maximized... and even if the browser were maximized the
screen real-estate useful for a web page is whittled away by tool bars,
explorer bars, search bars, favorites bars and candy bars.

There's a strong correlation between screen size and browsing behavior:
users with low screen resolutions nearly always maximize their browsers,
users with very high screen resolutions rarely do. However users with high
screen resolutions are also much more likely to leave real-estate gobbling
interface elements visible as well.

In any case one way to get the "browser size" (the actual size of the
browsers display area) is to examine the size of the current "BODY" tag
(this code, of course, that there IS a body tag available to be examined):

document.getElementsByTagName('BODY')[0].clientHeight
document.getElementsByTagName('BODY')[0].clientWidth

I've only tested this on IE 6.x and FireFox 1.x... it may or may not work on
others.

Of course just because their browser STARTS at that size is no reason to
assume that they'll leave it that size for the duration of their session.
Your implementation should be able to deal with this behavior - at the very
least the content of the site shouldn't present assumptions about the
current state of the browser if you've only checked that state at the
beginning of the session.

Again, sorry for the lecture. I'm a human factors consultant by trade so
this kind of thing hits home. ;^)

In any case I hope this helps,

Jim Davis

 

[Lasse Reichstein Nielsen]

document.getElementsByTagName('BODY')[0].clientHeight

Why this convoluted way of getting at document.body? I don't think
there is a browser implementing document.getElementsByTagName and not
document.body (document.body was implemented by IE 3) both are part of
the W3C DOM level 1 HTML standard).

The clientHeight property is not standardized (it was introduced by IE
4), nor is its position on the body element. If one wants to find the
size of the browser's document viewport, the FAQ has more general ways

Of course just because their browser STARTS at that size is no reason to
assume that they'll leave it that size for the duration of their session.

Ah, yes. The devil is in the details, too.
At least, after a page has loaded, the user can see what he is doing by
resizing it.

/L

 

[Jim Davis]

document.getElementsByTagName('BODY')[0].clientHeight

Why this convoluted way of getting at document.body? I don't think
there is a browser implementing document.getElementsByTagName and not
document.body (document.body was implemented by IE 3) both are part of
the W3C DOM level 1 HTML standard).

Is there there any better answer than "that's what worked off the top of my
head"? ;^)

Isn't the great thing about JavaScript that there's ALWAYS another way (and
usually a better way) to do something?

The clientHeight property is not standardized (it was introduced by IE
4), nor is its position on the body element. If one wants to find the
size of the browser's document viewport, the FAQ has more general ways
of doing it: <URL:http://jibbering.com/faq/#FAQ4_9>

Then, by all means, use the better code. As I noted, I only tested on IE 6x
and FireFox 1x (clientHeight is supported in both).

The primary point was NOT to use the screen size for such a decision.

Ah, yes. The devil is in the details, too.
At least, after a page has loaded, the user can see what he is doing by
resizing it.

Exactly... really until you constantly check for changes you're making broad
assumptions about an environment with one check. From a usability POV this
is just isn't good.

Jim Davis

 

[Karin Jensen]

2) Your "hiding" comments are broken - you're beginning the
comments ("<!--") but never ending them ("// -->").

Ick! That fixed it. I feel very silly now. Thanks to you and
Martin for pointing this out. I just couldn't see for looking that
I'd made that mistake once and copied it into both bits of code.
Sometimes IE doesn't help by running broken code, so that you think
the error is a mistake in another browser. (Most of the page is in
PHP, but the size stuff has to be client side. I don't use
Javascript much and it shows!)

I think that you're concept is flawed. You don't want the screen
size- you want to the browser size. It's wrong to assume that the
user will always run their browser maximized... and even if the
browser were maximized the screen real-estate useful for a web
page is whittled away by tool bars, explorer bars, search bars,
favorites bars and candy bars.

I agree - this was just a first stab. I'll use the method suggested
in <URL:http://jibbering.com/faq/#FAQ4_9> The next step after that
is to deal with window resizes during the same session. I have to
move in fairly small steps or I'd never get anything working...

Thanks again,

Karin

 

[Jim Ley]

In any case one way to get the "browser size" (the actual size of the
browsers display area) is to examine the size of the current "BODY" tag
(this code, of course, that there IS a body tag available to be examined):

document.getElementsByTagName('BODY')[0].clientHeight
document.getElementsByTagName('BODY')[0].clientWidth

Why on earth would you use this, rather than

document.body ???

They're equally as standard, and document.body is much, much more
supported.

Jim.

 

[Dr John Stockton]

JRS: In article <Pine.GSO.4.44.0508311550280.21034-100000@austen>,
dated Wed, 31 Aug 2005 16:01:21, seen in

Hi - I am trying to use Javascript to put material inside a table
(i.e. alongside the previous material) if the user's screensize is
big enough and outide the table (beneath table) if it isn't.

You have been told to use window size rather than screen size. That's a
naive response; if, as an author, you elect to present the material
wider, then the reader can increase the window size rather readily in
order to get your preferred effect.

In general, it seems better for a reader to be able to widen the window
rather than to be forced, because of the size that the window initially
happened to be, to have the material use more height than necessary.
You may be able to arrange that the material adjusts it position to suit
the window size currently in use, as happens for ordinary text.

For instance, when I arrive at a new site, I generally have a 640 px
wide window, because that is what suits my local home page and my
LinkFile; I *expect* to widen the window when I am ready to read it.



However, you cannot judge with any reliability whether your material
(unless largely graphic) will fit in a given screen width.

My default window size normally shows about 70-80 characters of my
default fixed-width font, but Ctrl-Mousewheel will alter this by a
factor of about 1.5 each way. Others may use more variation;
particularly the visually-handicapped.

 

[Jim Davis]

In any case one way to get the "browser size" (the actual size of the
browsers display area) is to examine the size of the current "BODY" tag
(this code, of course, that there IS a body tag available to be examined):

document.getElementsByTagName('BODY')[0].clientHeight
document.getElementsByTagName('BODY')[0].clientWidth

Why on earth would you use this, rather than

document.body ???

For the same reason I'd already given - because that's what I remembered off
the top of my head.

No special reason other than that. ;^)

Sometimes what sticks to your noodle (and works) isn't always the most
concise option.

Jim Davis

 

[Jim Davis]

Ick! That fixed it. I feel very silly now. Thanks to you and

Well - definatetly don't feel silly. Broken code outnumbers working code in
this world by a very healthy margin: you're not alone and you never will be.

I agree - this was just a first stab. I'll use the method suggested
in <URL:http://jibbering.com/faq/#FAQ4_9> The next step after that
is to deal with window resizes during the same session. I have to
move in fairly small steps or I'd never get anything working...

No problem... the majority of programming is chipping away at a problem.

You know - a journey of a thousand miles begins, well in this case with
fixing some comments. ;^)

Good luck!

Jim Davis

 

[Randy Webb]

Dr John Stockton said the following on 9/1/2005 10:31 AM:

JRS: In article <Pine.GSO.4.44.0508311550280.21034-100000@austen>,
dated Wed, 31 Aug 2005 16:01:21, seen in


You have been told to use window size rather than screen size. That's a
naive response;

If telling someone to use window size rather than screen size is naive,
then telling them afterwards to use screen size instead of window size
is plain stupid.

 

[Jim Davis]

Dr John Stockton said the following on 9/1/2005 10:31 AM:


If telling someone to use window size rather than screen size is naive,
then telling them afterwards to use screen size instead of window size is
plain stupid.

Well - neither conclusion is naive or stupid.

(John likes to see things and make negative assumptions about the person
making the statement. For example here he might have assumed "the person
making the suggestion wasn't addressing the topic in any detail" but instead
he made the assumption "the person making the suggestion doesn't know any
better".)

In any case...

Neither suggestion is "right" because both assume a different question that
hasn't been explicitly asked. But first some back ground.

The usability studies on the matter are rather clear on several points:

1) People with small screen resolutions (say 1024X768 or less) tend to run
their applications (including) maximized. People with larger screen
resolutions tend not to run their applications in windows (windows the gui
element, not Windows the OS). ;^)

2) People with small screen resolutions tend to eliminate "obvious"
real-estate grabbers. They will more often go after elements that force
horizontal scrolling (Explorer Bars in IE, for example) than vertical
scrolling (tool bars, status bars, etc). People with larger screen sizes
tend to leave such elements alone.

3) In general people will resize a browser window (if possible) to eliminate
a horizontal scroll bar. Other than they generally leave the size as-is.

The rule of thumb is: less is more. The less screen real-estate you have
the more of it will be dedicated to the current task. The more screen
real-estate you have the less of it will be focused to the current task.

What this means is that while the extremes (extremely small or extremely
high resulutions) are generally static the middle area is more alike when
comes to real-estate dedicated to the task (in this case viewing a web
page). The behavior at smaller resolutions is to dedicate most, if not all,
of that small screen to the Web page. The larger resolutions will allow
multiple applications and interface elements to coexist with the Web page so
that the actual slice of screen dedicated to the page is similar to that of
the smaller screen.

There are three metrics of interest:

Screen Size: this is the largest that application can be (barring virtual
desktop extenders, but lets assume a more general audience for the time
being). When it comes right down to it however what you really need here is
"Available Screen Size" - the size of the area dedicated to application
display in the OS (this measurement would not include such things as the
Windows Task Bar if that bar was set to "always on top").

Browser Window Size: This is the size of the browser widow - the outside
frame. It's the total size of the application, from edge to edge.

Browser Client Area Size: This is the space available in the browser for
the display of Web pages. It would not include scrollbars, explorer bars,
toolbars, statusbars, etc.

So... considering that (still cursory examination of a very interesting
topic) when applied to the original posters situation.

The situation was that a static web page would be generated with specific
additional content placed either on the right side of the main content area
"if there is room" or on the bottom of the page.

There are two questions (at least) that can be asked:

1) "Is there enough room this instant, as the browser is currently
displayed, to place the content on the side and not scroll horizontally?"
(Scrolling is a bit of a crap because scroll bar widths are not constant
across environments... but the aim is definately no horizontal scroll bar).

To answer this you need to look at the client-area of the browser and allow
some padding for scroll bar width.

2) "Is there enough room to add the content on the side without horizontal
scrolling either this instant or if the browser is resized?" (The
assumption, of course, is that the browser can't be resized larger than the
screen size.)

Well - this one is much trickier to answer. A starting guess might be to
work out the percentage of the width taken up by non-page materials (using
the Browser Window size and the Browser Client Area size) and apply that
ratio to the available screen width to see how much of the browser would be
dedicated to web pages if it were maximized.


I believed that the original poster was asking the first question. John
believed she was asking the second or some variation (or, if she wasn't that
she SHOULD be). Considering that I don't think either answer is wrong...
although one is definately tactless.

However using screen size alone is probably never the correct answer. The
only question this could answer would be something like: "Could the content
fit if the browser was maximized and if it featured no horizontally inserted
interface elements." The question is not looking at the state of the
environment but assuming one potential state. And you never want to make
decisions based on such assumptions.

Jim Davis

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Fri, 2 Sep 2005
03:16:34, seen in Jim Davis

Screen Size: this is the largest that application can be (barring virtual
desktop extenders, but lets assume a more general audience for the time
being).

Untrue. A window can be wider than its screen.

Remember Mark Twain.

 

[Randy Webb]

Dr John Stockton said the following on 9/3/2005 2:04 PM:

JRS: In article <[email protected]>, dated Fri, 2 Sep 2005
03:16:34, seen in Jim Davis



Untrue. A window can be wider than its screen.

And screen width is irrelevant when designing a web page.

 

[Jim Davis]

JRS: In article <[email protected]>, dated Fri, 2 Sep 2005
03:16:34, seen in Jim Davis


Untrue. A window can be wider than its screen.

Granted - you're right. Although for purposes of that definition they are
irrelevant. The clearly stated assumption is "a more general audience" - in
other words people that consider a maximized application "as big as it can
be".

But, I readily admit, as completely irrelevant as your point is, to the
conversation you are, technically correct - and we all know that's what
matters. ;^)

Actually... on second thought there is one potentially relevant issue - one
that your point hints on but doesn't actually illuminate (which again is
find since as long as you're technically correct there's no reason to
actually add useful content to the conversation):

Any script attempting the more complex calculation of potential client size
shouldn't make assumptions about relative sizes. In other words the script
should be robust enough to calculate correctly even if the screen size is
smaller than the application window.

This also reminds me of another subtle issue which may be relevant: dual
monitors. Current JavaScript implementations have the unfortunate problem
of being unable to provide information about multiple monitors. In my
experience current implementations will always return the information
relevant to the primary monitor in situation where independent displays are
at work no matter which display the current window is on.

If the displays are the same size this is fine, but if they're not (more
likely a large primary display and smaller secondary display) this could
make your calculations meaningless to the current browser instance.

Spanned desktop displays (non-independent multi-monitor displays) on the
other hand will return both displays as on value (which, in fact, they
technically are but in practice application windows are rarely spanned
across multiple displays). This will return screen sizes of (for example)
"1248x768" or "2560x1024".

The may not pose a problem to your calculations but again, you should be
aware that it's a possibility.

Jim Davis