Your problem in this case is that you need to get the computed style. Try this:

getStyle(document.getElementById('imgid'),height);

It will work on load using the following function:

/* retrieve the computed style of an element */
function getStyle(element,property) {
    var camelProperty = property.replace(/\-(\w)/g, function (strMatch, p1){ return p1.toUpperCase(); });

    var value = element.style[camelProperty];
    if (!value) {
      if (document.defaultView && document.defaultView.getComputedStyle) {
        var css = document.defaultView.getComputedStyle(element, null);
        value = css ? css.getPropertyValue(property) : null;
      } else if (element.currentStyle) {
        value = element.currentStyle[camelProperty];
      }
    }
    return value == 'auto' ? '' : value;
}

The additional problem with using the CSS values to determine sizing is that it doesn’t necessarily return a numeric number. It could just a easily be a percentage, or a non pixel number (12em). Yo may want to use properties such as offsetHeight though it not part of the DOM spec.

That aside, you are correct, I shouldn’t use the term ‘Never’ as per your other arguments with the yahoo research.

Thank you for the link. I’ve read over the stuff and I think I’ll amend my statement to remove “there is never a valid need” to just “there is never a need” since there are valid reasons (as you’ve shown) when mixing the two might be considered acceptable. However, I still maintain that there is no “need” here, the application will run just fine with a clean separation, even if it is slightly slower.

“This advice is as dated as demanding that everyone allow for a rich experience with Lynx, or design for a 640×480 screen. Arguments about how the scripting doesn’t improve the site, blah blah, are factless distractions — it’s a case by case decision, and universally saying that script-requiring sites are bad is inane.”

I think that if the commenter had read the other rules instead of flying off on a flame they might discovered that I also say don’t expect that every visitor get the same experience, just a functional one. I don’t expect people to avoid JavaScript because Lynx doesn’t do it, I simply expect that — if engineered correctly from the start — an alternative method for accessing the content can be given to these visitors.

“Oh it’s just 10% of people who don’t have JS, so screw ‘em!” is a very amateur thing to say. Sure millions of sites on the net use exactly that method, but the ones at the top (GMail etc) provide alternative interfaces for their fringe users. They aren’t as pretty or rich. They aren’t as easy to use and definitely don’t feel like desktop software… but they DO work, and they get the job done.

http://yuiblog.com/blog/2007/01/04/performance-research-part-2/

I shows the break down of what elements are sent to the user and when. Now it is a study on empty cache vs full cache, but the results are quite surprising.

The first phase was of regret. I used to document up a storm via comments in the old programming language I used for work. (Don’t ask, it wasn’t pleasant…) When I switch jobs, and languages concurrently, I fell out of the habit. Yeah, I can partially blame the team environment which didn’t stress/emphasize the commenting, but I am a member of that team and could have helped to modify that stance. Lately I have been trying to influence the lack of comments through some coding metrics (JavaNCSS) and publishing the results.

The second phase was one of contrarianism, spurred on by Peter’s comments. I am a HUUUGE fan of automated testing. One of the coolest ideas I ever came across was that though comments may become stale, tests (especially in a Continuous Integration environment) will serve as living comments.

Ideally, I would love to see both good comments, and tests serving as living documentation. On my team, I am striving for that ideal state, but in the meantime our tests will have to do…

This article is a SHORT PRIMER. I could easily have written a full 2000 word feature on any of these topics individually, and may do so in the future (the comments here are inspiring). Keep in mind that it’s impossible to cover all aspects of an issue in 3 paragraphs (or less) and I agree with Matt when he says “In programming never say never.”

In this case I define “never” as “Don’t break one of these rules without another developer on your own team backing up the decision”… which fits nicely with rule #10 :^)

I had no idea you were reading this too! (Pete was a roommate of mine at UW).

I know we’ve argued this exact point in the past and I agree in theory with many of your arguments.. things like having exceptional comments stand out, using smaller helper functions instead of bigger ones and having the small ones self-document. I agree and that is an alternative practice that can be equally good, and it would be excellent in a system modeled on MVC especially. In top-down script design I still favour my proposed #7.

On your “comments lie and 80% is maintenance”, that is true for applications like those you work on. In our case 90% of the scripts we write are written, tested, tweaked, delivered and forgotten. The clients are almost always happy with things as they end up on delivery. The problem arises two years down the road when they want a small change and someone new goes in to make the modification. Provided they ALSO keep the comments current, it does help greatly to use my method (as we’ve Proven at We-Create). Your method might help equally well however.

1. Your business logic is now perfectly obvious, so much so that I removed its description from the function header description due to utter redundancy.
2. Your business logic function doesn’t use any global variables.
3. Your global variables are declared next to the code that uses them (PS: is $conn global or not?)
4. You now have some helper routines for dealing with OTTs in the future, to pre-emptively get rid of code duplication.
5. You don’t need any comments inside functions; the comments became the function names. You might want to put in descriptions of the parameters and return values, but it’s not ultra-critical.
6. It’s obvious which parts of the code use the OTT itself, and which use its database values. This was particularly non-obvious in your original code (I didn’t notice the extract() at first, and had to go rewrite some of this).

The get_ott_data function is a bit ugly in how it’s used, but I didn’t feel like writing a OneTimeTicket class or anything crazy.

Reasonable people could disagree on this, I suppose. But 80% of programming is maintenance, and my experience maintaining large programs is that comments lie, large functions are buggy, and small functions let you skim code faster and see what’s going on. Plus if you save comments for the truly exceptional, weird situations, then they really stand out and you don’t gloss over them.

We’re usually paying attention to this blog in the morning and evenings.. between we’re busy writing software so please don’t take offense.

I’d love to see this article from Yahoo. Can you post a link? Until you can back up the numbers I’m going to reserve judgment entirely, as you are arguing quite well.

Your points above are valid and they even jive with rule #2 which in a nut shell says: if something has to be either hard on the user or hard on the developer then it should always be hard on the developer since we have an easier time understanding why, and the phone rings less

Compare your function to:

/**
 * Validate the authenticity of a 32-character MD5 one time ticket.
 *
 * Used primarily in the login function before comparing hashes sent by the user.
 *
 * @param resource $conn The connection to the database
 * @param string $ott The one time ticket hash
 * @return boolean true if valid, false otherwise
 * @author Cam Turner
 * @see http://en.wikipedia.org/wiki/Cryptographic_nonce
 */
function validate_one_time_ticket($conn,$ott) {
    if (!check_type($ott,'MD5')) { return false; }

    $ott_data = get_ott_data($ott);

    if ($ott_data == array()) { return false; }
    if (!consume_ott($ott)) { return false; }
    if (is_ticket_expired($ott_data) { return false; }    

    return true;
}

function get_ott_data($ott) {
    global $conn;
    $query = db_query($conn,"SELECT * FROM one_time_tickets WHERE one_time_ticket='$ott'");
    if ((!$query) || (db_numrows($query) != 1)) { return array(); }
    return db_fetch_array($query,0);
}

function consume_ott($ott) {
    global $conn;
    $query = db_query($conn,"DELETE FROM one_time_tickets WHERE one_time_ticket='$ott'");
    return !!$query;
}

function is_ticket_expired($ott_arr) {
    global $AUTHENT_CONFIG;
    $ttl = $AUTHENT_CONFIG['ttl']; // integer seconds
    $expiry = strtotime($ott_arr['time_issued']) + $ttl;
    $now = time();
    return ($expiry < = $now);
}