There are two types of technical books. Reference manuals are useful; you always have them to hand, and you can jump in and find a particular page which gives you the stuff you need to know. They're an indispensable reference tool, unless, say, you have access to the internet. Then, well, maybe they're not as handy. On the other hand, there's the other sort of technical book; the sort that's a pleasure to read in itself, and you only realised you've learned things afterwards. Such a book is Introducing HTML 5, by Bruce Lawson and Remy Sharp. As they say at the beginning of the introduction: welcome to the Remy and Bruce show. The book manages to be both a thorough introduction to the swathe of modern and new web technologies masquerading under the name of "HTML5", and a personal voice which comments on the state of web development today and in the near future. The tl;dr summary for people who don't want to read the rest: good web book is good. Get it.

The book successfully and intelligently covers the new markup in HTML5 (nav/header/section/article, new input types in forms, and WAI-ARIA accessibility) as well as the vast proliferation of new APIs available to modern web applications (canvas, multimedia, offline storage, workers, and geolocation, among others), drawing on the authors' experience of user questions and articles at their html5doctor site. Fortunately, it's not a hagiography, and they don't hesitate to stick the boot in where it's warranted; the current mess that is native drag-and-drop support in browsers and the ridiculous codec war inherent in online video both come in line for a justified kicking. Each chapter covers its material in decent detail, without devolving into a mere list of APIs; the book is full of both worked examples and links to relevant extra resources. Unusually for a book of this type, the examples are fairly real-world; instead of a contrived writeup to show off a feature, they show how to mark up the home page of the Guardian newspaper with HTML5 elements.

Conspicuously missing from the book are the major changes to CSS currently being implemented in browsers. A chapter covering the transform and similar CSS3 declarations (-webkit-transform, -moz-transform, and the like) would have fit nicely, and it's a shame that this wasn't covered -- yes, it's a book about HTML5, not CSS3, but the authors themselves admit that by "HTML5" they actually mean "HTML5 and related specifications that came from the WHATWG", and they throw in geolocation just because "it's really cool". Advances in CSS which give dynamic effects not only would fit well with the other subject matter but would also make a few of the examples perhaps easier.

The canvas chapter doesn't bring much more than innumerable web pages covering the basics of the canvas API for drawing, but it covers those basics well and in a readable way. Importantly, there's also a discussion of the difference between using the canvas element for drawing and using SVG, and when you'd choose one rather than the other. It's been difficult to find that sort of summary; it's equally difficult to decide yourself which to use for some new project, and the chapter's sidebar (or <aside>?) discussion of "when to use which" clarified the distinction well, especially when going beyond reimplementations of Super Mario Bros inside the browser.

All is not sweetness and light, mind. The data storage chapter, explaining how to use HTML5's new in-the-browser storage objects, breathlessly explains that this means an end to cookies (which are "rubbish" according to the authors). However, this is where their client-side bias seems to be coming through. Cookies are shared with the server, too; snazzy HTML5 storage is not. Any even reasonably detailed web application will have a substantial server component, and abandoning cookies will make it jolly hard to have the server and the front-end share data. This does seem rather like excitement over the new tech without thinking about how it can actually be used in real-world situations, and is disappointing from a book which goes out of its way to give suggestions that are actually useful to people.

Another area the book falls down is in its editing: there are typos scattered throughout the text (including in a heading in the introduction, for goodness' sake!) and these should have been caught by an editor; noticing them distracts the reader from the material, and it's a schoolboy error which damages the impact of the book.

I know both the authors, and they're both well-known and respected in the web development community; Introducing HTML5 does them credit, and it's worth your time. Go forth, get Introducing HTML5, and make great web stuff.

Hi guys,

I have talked briefly about a new project I wanted to undertake and so here it is!

‘wasiliana’ verb: communicate (swahili)

Wasiliana is a new email client that specifically targets small-form-factor devices such as netbooks. It combines the flexibility and beauty of HTML5, CSS3 and Javascript, with the speed and extensibility of Genie/Vala.

Not only will the design be beautiful, but it shall be practical, especially on small devices.

I am still in exams and so haven’t started coding yet but I have made some mockups and there is a video of a prototype I made.

Launchpad Page
https://launchpad.net/wasiliana

Mockups (5)

http://and471.deviantart.com/gallery/#Wasiliana

Video of Prototype

I was inspired to make this as I have yet to see any mail client that really delivers on a netbook.

Programs such as Anjal have gone in the right direction, but in has the hindrance of being based on bloated Evolution and trying to still use GTK widgets. I also believe current mail clients have it all wrong when it comes to design regarding contacts etc. and so I wanted an opportunity to fix this.

My mockups were obviously inspired by the great danRabbit and they use the elementary icons. I am not ready to begin coding but if anyone is interested/wants to find out more, please don’t hesitate to contact me via the comments below.

Any comments?

Seriously, I can’t be the only person who does this?

Incoming flash blob (or HTML5 video if you have a decent browser)

Combining this with my compulsion to watch -n 0.1 cat /proc/mdstat, I clearly need help. Is there a support group for people like me?

Disclaimer: If you are reading this via PlanetPlanet or a non-javascript aggregator, please visit the real page to read more

You know, we are living in a world of SOA. And even if we don’t like the new world order of the web, sometimes it can make our lifes easier.

We think that, right?

Right now I’m working on the re-implementation on my DjangoFAIed project. Which means, I’m in need of a separation between shiny new bling bling named web frontend and boring looking jsonrpc or xmlrpc for the web backend.

As you know, I’m working with Django for the daily system development, so here I’m in love with Django and RPC4Django.

The good thing about RPC4Django is that it gives me an easy way to provide two RPC types but only writing one backend.

So, having this in place, and doing some xmlrpc calls from the FAI side of life, I just need to find a way to deal with the web frontend.

So, here we are, my high rated topic: XMLHttpRequests, Javascript and Browsers, and what are they supporting.

There are at least 4 browsers I would care about:

1. Firefox >= 3.5
2. Google Chrome
3. IE8
4. Safari

No. 1 is my choice when developing some bling bling, No. 2 comes to my mind if I want to have a fast Javascript Execution time, No. 3 and No. 4, oh well, I use FF and Chrome even on windows, and I never had to do anything with Apple ;)

