[thelist] javascript default event handlers, default events. [TIP]

[Matt Warden]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Sam,

Sam Foster wrote:
> markup to provide a starting point or smoking gun. There can be
> something like strange magic from afar - doing a view-source might not
> be enlightening - you may be obliged to actually dig into the code and
> follow it through with a debugger... Especially if the concept is new to
> you.

You can't do a view-source to debug PHP or Java code, either. I
understand where people are coming from here, but the unobtrusive idea
is a paradigm shift, and it should be expected that debugging (and
other) methods should also have to shift.

> The de-coupling of code/behavior from markup is more effective when you
> use something like document.getElementsBySelector.
> (http://simon.incutio.com/archive/2003/03/25/getElementsBySelector) ..
> this frees you from document.getElementById and needing a particular id
> to magically make everything work.

See also cssQuery: http://dean.edwards.name/my/cssQuery/

Thank the lord for getElementsByTagName, eh?

> Like anything, there are good and bad ways to do it though. I'd
> recommend distinguishing between class attribute values that are used to
> to apply style, and those used to apply behavior. Its should be clear
> what is being triggered. I'm having some success with using a bvr-
> prefix to any classes that trigger behavior, and never using those
> classes in a stylesheet. Its just convention, but a good one IMO.

Do you apply a namespace to divs you're going to use for behavior and
those you're going to use for presentation?

<bvr:div></bvr:div>

If not, then why would you do it for class names?

> One more thing about inline function calls. I think the original
> example  - onsubmit="return validate(this)" - is indeed pretty well
> separated, and <form class="bvr-validate"> isnt any great improvement.

That's because your'e essentially still defining behavior in the
markup. The idea is to *classify* your forms with class. Your markup
shouldn't be saying "Hey, client-side script, validate me." You might
not even need to use class, if you want it to apply to all form elements.

> each row or cell. Or, frequently, if the markup is generated by some
> serverside process I dont own, modifying it might be entirely out of the
> question anyhow.

Further, why would you *want* to have to modify your server-side
script in order to apply client-side behavior?

> Devils advocate: if I'm trying to update the look and feel here, I may
> have to dig into the javascript to find out what css class is being
> appended to effect the row highlight. I'm a advocate of custom
> attributes for this kind of thing: <table class="bvr-highlightrows"
> rowhighlightclass="over"> or some such.

Your markup will be invalid unless you use a custom dtd. Also, you are
essentially reintroducing both presentation and behavior into the
markup. I don't really see the point of this at all.

<table class="results report">

then maybe your rule is that all report data should have striped rows.
This would be defined in your stylesheet. And maybe all results tables
should have your mouseover effect. This would be defined in your
javascript file. But neither is indicated in the markup, because the
markup has to do with neither.



Btw, you're in the acknowledgments of a Wrox LAMP book that's
in-press. Thanks again for hashing out that AJAX stuff with me on this
list a few months ago.


- --
Matt Warden
Miami University
Oxford, OH, USA
http://mattwarden.com


This email proudly and graciously contributes to entropy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDISOUAQ0d4HGyPE8RAsRUAJ0aPBcO6sfYvGMMkA2JwPSt/E+gkgCfZ6k9
EShU+On26Spz/YXcCyI83m0=
=IrJ4
-----END PGP SIGNATURE-----