My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.
Showing posts with label onload. Show all posts
Showing posts with label onload. Show all posts

Wednesday, April 28, 2010

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) {
callback.push(onload);
}
};
}(this, [])));


If we put above snippet before any other script, we can be almost sure that nobody will be able to break anything with classic obtrusive operations:

// test above concept via Chrome and maybe IE8 or others
onload = function () {
alert(1);
};

this.onload = function () {
alert(2);
};


That's it, something that may have been good will probably be just a proof of concept :-)

Friday, June 05, 2009

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

new libraries, new add-ons, 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 the field, specially when I need to log-in into my on-line banking service, where my actions are faster than page download. Am I that fast? OK, Android first model with its pretty keyboard let me type faster than how I could do with iPhone or second Android generation, but the main problem is that if there is an image, for example, or generally speaking just content after main focused input, the onload event will be fired too late and it will be completely useless and inefficient, rather than being an help for the user.

How could we solve the problem

In my opinion, it is the most simple thing ever. Assuming that the theoretically helping focus will be only one per page, if the site would like to make sense, all we need is a little manager able to understand if the input received focus before the onload event:

<form name="f" action="/search">
<input name="q" onfocus="fff=1" />
</form>

fff will be a global variable which name is absolutely irrelevant and which aim will be to stop the generic onload event to force focus in that input.

<body onload="if(!this.fff)document.f.q.focus();">
<!-- ... the rest of the page ... -->
</body>

With a zero effort + stress strategy that will not increase more than a couple of bytes our page, users will have more control over their fields. This simple trick could be used for every textarea, input, select, or button in the page making the auto focus really helpful in those case user has a fast connection or is lazy and does not want to point the focus automatically, rather than quick posts via mobile or slow connections.

Another Way Without Changing Every Layout


I agree that probably nobody will ever change every page layout adding an inline onfocus event for each field, so here I am with a better solution that should be widely copatible with every kind of device.

(function(){
// A WebReflection Anti Stress Idea
function onclick(e){
var target = (e && e.target) || event.srcElement;
if(/^(input|select|textarea|button)$/i.test(target.nodeName)){
window.fff = true;
if(document.detachEvent)
document.detachEvent("onclick", onclick);
else
document.removeEventListener("click", onclick, false);
}
};
if(document.attachEvent)
document.attachEvent("onclick", onclick);
else
document.addEventListener("click", onclick, false);
})();



// as body or window event
onload = function(){
if(!this.fff)
document.getElementById("main-input").focus();
};

Above snippet does not require both onReady or onload events so it should work just adding it inside the head tag. It is so simple, now let's see how people will react 8)