Posts

Showing posts with the label onload

Object.defineProperty - A Missed Opportunity

Just a quick post about some clever hack we should probably forget ... make old scripts less obtrusive using new ES5 features. I am talking bout those guys out there that use scripts with a classic: onload = function () { ... }; // or this.onload = ... // or window.onload ... // or self.onload ... // etc etc Apparently WebKit Nightly fires an error when we try to define getters and setters via Object.defineProperty and this is already enough to remove that "hoooraayyyy" for my silly test .... here the code: Object.defineProperty(this, "onload", (function (self, callback) { function onload(e) { while (callback.length) { callback.shift().call(self, e); } } self.addEventListener ? self.addEventListener("load", onload, false) : self.attachEvent("onload", onload) ; return { get: function () { return onload; }, set: function (onload) { callba...

input.focus() ... something really annoying!

new libraries, new add-on s , new engines, new browsers, but still the bloody focus event directly in the onload one ... any chance we will go a step forward? What is wrong with focus The main usage of this strategy is to force via JavaScript the focus of the main input field and it is usually on the top of the page. It could be a search input, a la Google, or it could be a generic log-in. It could be a blog post title, or it could be a comment ... whatever it is, it should NOT act like this! Try to imagine you have a slow connection (I am still with mobile usb pen) or try to imagine you are using your A Grade browser mobile phone with still, a not that fast connection (I am still using my Android, iPhone is the same). Since these magic-focused fields are usually at the beginning of the page and since the page will take more time to be downloaded, 90% of the time this automatic feature messes up my user and password or my searched keyword. Too often I have to correct or change back th...