The pixel computations are done because of the way this is used in the calendar. When a user resizes the event, some kind of pixel computation is going to happe

The pixel computations are done because of the way this is used in the calendar. When a user resizes the event, some kind of pixel computation is going to happen at some point, since mouse coordinates have to be transferred in some way to "left" and "top" offsets (perhaps by first translating to the start time and end time abstractions). This was probably the dirtiest part in that respect, as it is the point at which I chose to translate between pixels into usable data. It's a helper function, so to speak, so I don't have to deal with any of this in my more general abstract code (which does indeed follow the much more "clean" approach). Hence the underline before the method's name. :) (this is part of an object) 1. I agree, but they're tiny inline functions so that's why I did that. I'll refrain from doing that from now on as this seems to be a general consensus. 2&3. Aah, good point. I just went back and looked at an old JS project and noticed I was doing both of these properly with parseInt. I've forgotten though as I haven't done too much heavy Javascript for a while before this. Thanks so much! 4. I've used call before like that but for some reason I forgot about it and switched to apply. Thanks! 5. Ok, that's what I wondered. The comments so far seem to agree this would be better for readability. I don't plan on anyone else even touching this code, so indeed like someone else suggested that could be an important factor, as indeed if this wasn't a personal project I would've used a more orthodox (i.e., less compressed) approach. That's exactly what I was looking for. Thanks! EDIT: Also, if I used "day" and "halfHour" attributes they would be hardcoded. Maybe someday I'd like to change to hour blocks, or have a view in four-hour blocks instead of half-hour. I am using this object as an abstract class that handles a calendar view, which will be passed specifics for the view. For example, the day view will be initialized like this: arguments.callee.$.__init.call(this, {timeblock:1800, rows:48, cols:1, timedir:0, startTime:startTime, timename:'day', container:'daycontainer'} ); Where the "arguments.callee" stuff is just calling the (inherited) superclass initialization function. This way, if a New World Order appears and ever decides to make 5-day instead of 7-day weeks, all I have to do is change one line of code. ;) (while that's true, the real reason for me doing this is so I don't have to write code 3 times for a day, week, and month view) That's (partially) why I didn't do something like hardcode "day" or "halfHour" attributes (although I do store all this information in the object--the method I showed above is a computational helper function).