Help Jquery: unable to register a ready function

Discussion in 'Javascript' started by souporpower, Oct 28, 2008.

  1. souporpower

    souporpower Guest

    Hello All

    I am trying to activate a link using Jquery. Here is my code;

    <script type="text/javascript" src="../../resources/js/
    jquery-1.2.6.js"> </script>

    <script language="javascript" type="text/javascript">

    $(document).ready(function(){ $('.mylink').click(function()
    { $.jPrintArea('#tabularData') }); });


    var iframe=document.createElement('IFRAME');

    var doc=null;




    var links=window.document.getElementsByTagName('link');

    for(var i=0;i<links.length;i++)

    doc.write('<link type="text/css" rel="stylesheet" href="'+links.href

    doc.write('<div class="'+$(el).attr("class")+'">'+$(el).html()+'</







    <div id="tabularData">
    <a href="#" class="mylink" name="mylink">Print this Table</a>

    When I click on the link I see nothing. I am expecting to see an
    alert. Could someone please tell me where
    I am going wrong?

    Thanks for your help. Sorry I am unable to post the code on a web
    souporpower, Oct 28, 2008
    1. Advertisements

  2. souporpower

    David Mark Guest

    Trying to do what? And you can't do anything useful with jQuery.

    You forgot the doctype.
    Remove this.
    This is the sort of mangled syntax that the jQuery crowd thinks "makes
    JavaScript bearable?" This is complete nonsense and about as
    inefficient as it gets. And BTW, their "ready" method is known to be

    Yes. You clearly want to add scripting to your site, but do not know
    how. You heard that jQuery would make it really easy and you won't
    have to learn anything about ECMAScript, cross-browser issues, etc.
    Just wind it up and watch it go, right? It won't work. Yes, lots of
    pundits on blogs say it works, but they don't know what they are
    talking about.

    See the FAQ for some basic examples. That is the best place to start.
    David Mark, Oct 28, 2008
    1. Advertisements

  3. souporpower

    souporpower Guest

    You are right. I can't agree with you more. I found the following
    vanilla javascript to be working
    perfectly. For the benefit of some, I am posting it here. I am
    convinced Jquery is not for me. Thanks

    var iframe; //global
    function printArea (el) {
    var doc=null;'0px';'0px';
    var innerhtml = document.getElementById(el).innerHTML;
    doc.write('<html><body><div>'+innerhtml +'</div></body></html>');


    And it is called as printArea('mydiv') where mydiv is the div tag
    wrapping around some html.
    souporpower, Oct 29, 2008
  4. souporpower

    RobG Guest

    You seem to be making iframe global so you can call it from setTimeout.
    You don't have to do that, you can use a closure instead.

    There is rarely any need to initialise a variable with null if you are
    going to set its value later. Just declare it, its value will be
    undefined, which is more-or-less equivalent to null.

    Now you've assigned a value to doc, the previous assignment did nothing
    useful. It's not really an issue, just that you didn't need to assign
    it a value of null.

    To use a closure so you don't need the global variable, try:

    setTimeout(function(){document.body.removeChild(iframe)}, 5000);

    Untested, but should be OK.
    div element. :)
    RobG, Oct 29, 2008
  5. souporpower

    Matt Kruse Guest

    You forgot the wink: ;)
    Perhaps intentionally. (For example, when inserting code into an
    existing product or service with no doctype, it's best to test without
    a doctype).
    No. His formatting was terrible. I would write it like:


    ah, yes. Much better.
    Really? Under what conditions? Where would someone locate a more
    reliable method of determining when the DOM is ready?

    Hope that helps!

    Matt Kruse
    Matt Kruse, Oct 29, 2008
  6. souporpower

    David Mark Guest

    Why would I wink about that? It is a proven fact. You just have a
    (very) short memory.
    Oh, I am sure that was the intention.
    Formatting?! What does that have to do with anything?
    Much better than what? Look at that BS. Create a big jQuery object,
    which is known to have problems with its own arguments (typeof a ==
    'array', isFunction, etc.) due to an incredibly ignorant design, then
    discard a big jQuery object. Create a big jQuery object, discard a
    big jQuery object, create a big jQuery object, discard a big jQuery
    object, etc., etc. That's how all of the pathetic examples for this
    library read. It encourages people to be as inefficient as possible.
    And how many functions are called by the above "better" example?

    And you already know about the browser sniffing and the all-around
    incompetence of the author.

    That one is my personal favorite, next to the time he asked me for a
    "magic flag" to feature test get/setAttribute. Yes, I gave it to him,
    but I think he had fled back to gumdrop-land by then.

    Though for comic relief, you can't beat this one:

    What kind of idiot would delegate the most critical browser scripting
    tasks to people like that? In 2008 no less?! And we just had this
    discussion a year ago. Did you fall on your head since?

    I take it you like to write "plug-ins" for jQuery. How
    irresponsible. Are we to congratulate you for volunteering to help
    the helpless? Of course not. You are serving up poison in a soup

    I gather you like being a Big Fish in a very shallow pond.
    Google? This group? I have personally published such methods. Peter
    has a Blog entry on the subject. Perhaps you were too busy with the
    special needs class to notice.
    In a way, I think it did. Care to help dispel any more myths about
    jQuery? You do that inadvertently every time you open your mouth in
    David Mark, Oct 29, 2008
  7. souporpower

    Matt Kruse Guest

    I do useful things with it all the time. That seems to falsify your
    theory. *WINK*
    Ignorant design = true
    Problems = Only if you hit the cases where problems might exist, and I
    never have except in theory.
    Computers are fast. Don't optimize just because you feel bad for them
    having to work so hard.
    There are certainly cases where using jQuery hinders performance.
    Don't use jQuery in those cases.
    For many problems, jQuery is an inadequate solution.
    Don't use jQuery to solve those problems.
    That's some revolutionary thinking right there.
    Yes. Exactly 3000.
    Delegating the most critical scripting tasks to jQuery may be a
    mistake. I use it mainly in controlled environments. Mostly to add
    some UI enhancements and to show pictures of bunnies.
    I have. My motivation for doing so is probably quite different than
    what you imagine.
    It's surely right up there with smoking while pregnant and eating live
    puppies, both of which I have also done. I like to live on the edge.
    [Insert one-up kitchen analogy here]
    [Insert one-up pond analogy here]
    I haven't read this group regularly for a while.
    Consider using more descriptive words, like "open your big fat mouth".
    It will help you to connect with your audience. HTH!

    Matt Kruse
    Matt Kruse, Oct 29, 2008
  8. souporpower

    David Mark Guest

    Useful according to whom?
    Christ on a crutch. You don't have to have empirical evidence. Look
    at the code. You know it won't work on anything but a handful of
    modern browsers in their default configurations. You know this, yet
    you persist with these sorts of "arguments." You want to be
    Computers are fast?! That is your argument for using such inane and
    inefficient patterns? EVERYTHING IS RELATIVE. Tattoo that on your
    And there are certainly cases where incompetence hinders productivity.
    You had something there, but you stopped three words too late.

    You misspelled "any and all."
    It is yours after all. Your assumption that people who use jQuery to
    shield themselves from the intricacies of cross-browser scripting
    would be in a position to judge what would be a problem for jQuery is
    patently absurd. These people don't know what they are doing. That
    is why they chose jQuery in the first place.
    At least 2998 too many.
    Oh, I see you wrote a "context menu" plug-in for jQuery. A popup menu
    hard-wired to work only with the alternate mouse button? And it
    requires jQuery to work? Whatever your motivation, you are not
    Advocating a blob of incompetently written, poorly designed, *browser
    sniffing* script in 2008 is completely off-base. Your reputation can
    join Resig's in the toilet. No amount of stupid asides can change
    See next line.
    And you apparently forgot everything you learned previously. We just
    had this exact discussion a year ago. What are you in self-imposed
    exile ever since?
    Consider what a foolish post this was.
    David Mark, Oct 29, 2008
  9. souporpower

    Matt Kruse Guest

    Me. Why would I care if it's useful to you or anyone else?
    Your argument is that it will fail under some cases. My argument is
    that those cases don't matter to me. Your argument is theory, mine is

    I'm doing X, and you're arguing that it can't do Y. Odd.
    And I'm okay with that. You seem to think that if a person finds
    jQuery useful, then they must advocate its use on all web sites for
    all needs. That's not the case. jQuery is a tool. I use it for what it
    is useful for. I do not use or advocate it for situations where it is
    not useful.
    It is actually not as ridiculous of a strategy as you make it sound.
    A data warehouse, for example, is a very inefficient pattern as far as
    data storage is concerned. Keys duplicated, many rows, etc. If all you
    care about is data integrity and storage, you might say it is a
    terrible implementation. But if you use different criteria, it may
    become the best solution.

    A pattern that is less efficient to run, but more efficient to write
    and maintain, yet runs with an imperceptible loss in performance, can
    be considered a success.
    I'm quite familiar with Einstein. We can discuss that if you'd like.
    One of my favorite topics. Tattoos, not so much.
    Your extreme bias against jQuery makes your argument less compelling.
    I find that most intelligent people are less extreme and more
    That is your absurd assumption.
    Your inability to think outside your box is amusing.
    If you haven't noticed by now, I couldn't possibly care less what you
    or anyone else thinks of my opinions on jQuery.
    I'll keep trying.
    Ummmmm, not really.
    Indeed it was, but I forgive you. You can try again.

    Matt Kruse
    Matt Kruse, Oct 29, 2008
  10. souporpower

    David Mark Guest

    No. You advocate the use of jQuery on the Web. That is pure folly.
    Who knows what you are doing? Doesn't really matter. If it is
    browser scripting and involves jQuery, then you are doing something
    foolish. Intranet or not.
    But that is where you see jQuery (all over the public Internet.) This
    is largely because jackasses like you are handing out bad advice (like
    these last few posts.)
    It is not useful for anything but deluding yourself (and your clients)
    into thinking you are competent to do cross-browser scripting.
    Completely ridiculous. "Computers are fast" so it is okay to waste
    all of their resources. Who are you now, Bill Gates? Try using any
    of your jQuery apps on an older PC. You can literally hear the
    incompetence in the whirring fans.
    Data normalization and de-normalization is OT (and irrelevant) here.
    You are off in the weeds.
    You have completely lost it. There is nothing about using another
    person's browser sniffing monstrosity of a script that will make for
    easy maintenance. And who cares if it is easier to write if the end
    result is a maintenance nightmare?
    Okay, write it in black magic marker on your hand, then smack yourself
    in the forehead.
    Prototype, jQuery, MooTools, etc. are all fruits of the same poison
    tree. I am hardly alone in this determination.
    Most intelligent people would find your "arguments" to be non-
    arguments. It is like talking to a wall.
    Of course not. It's the library that "makes JavaScript (sic)
    bearable." Articles about it always start out: "I used to *hate*
    JavaScript, then I discovered..." To finish their thought, they
    discovered that they could create really lousy, inefficient scripts if
    they let somebody else's large, lousy and inefficient script do all of
    the work. Nobody with experience would consider this a worthwhile
    Outside my box? What you were after was a popup menu. I published
    one here a full year ago. And yes, it had an optional context "plug-
    in" (optional script) and "themes" (alternate style sheets.) It even
    works with XHTML (try *that* with jQuery.) And last, but not least,
    it does not require 50K of jQuery code to work. Certainly it couldn't
    be easier to implement and maintenance will likely be non-existent for
    a long time (unlike your browser sniffing "plug-in.")
    And I don't care what you think about my opinions, but I will not let
    you spread half-truths and outright falsehoods here. There is enough
    blithering on the blogs.
    And you will keep failing. The pattern is not hard to spot.
    David Mark, Oct 29, 2008
  11. souporpower

    David Mark Guest

    A tool for what?
    Like what? A mockup? I wouldn't even recommend them for that.
    Or in the case of many, the code may be incompetently written and
    therefore a waste of time.

    And yes, the designs are absurd for browser scripting.
    Yes, it is a crock.
    And at least one of the two is demonstrably false. The other looks
    like nonsense too.
    It isn't a case for anything.
    LOL. And there you have it.
    It is far worse than a hasty conclusion. The idea that you cannot
    feature test IE's broken getAttribute has been proven false by me in
    this newsgroup a long time ago. And that pinhead was a participant in
    the thread. (!) So why hasn't he retracted this rubbish?
    Neither of you got it. Re-read that "quirk report" again.

    The moral of the story is that even if people like John Resig had the
    slightest idea what they were talking about, browser detection would
    still be useless. If you read between the lines, you will see why
    they think they need it. Needless to say, their fundamental mistake
    has been discussed to death here.
    David Mark, Nov 4, 2008
  12. souporpower

    David Mark Guest

    That is inexperience talking.
    Yes, you can feature test that.
    Not like that!
    You have the basic idea.
    LOL. No need for browser sniffing there.
    That can (and should) be designed out of any system.
    Nope. Not the user agent string. Try thinking about these issues a
    little harder.
    David Mark, Nov 4, 2008
  13. souporpower

    David Mark Guest

    A better solution to using outerHTML? How about anything?
    Depends on the context. As I have worked on numerous projects that
    use transparent PNG's as widget decorations, I have had to work around
    the same IE6 nonsense that you have. Never once have I had to stoop
    to browser sniffing. The simplest solution is to provide GIF
    equivalents and override the the PNG's in the inevitable IE6-specific
    style sheets. And those are typically hidden with IE conditional
    It can't be inferred from the user agent string either. Best to
    design it out of the system (whether you agree or not is another
    That's what browser sniffing uses to "check the browser version."
    Thin ice, Conrad. Very thin ice. You are clearly new and very
    impetuous. Try reading more and writing less.
    Fierce of hatred of who?! I don't know him at all. His code is awful
    The ice just broke. Try a little research before opening your mouth.
    It will save a lot time and embarrassment. You are currently
    following in the footsteps of Matt Kruse, circa a year or so back.
    David Mark, Nov 4, 2008
  14. souporpower

    Matt Kruse Guest

    Not necessarily. Depends on your definition of "sniffing".
    Using IE conditional comments is one alternate approach.

    Matt Kruse
    Matt Kruse, Nov 4, 2008
  15. souporpower

    David Mark Guest

    IE conditional comments are not sniffing per se. And they are
    absolutely the best way to include the handful of CSS corrections that
    are virtually always required for older versions of IE (e.g.
    proprietary rules like "zoom:1".)

    They can be abused though. Do not use conditional comments to load
    script that makes assumptions about IE's host objects based on the
    browser version.
    David Mark, Nov 4, 2008
  16. souporpower

    Matt Kruse Guest

    Semantics. You can define it however you wish.
    In theory, it is no more reliable than a user-agent string. Any
    browser could choose to process code within IE's conditional comments.
    Just as any browser can choose to fake a user-agent string.

    Can you really assume CSS behavior based on a browser's evaluation of
    conditional comments? Isn't that quite a leap?

    You rely on one potentially-broken approach, but not the other. Why?
    But you can make assumptions on PNG support from conditional comments?
    What if a user has a custom extension in their version of IE6 that
    allows PNG files to work correctly? Oh, SNAP!

    Matt Kruse
    Matt Kruse, Nov 4, 2008
  17. souporpower

    David Mark Guest

    Nonsense. It is clearly not browser sniffing.
    That is where you are wrong.
    But since there is no benefit for them to do so (unlike spoofing UA
    strings), they don't.
    Certainly not. It is the best practice for fixing IE6's silly quirks
    (primarily by using rules that are proprietary to IE.)
    One is easily demonstrated as baseless, the other is not.
    Oh what? They would still get the GIF's. Wouldn't hurt a thing. See
    how that works?
    David Mark, Nov 4, 2008
  18. souporpower

    Matt Kruse Guest

    If you restrict sniffing to only looking at the user-agent, then I
    suppose you are right.
    I agree that it is more reliable in practice, but not in theory.
    So you're going to assume it's a safe tactic because, according to
    your knowledge, no browser is currently doing it?
    What if I wrote a browser that used IE's parsing/js engine but my own
    CSS logic? It might evaluate conditional comments, but not follow the
    CSS quirks that you are inferring. The point is, you are making an
    assumption about some behavior (css quirks) based on something
    entirely different (support for conditional comments evaluation).

    In my experience, I've never come across a browser that faked it's UA
    string and caused a problem for the user. So by your logic, can't I
    assume it is a safe practice?

    [snip the rest due to boredom]

    Matt Kruse
    Matt Kruse, Nov 4, 2008
  19. souporpower

    David Mark Guest

    Why do you feel the need to tell me that? Assume whatever you want.
    I didn't care for any of it. Thank you.
    You have no point at all. You can't feature test the color shirt the
    user is wearing either. Sheesh.
    Nothing ugly about it. Supporting alpha transparency (or not) does
    not affect a single design of mine. Yours?
    You don't have to "test for IE versions" in your script at all.
    That's the point.
    Conditional evaluation? I think not. If you mean conditional
    compilation, wrong again. I would never put that into the library as
    (for one) it screws up the YUI minifier. Perhaps you are thinking of
    an add-in? Sure as hell doesn't "check the IE version" either. Could
    you get any more off-base than to lecture me on my own code?
    His incompetence is easily discerned from his numerous books, blog
    posts, scripts, etc. Opinion seems to be divided here. Everybody
    else says it is so, you and Matt Kruse say it isn't (though Matt seems
    to have finally realized that Resig is not worth listening to.)

    And yeah, I have talked to him. It is a matter of public record. He
    is an idiot. Read more, write less.
    The ice under your feet, genius. As in, you had no argument at all.
    All of the blithering that followed was the usual waste of time, which
    was clearly followed by the inevitable epiphany.

    If I really cared to help you, perhaps I would have suggested some
    search terms (e.g. "browser scripting" library.) Looks like #1, #2
    and #4 respectively on Yahoo, Google and Answers. Looks like you
    figured it out on your own. There's a good fellow.
    David Mark, Nov 4, 2008
  20. The point that you are still missing after all these months I already tried
    to explain it to you is that your theory is flawed.

    Using Conditional Comments does not break anything because when it is not
    regarded as a special processing instruction (as by MSHTML, or a
    deliberately borken UA if it can't handle it properly) it is regarded an
    SGML/HTML/XML comment and goes *ignored*, plain and simple. IOW, when a CC
    fails you do *not* do anything.

    Much in contrast, using browser sniffing and sniffing to the wrong effect is
    inevitably harmful because you end up *doing* things that you did not
    intended to do in the UA that you did not know to spoof you successfully
    yet. And you will have to adapt your code each time it happens to handle
    that case, *after* some kind soul *might* have told you that your code
    messed with their UA. I hope you can agree that being aware of those issues
    and continue sniffing anyway (unless it is *absolutely required*) is just
    plain stupid.

    Thomas 'PointedEars' Lahn, Nov 4, 2008
    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.