Posts Tagged ‘web’
Bespin…
…was launched yesterday. One of the coolest implementations of canvas around.
It has some interesting stuff in there. For instance :- a global event bus for all events and listeners, a nice little syntax resolver which supports js, html, css currently. Very easy on the eyes, javascript.
They are also going to support VIM syntax per the forums. That’ll be the day!
I’m in.
Peeling the covers off HTML5
Went back to the HTML5 draft spec after a long while and found some interesting tidbits as usual.
element.click() has been made non-reentrant :- no worries anymore about dumb users clicking buttons again and again.
src attribute in img will be ignored if its the same as the page url :- most browsers used to fire an HTTP request even if the src attribute pointed to the same url as the page url (formally known as the ignored self-reference), duh.
And here’s the beast of a change which introduces script groups. Takes a while to stomach the implications.
MY NEW YEAR RESOLUTION :: MUST.KEEP.REVISITING.HTML5.SPEC.
event.returnValue
You won’t know how important this sucker is unless you’ve coded confirmation dialogs in IE7. Yes, those worthless pop-ups which are supposed to help out the clueless.
<husky_mocking_overbearing_voice>
You might want to save you changes before you go to the other link! Are you sure you want to navigate away? Were all those clicks really just fluff not to be recorded for posterity?
</husky_mocking_overbearing_voice>
I was merrily invoking a js function from an anchor which throws up a innocuous confirmation dialog when I realized that clicking Cancel was still posting the page to the href URL!
Here are the relevant bits:-
<a onClick="javascript:return processClick(event);" href="/takemeaway">Click me</a>
function processClick(event) {
if (unsavedChangesOnPage) {
return showDialog(event);
}
}
function showDialog(event) {
return confirm("Do you really want to lose your changes?");
}
Apparently, with confirmation dialogs sometimes (on some machines; come on I should have a better answer); IE forgets to set the event returnValue to false! Bloody piece of crap!
Anyway, the solution was merely setting event.returnValue explicitly to false if Cancel was clicked.
Here’s the fix:-
function processClick(event) {
if (unsavedChangesOnPage) {
var result = showDialog(event);
if (!result && itsStupidIE()) {
event.returnValue = false;
}
return result;
}
}
No love lost between me and IE!
Not now; not ever.
ECMAScript property resolution
Hummm…And I thought I knew property resolution in Javascript.
Read this and decide for yourself.
Everyday is a real humbling experience!
Workers on the Web! Ahoy!
The WebWorkers draft spec is out.
Looks like Gears is going to dominate the browser related W3C recommendations & standards for some time to come.
Accessibility in Web 2.0 apps
In case you are interested in implementing accessibility in Web 2.0 apps; I would recommend taking a look at AxsJAX. There is a nice tute available here. It’s creators gave a talk at Google I/O this July which can be found here.
And for the theoretically inclined, here is the W3C roadmap for ARIA.
Oh, and what did this do for me? Well…I have yet to make a accessible web2.0 app…however, I did start using XPather. There’s always a silver-lining