Attaching functions to events, from external JS files

[knocte]

Hello.

I am a web developer very worried about "bloat code" and "languages
mixture". So, since some time, I always try to avoid completely the use
of javascript in XHTML/HTML files. This leads to me to hate, also, any
event (onload, onchange, ...) instanciated in the element tag itself, like:

<input type="text" onkeyup="return doSomething();" />

I would replace this code above with an input element marked with an
"id" attribute, and append a JS file to the header with the following
content:

function doSomething(){
[...]
}

function ApplyEvents(){
document.getElementById("mytextinput").onkeyup = doSomething;
}

window.onload = ApplyEvents;
I think that all people who read this would agree that this method is
very smart and gentle.

But it has a very big problem: sometimes, when the XHTML/HTML page is
very large, the ApplyEvents function gets called to late. For example,
when the page is loaded, the user has usually been able to use some
HTML/XHTML controls so as to cause the page to fire some events, but
they are ignored.

I have thought also about using <script> elements just after each tag
element to which I want to apply an event, but I think this is a bit dirty.

Do you know a better method to apply events without mixing javascript
with the markup or using events on the XHTML/HTML source? If I was a
person in charge of suggesting XHTML 2.0 capabilities, I would propose a
new event for the window, for example: onnodeload. This way I could
apply events whenever a new tag has arrived from the server to the
rendering client.

Regards,

Andrew

--

[Jim Ley]

On Fri, 01 Jul 2005 20:50:10 +0200, knocte
<kn****@NO-SPAM-PLEASE-gmail.com> wrote:

I am a web developer very worried about "bloat code" and "languages
mixture".
Why?
So, since some time, I always try to avoid completely the use
of javascript in XHTML/HTML files. This leads to me to hate, also, any
event (onload, onchange, ...) instanciated in the element tag itself, like:
A big mistake, as you've noticed below, if you do not have it in the
code, you have to hide the controls from all users, or accept that
your page is going to behave inconsistently. Why not just accept the
limitations of your medium, and use the sensible methods - your users
will be much happier, and you can develop techniques that work.
<input type="text" onkeyup="return doSomething();" />

I would replace this code above with an input element marked with an
"id" attribute, and append a JS file to the header with the following
content:

function ApplyEvents(){
document.getElementById("mytextinput").onkeyup = doSomething;
}
Using DOM 1 getElementById, to access form elements is a bad idea, DOM
0 (aswell as HTML DOM standard of course) document.forms method, is
considerably better supported.
window.onload = ApplyEvents;

I think that all people who read this would agree that this method is
very smart and gentle.
No, as you note below, it's disastrous, changing how your page behaves
best on onload is simply wrong, it fails the "consistency" rule of UI
- doing the same thing results in the same action.
I have thought also about using <script> elements just after each tag
element to which I want to apply an event, but I think this is a bit dirty.
Sure, the method is intrinsic events as they're called some places,
but they're the things you're trying to get rid of, maybe if you
explain more of your reason for getting rid of them...
If I was a
person in charge of suggesting XHTML 2.0 capabilities, I would propose a
new event for the window, for example: onnodeload.

Why haven't you then? the development of W3 standards happens in
semi-public, members of the Working Group certainly read and respond
to the mailing list. However there's no need for such an event, the
Mutation events already exist which would cover this - if they were
supported anywhere.

Jim.

[knocte]

Thanks for such a quick answer!

Jim Ley escribió:

On Fri, 01 Jul 2005 20:50:10 +0200, knocte
<kn****@NO-SPAM-PLEASE-gmail.com> wrote:

I am a web developer very worried about "bloat code" and "languages
mixture".
Why?

Maintainability reasons. If I set a discipline where programmers can add
many languages or layers/tiers in one file, I will end up with SQL in
ecmascript code. I want to avoid this at all.

So, since some time, I always try to avoid completely the use
of javascript in XHTML/HTML files. This leads to me to hate, also, any
event (onload, onchange, ...) instanciated in the element tag itself, like:

A big mistake, as you've noticed below, if you do not have it in the
code, you have to hide the controls from all users, or accept that
your page is going to behave inconsistently. Why not just accept the
limitations of your medium, and use the sensible methods - your users
will be much happier, and you can develop techniques that work.

Well, I respect your opinion, but I don't agree at this moment (unless
you convince me :) BTW, who are those which you are calling users? The
user of the web page? I think they won't bother about that.

Besides, taking your argument to the last consequence, we could state
that any javascript code outside the XHTML/HTML document (via <script>
elements) is evil.

<input type="text" onkeyup="return doSomething();" />

