Attaching functions to events, from external JS files

Discussion in 'Javascript' started by knocte, Jul 1, 2005.

  1. knocte

    knocte Guest


    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

    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.



    knocte, Jul 1, 2005
    1. Advertisements

  2. knocte

    Jim Ley Guest

    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.
    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.
    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.
    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...
    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 Ley, Jul 1, 2005
    1. Advertisements

  3. knocte

    knocte Guest

    Thanks for such a quick answer!

    Jim Ley escribió:
    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.
    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
    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.
    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 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.
    Hehe, I already knew this, but I wanted to pass, firstly, the filter of
    the javascript newsgroup :D
    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.


    knocte, Jul 1, 2005
  4. knocte

    Jim Ley Guest

    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.
    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.
    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.
    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?
    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!
    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?
    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

    <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.
    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 Ley, Jul 1, 2005
  5. knocte

    VK Guest

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

    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.
    VK, Jul 1, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.