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

Is it preferrable to not use inline javascript?

P: n/a
Which code is preferrable?

Code A:

<script type="text/javascript">
function someFunc() {
// stuff
}
</script>
<body>
<div onmouseover="someFunc()">
<a href="...">link</a>
</div>
</body>
Code B:

<script type="text/javascript">
function someFunc() {
// stuff
}
function init() {
var div1 = document.getElementById('div1');
div1.onmouseover = someFunc;
}
</script>
<body>
<div id="div1">
<a href="...">link</a>
</div>
</body>
It could be argued that Code B is preferrable because it completely separates
the Javascript from the HTML. What do you guys think?

Jul 20 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Oops, code B should have this body tag:

<body onload="init()">

Jul 20 '05 #2

P: n/a
de*******@no.spam.com wrote:
Oops, code B should have this body tag:

<body onload="init()">


Hardly seperates it then does it?

window.onload = function() { init(); }

--
David Dorward <http://dorward.me.uk/>
Jul 20 '05 #3

P: n/a
delerious wrote:
It could be argued that Code B is preferrable because it completely separates
the Javascript from the HTML. What do you guys think?


I prefer code C:

<script type="text/javascript">
function someFunc() {
// stuff
}
document.getElementById('div1').onmouseover = someFunc;
</script>
<body>
<div id="div1">
<a href="...">link</a>
</div>
</body>

Or even better code D:

<script type="text/javascript" src="behaviour.js"></script>
<body>
<div id="div1">
<a href="...">link</a>
</div>
</body>

where behaviour.js contains:

function someFunc() {
// stuff
}
document.getElementById('div1').onmouseover = someFunc;

With code D, the javascript becomes a simple drop-in file (like CSS is)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?page=132

Jul 20 '05 #4

P: n/a
de*******@no.spam.com writes:
It could be argued that Code B is preferrable because it completely separates
the Javascript from the HTML.
No it doesn't. If it was
<script src="someotherfile.js" type="text/javascript"></script>
then it would be separate.

Why is separation important? With CSS, I can see the point, because
the same CSS can be used for different pages, giving a consistent look
throughout a site. Javascript doesn't work like that, since the
behavior is very often unique to the page. The parts that can be shared,
are shared with included files, but the logic that binds the code
to the HTML is often unique to the page.
What do you guys think?


I think I prefer A.

Using the HTML intrinsic event attributes is easier, and better shows
which code is connected to which other code.
I won't write novels, though. Just a call to the appropriate function.

It is defined in the HTML specification (and you should remember the
<meta http-equiv="Content-Script-Type" content="text/javascript"> tag!).
The "onmouseover" property, as in:
document.getElementById("div1").onmouseover = func;
is not part of a W3C specification. If you user DOM 2 Events, you should
write:
document.getElementById("div1").addEventListener(" mouseover",func,false);
That won't work in IE, though (what does?).
/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.'
Jul 20 '05 #5

P: n/a
On Sat, 13 Dec 2003 13:34:14 +0100, Lasse Reichstein Nielsen <lr*@hotpop.com>
wrote:
The "onmouseover" property, as in:
document.getElementById("div1").onmouseover = func;
is not part of a W3C specification. If you user DOM 2 Events, you should
write:
document.getElementById("div1").addEventListener(" mouseover",func,false);
That won't work in IE, though (what does?).


In IE, you would use this:
document.getElementById("div1").attachEvent("onmou seover", func);

Jul 20 '05 #6

P: n/a
In article <y8**********@hotpop.com>, lr*@hotpop.com says...
Why is separation important? With CSS, I can see the point, because
the same CSS can be used for different pages, giving a consistent look
throughout a site. Javascript doesn't work like that, since the
behavior is very often unique to the page. The parts that can be shared,
are shared with included files, but the logic that binds the code
to the HTML is often unique to the page.


Many people have javascript code libraries, that contain globals,
classes, and useful functions. When used like this, an external file is
the way to go.

--
Whitecrest Entertainment
www.whitecrestent.com
Jul 20 '05 #7

P: n/a
Lee
Whitecrest said:

In article <y8**********@hotpop.com>, lr*@hotpop.com says...
Why is separation important? With CSS, I can see the point, because
the same CSS can be used for different pages, giving a consistent look
throughout a site. Javascript doesn't work like that, since the
behavior is very often unique to the page. The parts that can be shared,
are shared with included files, but the logic that binds the code
to the HTML is often unique to the page.


Many people have javascript code libraries, that contain globals,
classes, and useful functions. When used like this, an external file is
the way to go.