I would replace this code above with an input element marked with an
"id" attribute, and append a JS file to the header with the following
content:

function ApplyEvents(){
document.getElementById("mytextinput").onkeyup = doSomething;
}

Using DOM 1 getElementById, to access form elements is a bad idea, DOM
0 (aswell as HTML DOM standard of course) document.forms method, is
considerably better supported.

I know that older specifications are always more compatible. But my web
knowledge has led me to behave with the following rule:

- Make webs with javascript non required, so as to allow absolutely
obsolete or simple browsers.
- If javascript is used, assume that I am dealing with a very modern one.

Using this technique I think I succeed very well at my everyday work.

window.onload = ApplyEvents;

I think that all people who read this would agree that this method is
very smart and gentle.

No, as you note below, it's disastrous, changing how your page behaves
best on onload is simply wrong, it fails the "consistency" rule of UI
- doing the same thing results in the same action.

I think you are too proud to discuss about technology. I would never say
such subjective and rude terms in a technical discussion. Perhaps my
point is bad, but we are here to talk about it, not to make FUD's.

Of course, knowing the issue I have announced in this newsgroup, one
could say I don't design correct UI's, but what happens if I told you
that I use transition layers in my framework (div's with "LOADING..."
labels that get replaced with the UI when the page is loaded, and then,
when the onload event has already been called). Then you could answer:
so why did you ask this if you already had a solution? Because I want to
know if anyone else have other solutions (worse or better) to this issue.

I have thought also about using <script> elements just after each tag
element to which I want to apply an event, but I think this is a bit dirty.

Sure, the method is intrinsic events as they're called some places,
but they're the things you're trying to get rid of, maybe if you
explain more of your reason for getting rid of them...

I want to make a clean piece of software, where javascript is placed
only at one place and not at many places, I want a software that is easy
to change. I want a software that allows me to think that if I want to
change the client scripting, I will edit a .js file. I hope you
understand me more now.

If I was a
person in charge of suggesting XHTML 2.0 capabilities, I would propose a
new event for the window, for example: onnodeload.

Why haven't you then? the development of W3 standards happens in
semi-public, members of the Working Group certainly read and respond

Hehe, I already knew this, but I wanted to pass, firstly, the filter of
the javascript newsgroup :D
to the mailing list. However there's no need for such an event, the
Mutation events already exist which would cover this - if they were
supported anywhere.

Mmmm, could you point me to any URL about this?

Anyway, my wish would be to find a solution to this which was already
supported by most ecmascript interpreters.

Regards and thanks again for your help.

Andrew

--

[Jim Ley]

On Fri, 01 Jul 2005 21:32:40 +0200, knocte
<kn****@NO-SPAM-PLEASE-gmail.com> wrote:

Maintainability reasons. If I set a discipline where programmers can add
many languages or layers/tiers in one file, I will end up with SQL in
ecmascript code. I want to avoid this at all.
Do you also keep all your HTML and CSS out of your script files? This
really starts to be difficult, you have to have all content you might
want to add in the main page, which makes fallback very difficult with
the non-script or CSS browsers.

Also of course, you have the <script> and <link> elements in the HTML,
so there's no genuine true seperation. If we could have true
seperation, without compromising on the usability issues, then I'd
agree with you, we should keep them seperate, but the compromises are
too severe.

A big mistake, as you've noticed below, if you do not have it in the
code, you have to hide the controls from all users, or accept that
your page is going to behave inconsistently. Why not just accept the
limitations of your medium, and use the sensible methods - your users
will be much happier, and you can develop techniques that work.

Well, I respect your opinion, but I don't agree at this moment (unless
you convince me :) BTW, who are those which you are calling users? The
user of the web page? I think they won't bother about that.

UI consistency is one of the key principles, if typing in a box does
something, it should always do the same thing, it shouldn't only do
that thing after page load.

For me, Google has javascript disabled because it doesn't understand
that onload is too late to do something, and google's a tiny page to
download, but with script enabled, I get inconsistent behaviour.
Besides, taking your argument to the last consequence, we could state
that any javascript code outside the XHTML/HTML document (via <script>
elements) is evil.
How so? Certainly you need to be careful that your document still
functions if any remote resources fail to load (so you need stub
functions or to check in your intrinsic events), however there's no
consistency change, the document works the same way, in the same
instance. I agree there's a potential problem if the user reloads and
this time the external resource succeeds whereas it previously failed,
but that's not a big risk, and I don't think the monolithic page is a
good response to that.

