Javascript and CSS

f1crazed

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>

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

Subscribe Post Reply

1796

RobG

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

Michael Winter

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

Svend Tofte

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

</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() {
 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

RobG

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

</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() {
 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 
</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

Michael Winter

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

RobG

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

Svend Tofte

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

Similar topics