Yes, external libraries are handy, but they're not as useful
for event handlers, since they have to be tied to specific
DOM objects.

Jul 20 '05 #8

P: n/a
de*******@no.spam.com writes:
In IE, you would use this:
document.getElementById("div1").attachEvent("onmou seover", func);


Yes, but when using that, func is not treated as a method of the
element (i.e., "this" inside the func body will not refer to the
element "div1").

/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.'
Jul 20 '05 #9

P: n/a
JRS: In article <br*********@drn.newsguy.com>, seen in
news:comp.lang.javascript, Lee <RE**************@cox.net> posted at Sat,
13 Dec 2003 10:50:24 :-

Yes, external libraries are handy, but they're not as useful
for event handlers, since they have to be tied to specific
DOM objects.


ISTM that the above is not the case.

<URL:http://www.merlyn.demon.co.uk/hols.htm> has, IIRC, five buttons.
They all call the same onClick function, which reads from the controls
and writes to the object appropriate to the button used.

When used for the last button, unlike the others, onClick executes an
eval() providing extensibility.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Jul 20 '05 #10

P: n/a
Dr John Stockton <sp**@merlyn.demon.co.uk> writes:
<URL:http://www.merlyn.demon.co.uk/hols.htm> has, IIRC, five buttons.
They all call the same onClick function, which reads from the controls
and writes to the object appropriate to the button used.
As I read the page, you are using a different solution than the two
discussed so far (adding a hander eithe using an onclick="code"
attribute or with elem.onclick=func scripting). This page uses
document.write to add the button tags, which then contain onclick
attributes. When it comes to separation of content and behavior
(HTML/Javascript), this is further from that goal than just having
onclick attributes. (I'm not saying it's a desireable goal :).

You still need to link the HTML and the Javascript in some way. Your
solution to that is to let the Javascript create not only the link,
but also the HTML it is linked to. That makes it independent of the
page it is used on. It also makes the page completely dependent on
Javascript, which not all pages can afford.
When used for the last button, unlike the others, onClick executes an
eval() providing extensibility.


.... but ... but ... but ... eval is *evil*?!?!? :)

/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.'
Jul 20 '05 #11

P: n/a
JRS: In article <u1**********@hotpop.com>, seen in
news:comp.lang.javascript, Lasse Reichstein Nielsen <lr*@hotpop.com>
posted at Sun, 14 Dec 2003 17:44:53 :-
Dr John Stockton <sp**@merlyn.demon.co.uk> writes:


( in response to :
Yes, external libraries are handy, but they're not as useful
for event handlers, since they have to be tied to specific
DOM objects.

<URL:http://www.merlyn.demon.co.uk/hols.htm> has, IIRC, five buttons.
They all call the same onClick function, which reads from the controls
and writes to the object appropriate to the button used.


As I read the page, you are using a different solution than the two
discussed so far (adding a hander eithe using an onclick="code"
attribute or with elem.onclick=func scripting). This page uses
document.write to add the button tags, which then contain onclick
attributes. When it comes to separation of content and behavior
(HTML/Javascript), this is further from that goal than just having
onclick attributes. (I'm not saying it's a desireable goal :).

You still need to link the HTML and the Javascript in some way. Your
solution to that is to let the Javascript create not only the link,
but also the HTML it is linked to. That makes it independent of the
page it is used on. It also makes the page completely dependent on
Javascript, which not all pages can afford.


That's highly useful to the page, but not essential to the point.

I take "event handler" to be not the onClick="..." string itself, but
the code which does the bulk of the work. In this case, said code is
function Response(Div, FNam) { ... } which is given strings identifying
the result destination (Div) and the information source (FNam). It is
an irrelevant convenience that the button is here created by javascript
and not by straight HTML. Response is not external to the page, but it
could be.

So the event handler is not tied to a specific object, AIUI.

When used for the last button, unlike the others, onClick executes an
eval() providing extensibility.


... but ... but ... but ... eval is *evil*?!?!? :)


Be careful, then, not to look at the end (line 11233) of a fresh version
of js-date5.htm, which also uses eval to discover the user's wishes. I
used Paris before I discovered how to spell KÝbenhavn.

Another reason for using eval is higher up the page, line 365; ISTM
necessary if one wants to put code in a page for *both* execution and
display (obviously it is good to have the code shown being the code
executed, and not a fallible transcription).

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> Jsc maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/Jsc/&c, FAQ topics, links.
Jul 20 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.