HTML event handlers

[Eustace]

I used the JavaScript Verifier (http://www.jslint.com/) to check my
webpage (http:/www.geocities.com/emfrilingos/js/datecalc.html). It
advises me to avoid HTML event handlers:

=================
Problem at line 214 character 7: Avoid HTML event handlers.

onLoad="document.dataForm1.firstYear.value = 'yyyy';
document.dataForm1.first...

Problem at line 268 character 24: Avoid HTML event handlers.

onClick="calculateInterval(); return false;">

Problem at line 316 character 23: Avoid HTML event handlers.

onClick="calculateDate(); return false;">

Problem at line 317 character 58: Avoid HTML event handlers.

<input type="button" value="Repeat" onclick="repeatAction();">
=================

How can I avoid HTML event handlers?

Eustace

 

[Lasse Reichstein Nielsen]

I used the JavaScript Verifier (http://www.jslint.com/) to check my
webpage (http:/www.geocities.com/emfrilingos/js/datecalc.html). It
advises me to avoid HTML event handlers:

It is known to be a little over-zealous. If you follow its advice, and
know what you are doing, you are likely to get pages that are easier
to maintain, change and understand.

That doesn't mean that it's necessarily worth it for every page out
there.

=================
Problem at line 214 character 7: Avoid HTML event handlers.

onLoad="document.dataForm1.firstYear.value = 'yyyy';
document.dataForm1.first...

Problem at line 268 character 24: Avoid HTML event handlers.

onClick="calculateInterval(); return false;">

Problem at line 316 character 23: Avoid HTML event handlers.

onClick="calculateDate(); return false;">

Problem at line 317 character 58: Avoid HTML event handlers.

<input type="button" value="Repeat" onclick="repeatAction();">
=================

How can I avoid HTML event handlers?

Delete them. I.e., remove all "onclick", "onload", "onwhatever"
attributes from the HTML.

Now, if you want the page to still do the same thing, you'll have
to add them again, programmatically, so you would have something like

<script type="text/javascript">
window.onload = function() {
document.getElementById("intervalFieldId").onclick = function() {
calculateInterval(); return false;
};
document.getElementById("dateFieldId").onclick = function() {
calculateDate(); return false;
};
document.forms['myFormId'].elements[42].onclick = function() {
repeatAction();
};
document.forms['dataForm1'].elements['firstYear'].value = 'yyyy';
document.forms['dataForm1'].elements['first...
// etc
};
</script>

Then you can start considering whether it's worth all that fuss over
a warning from an extra zealous validator. There's nothing inherently
wrong with HTML intrinsic event handlers. Sure, separation of content,
style, and behavior is a great idea, but only you can tell whether this
is the kind of high quality, long lasting code that needs to be
extremely maintainable, or if it's something that's going to get replaced
completely in three months[1].

/L
[1] Hint: "Temporary" code tends to hang around for decades longer
than predicted.

 

[Thomas 'PointedEars' Lahn]

It is known to be a little over-zealous. If you follow its advice, and
know what you are doing, you are likely to get pages that are easier to
maintain, change and understand.

That's highly unlikely.

That doesn't mean that it's necessarily worth it for every page out
there.

Given the output posted, it's not worth it for any "page" out there.

=================
[...]
Problem at line 268 character 24: Avoid HTML event handlers.

onClick="calculateInterval(); return false;">
[...]
How can I avoid HTML event handlers?

Delete them. I.e., remove all "onclick", "onload", "onwhatever"
attributes from the HTML.

It would solve the problem, but it is still bad advice as there is no
problem at all.

Now, if you want the page to still do the same thing, you'll have to add
them again, programmatically, so you would have something like

<script type="text/javascript">
window.onload = function() {
[...]
}; </script>

Then you can start considering whether it's worth all that fuss over a
warning from an extra zealous validator.

And your example is only the peak of the iceberg, considering that it uses a
proprietary approach that would require a standards compliant alternative
for it to have at least the chance to be interoperable.

There's nothing inherently wrong with HTML intrinsic event handlers.

My words exactly.

Sure, separation of content, style, and behavior is a great idea,

But it does not apply here. DOM scripting code belongs to the markup that
it operates on. "Unobtrusive JavaScript", as apparently advocated by this
script-kiddie validator, is a nonsensical script-kiddie notion considered
harmful.

but only you can tell whether this is the kind of high quality, long lasting
code that needs to be extremely maintainable, or if it's something that's
going to get replaced completely in three months[1].

However, easy maintenance, no matter the supposed lifetime of the code, is
one reason why you should use event handler attributes for existing markup,
albeit not the most important one (that would be interoperability). The
code is where it belongs, not somewhere else. And you can easily find out
with a code inspector what that code is, without having to resort to
interpret string representations of the assigned method, if these are
directly available (they are not if you used addEventListener() or
attachEvent()).


PointedEars