473,325 Members | 2,860 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

Javascript problem in Firefox

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

Aug 31 '05 #1
14 12619


Karin Jensen wrote:

<script language="text/javascript"> Use
<script type="text/javascript">
or
<script language="JavaScript" type="text/javascript">
<!-- ^^^^
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>.
--

Martin Honnen
http://JavaScript.FAQTs.com/
Aug 31 '05 #2

"Karin Jensen" <k_******@mailblocks.com> wrote in message
news:Pine.GSO.4.44.0508311550280.21034-100000@austen...
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
Aug 31 '05 #3
"Jim Davis" <ne********@vboston.com> writes:
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 doing it: <URL:http://jibbering.com/faq/#FAQ4_9>
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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Aug 31 '05 #4
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:ll**********@hotpop.com...
"Jim Davis" <ne********@vboston.com> writes:
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.
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.


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
Aug 31 '05 #5
Jim Davis wrote:
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
Sep 1 '05 #6
On Wed, 31 Aug 2005 13:29:40 -0400, "Jim Davis"
<ne********@vboston.com> wrote:
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.
Sep 1 '05 #7
"Jim Ley" <ji*@jibbering.com> wrote in message
news:43**************@news.individual.net...
On Wed, 31 Aug 2005 13:29:40 -0400, "Jim Davis"
<ne********@vboston.com> wrote:
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
Sep 1 '05 #8
"Karin Jensen" <k_******@mailblocks.com> wrote in message
news:Pine.GSO.4.44.0509010905190.11722-100000@austen...
Jim Davis wrote:
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


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 think that you're concept is flawed. You don't want the screen


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
Sep 1 '05 #9
JRS: In article <Pine.GSO.4.44.0508311550280.21034-100000@austen>,
dated Wed, 31 Aug 2005 16:01:21, seen in news:comp.lang.javascript,
Karin Jensen <k_******@mailblocks.com> posted :
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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Sep 1 '05 #10
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 news:comp.lang.javascript,
Karin Jensen <k_******@mailblocks.com> posted :

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 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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Sep 1 '05 #11

"Randy Webb" <Hi************@aol.com> wrote in message
news:D-********************@comcast.com...
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 news:comp.lang.javascript,
Karin Jensen <k_******@mailblocks.com> posted :

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 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
Sep 2 '05 #12
JRS: In article <df*********@news2.newsguy.com>, dated Fri, 2 Sep 2005
03:16:34, seen in news:comp.lang.javascript, Jim Davis
<ne********@vboston.com> posted :
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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Sep 3 '05 #13
Dr John Stockton said the following on 9/3/2005 2:04 PM:
JRS: In article <df*********@news2.newsguy.com>, dated Fri, 2 Sep 2005
03:16:34, seen in news:comp.lang.javascript, Jim Davis
<ne********@vboston.com> posted :

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.


And screen width is irrelevant when designing a web page.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Sep 3 '05 #14

"Dr John Stockton" <jr*@merlyn.demon.co.uk> wrote in message
news:k3**************@merlyn.demon.co.uk...
JRS: In article <df*********@news2.newsguy.com>, dated Fri, 2 Sep 2005
03:16:34, seen in news:comp.lang.javascript, Jim Davis
<ne********@vboston.com> posted :
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.


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


Sep 4 '05 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
by: Howard Kaikow | last post by:
Yesterday, I decided to try Firefox. I've encountered a behavior that is either a bug in Firefox or a bug in my Javascript code. I'll try to explain the problem, hoping that this newsgroup can...
5
by: LRW | last post by:
(Sorry if this is a repost...my newsreader keeps crashing on the posting--I don't know if the message going out or not) For some reason this javascript just won't work in Firefox. It works fine...
13
by: John Smith | last post by:
I am using IE 6.0 from http://www.javaworld.com/javaworld/jw-07-1996/jw-07-javascript-p2.html I gather that "If you need to test a number of command lines, you can reduce the keystrokes by...
8
by: chrisdude911 | last post by:
how do i add video into a javascript web page with my own custom buttons?
4
by: lmarceglia | last post by:
Hi, I have this website that doesn't work in Firefox 1.5: www.pianetaluca.com The HTML source is: <TITLE>PianetaLuca</TITLE> </HEAD>
7
by: Coder | last post by:
Hi I have the following code in java script, it is not giving proper output in FIREFOX but running fine in IE... can anybody help me out to make this run in FIREFOX . <script...
11
by: minnesotti | last post by:
Hi there, I subscribed to a photographic pictures-hosting website which is heavy on JavaScript. My preferred latest browser Mozilla Firefox does not work with it -- no pictures are displayed and...
8
by: Matt Kruse | last post by:
http://news.zdnet.com/2100-1009_22-6121608.html Hackers claim zero-day flaw in Firefox 09 / 30 / 06 | By Joris Evers SAN DIEGO--The open-source Firefox Web browser is critically flawed in...
16
by: Eric | last post by:
I have a user of a web application written in Java/JSP that is unable to login to the site simply because certain links on the page do not run when they are clicked. Other popups using Javascript...
12
by: tim | last post by:
I am using foldoutmenu 3 and am having problems with viewing my menus in firefox. On my sub3 menus i have more than one line of text in some places. firefox does not recognise that there is more...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.