Creating our testbed

Now, let’s setup a testbed for the application. Let’s assume:

1. http://testrpc/ -> this is the domain where Django lives. It’s setup and runs like a charm
2. http://testhtml/ -> this is where our test web application is living. It consits right now of one web page, named index.html
3. For doing some simple javascript work we are using jQuery delivered by the google cdn
4. Our webserver is Apache 2.2.x
5. We are using WSGI as gateway to our application (mod_wsgi)

Now, I hope you have a django installation (I’m already using 1.2 beta) and installed RPC4Django. Create a new django application and add to the __init__.py file these methods:

This is how we define a new xmlrpc/jsonrpc call which just returns “Hello World”.

Now add to your djangoproject urls.py this endpoint for our RPC calls:

(r'^RPC2/$', 'rpc4django.views.serve_rpc_request')

and add your new application and the rpc4django application to your settings.INSTALLED_APPS.

Setup your apache installation to serve your application, don’t forget your wsgi_handler.py.

Now, if we start a browser and enter “http://testrpc/RPC2/” into the location bar, you will get something like this:

(Picture taken from: David Fischer RPC4Django)

To test if our application is working just create this little xmlrpc client app:

It should print out “Hello World”.

Creating the web frontend

As said before, we are using jQuery as DOM library to make our lifes easier, regarding Events and Ajax things.

Let’s see how this goes:

This page includes the jQuery Script from the Google API CDN, you need to get the json2.js from http://www.json.org/
and put it in your documentroot or in your directory where the html file is saved.
When you point your browser now to this page, and you click with your mouse on “click here”, the javascript fires an click event, and inside this click event, it starts to make a Ajax Request against our rpc django app.
The result of this ajax request should be, that the content of the “<DIV> with the ID of “#testOutput will change its content and displays “Hello World”.

“Oh, but you can’t do XMLHttpRequests across different domains! It will fail, and you should know about the same origin policy !” you will say now, and you are right.
But, thanks to the “Web Applications Working Group” we have something new: CORS or simply named: Cross Origin Resource Sharing.

Cross Origin Resource Sharing – CORS

What is “CORS”? you will ask now. The working draft abstracts it like this:

This document defines a mechanism to enable client-side cross-origin requests. Specifications that want to enable cross-origin requests in an API they define can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.

(from: Cross-Origin Resource Sharing, W3C Working Draft 17 March 2009

This really sounds important, right? What it just says is, that now it’s possible to make Cross Site XMLHttpRequests under special cicumstancas.
What we just need to know is that Mozilla implemented this feature already in all Firefox Browsers >= 3.5.
Mozilla calls it “HTTP access control“.

Now, you will bring this example to work when you enable mod_header of your apache installation and add to your test virtualhost something like this:

Pay a bit of attention to the “Header” line. What it will do is easy: It will spit out a new Access-Control-Allow-Origin Header, which is set for anybody to make cross site XHR requests to your site.
It’s just like a bit when you tell Adobe Flash Crossdomain.xml to ‘allow-from-domain “*”‘. Different names, same result.

Now, restart your apache server and try the demo page again, now it should work like a charm. The contents of the div will change to “Hello World” and we are done.

Are we really done?

Oh well, not quite done. Now we need to test this positive result in another browser, let’s choose Google Chrome.

To make a long story short, somehow this example doesn’t work, but regarding all the postings on the fantastic lazyweb, Google Chrome does support CORS!
Well, not really. It does support this feature under special circumstancas. This document tells us more.

Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers,
but they’re limited by the same origin policy.
Extensions aren’t so limited. An extension can talk to remote servers outside of its origin, as
long as it first requests cross-origin permissions.

(taken from: Google Chrome Extentions: Cross-Origin XMLHttpRequest)

There is another explanation.

Content scripts are JavaScript files that run in the context of web pages. By using the standard Document Object Model (DOM), they can read details of the web pages the browser visits, or make changes to them.
Here are some examples of what content scripts can do:

• Find unlinked URLs in web pages and convert them into hyperlinks
• Increase the font size to make text more legible
• Find and process microformat data in the DOM

However, content scripts have some limitations. They cannot:

• Use chrome.* APIs (except for parts of chrome.extension)
• Use variables or functions defined by their extension’s pages
• Use variables or functions defined by web pages or by other content scripts
• Make cross-site XMLHttpRequests

(taken from: Google Chrome Extentions: Content Scripts)

Now what?

Now we have a good, fast and cool browser named Chrome, and it does not work as expected.
It should support this out of the box, and it should work like Mozillas implementation.
There are discussions in the background, regarding Greasemonkey and CORS.

Honestly, I’m writing “intranet” applications, I don’t want to use CORS in external applications. But regarding the CORS specification, I do like the way how this goes.
No need anymore to do cross site XHR via iframe (which works, but is actually painful). Furthermore, it can be a nice standard.
What we need to avoid is that really good browsers like Mozilla FF and Googles Chrome are doing what we always hated about MS: Going two different ways.

I also don’t want to write two or three different JS implementation to do the one thing. I really don’t want to support more then one browsers javascript implementation.
So, how can I get this to work without doing the old painful “iframe” way, and without writing a google extention?