By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,774 Members | 1,380 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,774 IT Pros & Developers. It's quick & easy.

Javascript and CSS

P: n/a
Ok, The following html works wonderful in IE. It does not work in
FireFox. Can someone please tell me the work around for FireFox to get
this to work.

HTML DOCUMENT:

<html>
<head>
<title>CSS Z-order Test</title>
<script language=Javascript>
<!---
function showtbl2()
{
window.document.getElementById("tbl1").style.displ ay="none";
window.document.getElementById("tbl2").style.displ ay="block";
}
function showtbl1()
{
window.document.getElementById("tbl2").style.displ ay="none";
window.document.getElementById("tbl1").style.displ ay="block";
}
--->
</script>
<style TYPE="text/css">
table.tblone{color:white; background-color:red; position:absolute;
top:100px; left:100px;z-index:1;}
table.tbltwo{color:white; background-color:darkblue;
position:absolute; top:100px; left:100px;z-index:2; display:none;}

</style>

</head>
<body>

<h3 align=center>Z-order Test</h3>

<table ID="tblmenu" style="position:absolute; top:83px;
left:100px;z-index:1;" width="50%" border=0 cellpadding=0
cellspacing=0>
<tr>
<td width="50%" style="color:white; background-color:red"><a
href="javascript:;" onClick="showtbl1();" style="color:white">Table
One</a></td>
<td width="50%" style="color:white; background-color:darkblue"><a
href="javascript:;" onClick="showtbl2();" style="color:white">Table
Two</a></td>
</tr>
</table>
<table class="tblone" ID="tbl1" width="50%">
<tr>
<td>This is table one</td>
</tr>
</table>
<table class="tbltwo" ID="tbl2" width="50%">
<tr>
<td>This is table two</td>
</tr>
</table>

</body>
</html>

Thanks for any help!!!

Jul 23 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
f1******@gmail.com wrote:
Ok, The following html works wonderful in IE. It does not work in
FireFox. Can someone please tell me the work around for FireFox to get
this to work.

No 'work around' required, just fix the code...
HTML DOCUMENT:

<html>
<head>
<title>CSS Z-order Test</title>
<script language=Javascript>
The language attribute for the script element is depreciated,
type is required:

<script type="text/javascript">
<!---
This is a comment delimiter for HTML, not JavaScript. It will
be ignored by any JavaScript parser. Use /* */ for blocks or //
for single lines.

It was used once upon a time in ancient days to hide scripts
from browsers that didn't know how to deal with scripts but
hasn't been necessary since Netscape 2 (1994?). Even browsers
that don't implement JavaScript know to ignore the content and
not render it.
function showtbl2()
{
window.document.getElementById("tbl1").style.displ ay="none";
window.document.getElementById("tbl2").style.displ ay="block";
}
The default value for the display attribute of a table's style
object is not "block", it is "table".

The CSS table model is here:

<URL:http://www.w3.org/TR/CSS21/tables.html#value-def-table>

and the default HTML style sheet is here:

<URL:http://www.w3.org/TR/CSS21/sample.html>

In general, if using 'display' to show and hide elements, swap
between '' and 'none' respectively, '' will return the element
to the default.

document.getElementById("tbl1").style.display="non e";
document.getElementById("tbl2").style.display="";

The 'window' global object is assumed and not required.
function showtbl1()
{
window.document.getElementById("tbl2").style.displ ay="none";
window.document.getElementById("tbl1").style.displ ay="block";
}
--->
This closing HTML comment tag will cause an error in most
browsers (but not IE?). Get rid of it.

In the dark days when it was actually necessary, it was done
like this:

// -->

using a script comment delimiter to hide the HTML comment
delimiter from the JavaScript parser. Messy, eh?
</script> [...] <td width="50%" style="color:white; background-color:red"><a
href="javascript:;" onClick="showtbl1();" style="color:white">Table
One</a></td>
When you click on the 'a' element, the onclick runs, and then
whatever is in the href attribute is parsed. Since there is
nothing there, Firefox re-loads the page, returning it to the
original layout. To stop the page reloading, have the onclick
return false.

There is also no need to use the javascript pseudo protocol in
the href since you have onclick:

href="#" onClick="showtbl1(); return false;" ...

[...] <td width="50%" style="color:white; background-color:darkblue"><a
href="javascript:;" onClick="showtbl2();" style="color:white">Table