Remember my arguments are about pragmatism in working with what we
have, rather than some ideal model.
- Make webs with javascript non required, so as to allow absolutely
obsolete or simple browsers.
An excellent idea, however the script above would just error in many
browsers - script errors popping up are not a website that's working,
and certainly are a bigger issue than mixing languages in a page?
I think you are too proud to discuss about technology. I would never say
such subjective and rude terms in a technical discussion.
Rude? I'm sorry you were offended, but I don't get what offended you,
lack of UI consistency is a problem, a big problem, you recognised it
yourself, it's why you posted!
Of course, knowing the issue I have announced in this newsgroup, one
could say I don't design correct UI's, but what happens if I told you
that I use transition layers in my framework (div's with "LOADING..."
labels that get replaced with the UI when the page is loaded, and then,
when the onload event has already been called).
The problem with these approaches, which do get around the consistency
issue, is that they fail the fallback issue - how do you both show the
message, and leave the page working for people without sufficiently
advanced script supported?
I want to make a clean piece of software, where javascript is placed
only at one place and not at many places, I want a software that is easy
to change. I want a software that allows me to think that if I want to
change the client scripting, I will edit a .js file. I hope you
understand me more now.
The problem here is that you don't really get that what you're
replacing is a dependancy in the script on "onclick='something()'"
with a dependancy on an ID, is there really that much independance
between:

<h1 id="chicken" ... >
<h1 onclick="chickenClicked()" ... >

Sure, you could attach other events to the first one than onclick, but
that's all, if you decide you want to change which element you want to
respond to a click you still need to change the HTML.

There are good future technologies for this, particularly XBL, where
you truly can seperate the behaviour from the mark-up, but we don't
have it yet, I don't think it's a good idea to compromise on the
usability of your application.

to the mailing list. However there's no need for such an event, the
Mutation events already exist which would cover this - if they were
supported anywhere.

Mmmm, could you point me to any URL about this?

<URL:
http://www.w3.org/TR/DOM-Level-2-Eve...mutationevents Anyway, my wish would be to find a solution to this which was already
supported by most ecmascript interpreters.

There isn't one :-) there's better than onload available in some,
there's exactly what you want for IE if behaviors are enabled (but
they have a whole raft of other problems), but in general there's
nothing that will give you what you want.

So your solutions are, leave inconsistent UI's around.
Try and solve the "loading..." methods problems with fallback when
CSS/javascript is unavailable weakly supported.

Jim.

[VK]

The external event listeners' issues were discussed many times here.
You nay want to read this (and similar - use "event" keyword to search;
I just couldn't pass the opportunity to post this link w/o formally
top-posting :-)
<http://groups-beta.google.com/group/comp.lang.javascript/browse_frm/thread/083ed9630b81dee9/cd81fab7ffdfadd7?hl=en#cd81fab7ffdfadd7>

The ergonomics studies tell us that users prefer to wait longer but get
the final result "in one chunk" rather than to be forced to see the
creation process.

In the partucular, they would prefer to see "Loading..." sign as long
as it's needed, but when the form appears, it should be fully usable
from the very first moment. They would be disturbed by a form that
appears part-by-part but is not fully usable until the last part
arrived. It's a side-effect of the common human behavioral template:
"If you can give it to me, then *give* it to me. Otherwise don't show
it to me".

So in your approach I would suggest to stay on "onload" event to attach
all needed events and *to display* the form only after all preparative
works are done.

[Danny]

Both inline/explicit event handlers and implicit/indirect ones are
necessary, one no more important than the other, each has their own use,
your opinion is understood and noted, however is just opinion and as
entitled as you may be, doesn't quite equate to practical for most
scenarios. If you are on server end, you can have the server language put
it inline, if you don't like it inline, you have have js do it indirect
binding by means of a function per parent on children bubbling or per node
itself by using IDs. As for the onnodeload, onload on the body takes care
of the whole document being loaded, not just the node, as your plight on
the user being able to click on an event, well, that is something YOU as
programmer should address, as it's simple to do, and no try to pass the
buck to the API. As for the 'evil' call on code outside the <script>
section, well, even though in tags, is technically seen even by html as
js, not html. You need a centralized system for the object handling, and
is understood for your UI, but as much as I dislike to quote donald
rumsfeld on his buck-passing response a while ago, "you go with the army
you have, no the one you wish you had or the one you think you should have
had".

I think you're already using the optimal technique for your Divs and UIs,
as for the user clicking anywhere, you just need code it to not do so and
do use inline event handlers, they're there to help you, not to take you
astray.
Danny
On Fri, 01 Jul 2005 11:50:10 -0700, knocte
<kn****@NO-SPAM-PLEASE-gmail.com> wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/