The most useful thing so far is having a valid way of stashing information in the DOM so it is available to client-side script via the data- attributes. An example would be storing an attribute like data-zoomimageurl=”http://blah” for use by an image zoom plugin.

Anyway, I’m off to shoot my friends now.

This fits in very nicely with some of the ideas in Behaviour Driven Design, which is like the next iteration of thinking around TDD. The idea is to express acceptance tests using a simple DSL vocabulary working in plain English, then hook up each acceptance test scenario to some automated tests which prove the scenario works as expected.

A simple example would be…

+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

In BDD, an acceptance test would be along the lines of…

+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

I’ve lifted the example here from the key article published on BDD from Dan North – if you’re interested so far then you should stop reading now and go and check out the article.

BDD frameworks will then map each step expressed in the text above through to a method in a test class, so you have a great balance between expressing the acceptance tests in simple language, but having the ability to execute the tests.

I found the best way to learn about this so far was a TekPub video – you’ll need a subscription, but the video is under the ‘Concepts’ section > Concepts:5 Behaviour-driven Design with Specflow.

Overall it seems like a more natural way to approach proving the application behaviour, and makes it much easier for testers and analysts to work alongside you in defining acceptance tests. I’m quite keen to roll this into our day-to-day process.

They have introduced a feature where closing the browser can remember the tabs you had open, and rehydrates these again when you start Firefox. This feature is controlled in the Settings > General > Startup section. If you have this set to Show my windows and tabs from last time, Firefox will no longer expire session cookies when the browser is closed.

This seems to be a pretty big security concern, as you are prompted to switch this setting on the first time you try to close the browser, so the majority of users would have this set-up. I’m not entirely sure how it decides when a session cookie should expire under these conditions, any ideas?

By default if you don’t send either Cache-Control: max-age, or Expires headers then the user agent has been told that the resource can be cached, but has no way to know whether it has changed on the server. Based on this the user agent will send a conditional GET request to the server to find out if the resource has changed, or if it can be served directly from the local cache (this would look like a 304 response).

A conditional GET will compare versions of a resource based on either the Last-Modified header, or the ETag header. Generally these would have been sent in the original response for a resource. The client will then send either the If-None-Match, or If-Modified-Since headers in the GET request to indicate the resource should ONLY be sent by the server if it has changed.

In this case the dynamic endpoint had not been coded to support conditional GETs, so the images were getting fully downloaded on each request as a 200 response.

The simplest solution is to send Cache-control: max-age in order to allow the user agent to serve the resource directly from the cache without bothering with a conditional GET. Alternatively the endpoint has to check for conditional GET requests and change it’s behaviour to support sending a 304 response if the image hasn’t changed.

The best diagnostic tool to see what is going on is the Net tab in Firebug. This will allow you to check the request and response headers, the response codes, and user agent caching behaviour.

I know there are many grey areas where it’s hard to decide if something is really behavioural (so should be covered via javascript) or presentational (in CSS). I can’t help feeling that this is taking CSS too far into trying to accommodate behaviour. After all, mostly what we do with javascript is about changing the state of the DOM, which causes the browser to re-render with the change applied.

There are many problems that would need to be solved well in order for this to be viable, which are currently very simple to achieve in javascript using a decent library. These include…

• Managing multiple independent animations on an element
• Animating multiple elements simultaneously
• Cancelling all active animations on an element
• Transitioning either from the current value of a property, or from an absolute value
• Chaining animations (so when animation X finishes, trigger animation Y)

I think my other objection is simply that all of this is currently achievable in quite a simple way using existing web standards, and libraries built on top of those standards. I think deciding how to change a property over time is behavioural, not presentational and should stay in the realms of javascript. Given this, the only thing to consider is whether to extend the core DOM specification to standardise some of the behaviour that is currently provided by javascript libraries.

Personally I don’t quite see how this progresses anything – it will just add another way to achieve something we can do already and add inconsistency and confusion around how to approach animation.

Previously it has been possible to temporarily store state information in custom properties against an element via javascript, however embedding state information in a page when generated server-side (and getting a page to validate) always required workarounds. I’ve often resorted to using hidden input elements to expose state information to client-side script, but this should not (and won’t any longer) be necessary.

I had heard a little about document databases being an alternative to relational databases (a slightly alien idea) but hadn’t got around to much research. In particular the session was looking at how to use CouchDB. The design goals are more based around assuming that individual nodes will fail, and having a lightweight, multiple-master setup with changes replicating across nodes.

From the introduction (which I recommend you read)… A CouchDB document is an object that consists of named fields. Field values may be strings, numbers, dates, or even ordered lists and associative maps. A CouchDB database is a flat collection of these documents. Each document is identified by a unique ID.

Unfortunately the session didn’t really cover how to apply this concept to a real-world scenario and how to perform useful queries against the data. However it was definately enough to encourage some reading around the subject – I think it’s important to understand the kind of problems where this could be a viable and better solution.

• Mixing functional and object oriented approaches to programming in C#
• Hello Document Databases
• C# 4
• Microsoft Surface
• A developer’s guide to encryption

I think the major things I’m looking forward to are…

• Ability to specify multiple background images on the same element – so no need to add superfluous elements as styling hooks
• Multi-column layout – allowing text from a single element to visually flow into multiple columns, much like a newspaper layout
• Decent support for RGBA – so being able to specify the alpha channel when setting a background colour. This avoids having to cut PNG images in order to achieve a semi-transparent background.
• Support for specifying colours in terms of Hue, Saturation and Lightness. Although I’m not quite sure how I’ll use this yet, I can imagine this would make animation of colours more intuitive – for example, using javascript to animate the amount of light applied to an element.

The live examples are really worth looking at, and give a much better feel for what is coming up compared with reading a specification.

   1: <script type="text/javascript" src="blah.js"></script>    

   2:  

   3: <script type="text/javascript">

   4:     

   5:     mycompany.video.addVideoWidget({

   6:         siteId: "Heat",

   7:         keywords: "Britney Spears",

   8:         parent: "Id of the container"

   9:     });

  10:     

  11: </script>

When authoring a script like this, it needs to be entirely self-contained as you have no knowledge of what other scripts have been included on the host page, or what versions etc.

The issue is how to offer this script when you have a dependency. In this case I wanted to use swfoject as a reliable way to add a flash movie to a page. Another common scenario would be writing script on top of jquery. An example is Typekit who end up packaging up and distributing jquery as part of the code they require you to download – discussed here.

Given that you have no working knowledge of the host page, the only possible option is to package up the dependency, avoid naming conflicts, and include it with your script logic. However this seems quite wasteful given that the host page may also include the same library.

We are so used to using libraries now to make javascript a pleasurable activity, the idea of writing raw script, while possible, is really not an enjoyable prospect.

I don’t have a good answer to the problem – I ended up going down the same route that Typekit have gone. The only other option is to provide a flavour which requires the host page to implement the dependency, but then you lose the simplicity and are open to tricky issues around versioning.

Still, I guess life is short and bandwidth is cheap.