Same here.

[...]

Do the above modifications and your script will work in IE and
Firefox.
--
Rob
Jul 23 '05 #2

P: n/a
On 22/03/2005 02:44, RobG wrote:
f1******@gmail.com wrote:


[snip]
function showtbl2()
{
window.document.getElementById("tbl1").style.displ ay="none";
window.document.getElementById("tbl2").style.displ ay="block";
}


The default value for the display attribute of a table's style
object is not "block", it is "table".

The CSS table model is here:

<URL:http://www.w3.org/TR/CSS21/tables.html#value-def-table>


That is true, except for IE where virtually every block-level element
has a display value of 'block', even if there is a more appropriate
value. That's why restoration of an element should involve assigning
any empty string

document.getElementById('tbl2').style.display = '';

rather than a value. However, that cannot work in this case as the
table is initially hidden via a style sheet declaration.

To the OP: Rather than specifying class names (which is appropriate
when a rule does - or /can/ - apply to multiple elements), use an id
selector. That is, replace

table.tblone {

with

#tbl1 {

and likewise for the second table.

Secondly, it is generally inadvisable to hide an element with CSS and
rely on a client-side script to later reveal it. If a script will show
and hide elements, it should be left soley to the script as then you
can be sure that if the element was hidden, it can be shown again
(something which isn't necessarily true otherwise).

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #3

P: n/a
While table is the default value for the display property, there's
nothing wrong about assigning it as block, I can hardly imagine FF not
cooporating because of that.

The HTML comments should also be pretty cosher, seeing as it's
mentioned in the spec:
http://www.w3.org/TR/html4/interact/....html#h-18.3.2 But the form
is obviously not "--->" but "//-->", that's all it takes. The spec
gives this general form

<script type="text/javascript">
<!--
js here
// -->
</script>

Which always confused me, because why is the last closing comment
delimeter required to be (JS) escaped? I just tested in my cmd version
of spidermonkey (1.5), and it just eats this

function foo() {
<!--
return 2 + 2;
}

JScript won't eat the above, so it must be agent dependent. So again,
why this strange specification? Was the W3 just looking/working with
NS, to get a behavior? Neither <!-- or --> are JS tokens, and as such,
invalid (or? someone more up on JS lex/grammar then me?), so does the
HTML spec "spare" the engine for the -->, but NOT the <!--.

Strange, and it's far too late here, and the question far too
inconsequential :p

Regards,
Svend

Jul 23 '05 #4

P: n/a
Svend Tofte wrote:
While table is the default value for the display property, there's
nothing wrong about assigning it as block, I can hardly imagine FF not
cooporating because of that.
Noted, but some seem to think elements are either block or
in-line, with nothing in between. Unless a specific layout is
required, it is safer to use ''.

The HTML comments should also be pretty cosher, seeing as it's
mentioned in the spec:
http://www.w3.org/TR/html4/interact/....html#h-18.3.2 But the form
is obviously not "--->" but "//-->", that's all it takes. The spec
gives this general form
Yes, but it's just not necessary. As far as I can tell, the
script element was introduced with HTML 3.2 in January 1977 so
I can't imagine that there are too many users with browsers that
don't understand what it's for, even if they don't support
scripting.

<script type="text/javascript">
<!--
js here
// -->
</script>

Which always confused me, because why is the last closing comment
delimeter required to be (JS) escaped? I just tested in my cmd version
of spidermonkey (1.5), and it just eats this

function foo() {
<!--
return 2 + 2;
}

JScript won't eat the above, so it must be agent dependent. So again,
why this strange specification? Was the W3 just looking/working with
NS, to get a behavior? Neither <!-- or --> are JS tokens, and as such,
invalid (or? someone more up on JS lex/grammar then me?), so does the
HTML spec "spare" the engine for the -->, but NOT the <!--.
I don't think it's anything to do with W3C, they don't define
JavaScript, ECMA does - that's why it's real name is

"Standard ECMA-262 ECMAScript Language".

<URL:http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>

The ECMA spec does not define "<!--" anywhere, so I'll take a
guess that the fact that JavaScript interpreters appear to
ignore <!-- is implementation specific and should not be relied
on. Firefox ignores the rest of the line after <!--, making it
effectively the equal of // (as does IE).

I suspect the browser removes it before passing it to the
interpreter, since if a JS comment marker was required before
the opening HTML comment marker, the it would be displayed in
those browsers that don't understand the script element.

i.e.
<script ...>
// <!--
/* insert valid JavaScript here */
// -->
</script>

would appear in the document as:

//

JS interpreters likely barf on the closing HTML tag because of
confusion with the prefix decrement operator.

Strange, and it's far too late here, and the question far too
inconsequential :p


Not inconsequential, it's worth discussing even if only to make
me lookup the ECMA spec and run a few tests.

--
Rob
Jul 23 '05 #5

P: n/a
On 23/03/2005 06:32, RobG wrote:
Svend Tofte wrote:
While table is the default value for the display property, there's
nothing wrong about assigning it as block, I can hardly imagine FF not
cooporating because of that.
What effect is made by assigning the wrong display value would depend
on what is associated with that value. User agents may simply map
table to block. Some may not. Furthermore, their similarity may only
be visual. As you don't need to assign the wrong value, don't.

[snip]
The HTML comments should also be pretty cosher, seeing as it's
mentioned in the spec:
The specification is almost six years old. At the time of writing,
there still will have been (what are now ancient) user agents that did
not recognise the SCRIPT and STYLE elements. Those user agents are no
longer in use so catering for them is a complete waste of time and
perpetuates the myth that "hiding" scripts is somehow necessary.
Moreover, if you move to XHTML (proper) this form of hiding really
/will/ hide your script, though this time from all XHTML user agents.

[snip]
Yes, but it's just not necessary. As far as I can tell, the
script element was introduced with HTML 3.2
The element was introduced (STYLE, too), but it wasn't defined. It
merely acted as a placeholder so that new user agents could recognise
the name.
in January 1977
Umm, I think you mean '97. HTML 2.0 (RFC 1866) was published in 1995.
I can't imagine that there are too many users with browsers that
don't understand what it's for, even if they don't support
scripting.


There shouldn't be any. If they are roaming around, the user must
either be a masochist or is using it for some sort of historical
comparison: "I wonder - just how useless is this browser nowadays?" :)

[snip]
Which always confused me, because why is the last closing comment
delimeter required to be (JS) escaped?


The starting delimiter is easily recognised. If after whitespace an
SGML comment is recognised, the lexer (most likely) will just keep
eating characters until a new line when it can go back to eating
whitespace and comments, and looking for valid tokens. Recognising the
closing delimiter is harder as the lexer will see a decrement operator
and a comparison. As these would be legal within a script (provided
that the decrement follows an l-value, but that isn't a lexer's
responsibility), you can't just toss them away. Unless you make a
special case out of \s*-->\s*(?:[\u000a\u000d\u2028\u2029]+|$), or if
the browser strips the delimiters out itself.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #6

P: n/a
Michael Winter wrote:
RobG wrote:
in January 1977

Umm, I think you mean '97. HTML 2.0 (RFC 1866) was published in 1995.


Umm, yes. Must get these rented fingers checked... :-x

[...]

--
Rob
Jul 23 '05 #7

P: n/a
>> Which always confused me, because why is the last closing comment
delimeter required to be (JS) escaped?
The starting delimiter is easily recognised. If after whitespace an
SGML comment is recognised, the lexer (most likely) will just keep
eating characters until a new line when it can go back to eating
whitespace and comments, and looking for valid tokens.
But that assumes that it's the same lexer, working on the JS as well as
the HTML, and in all reasonable instances of browser architecture, that
is surely not true. W3C obviously also sees this, as they readily
imagine several languages for the script tag.
Recognising the
closing delimiter is harder as the lexer will see a decrement operator and a comparison. As these would be legal within a script (provided
that the decrement follows an l-value, but that isn't a lexer's
responsibility), you can't just toss them away. Unless you make a
special case out of \s*-->\s*(?:[\u000a\u000d\u2028\u2029]+|$), or if the browser strips the delimiters out itself.


I imagine, that the script tag is recognized by a parser (It doesn't
make sense to tokenize HTML+"unknown script", or?), and then the
content is processed by the browser, and then handed off of to the
script engine. And in that case, a context-sensitive "search" can
surely be made (to filter out the HTML comment tags).

The problem is just that I can imagine a trillion ways to solve the
problem, without having to escape the closing delimeter, and as such, I
was just wondering if there was any clear reasoning behind the spec.

Anyways, just wondering out loud ;)

Regards,
Svend

Jul 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.