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.

We still need to manage a migration to Windows Server 2008 / IIS7, and it looks like it might be best to complete this first then look at shared configuration management in IIS7. The good news is that we now have enough capacity that it shouldn’t be a problem to take a single server out of the load balancer, get it rebuilt to IIS7, then added back in.

It looks like any centralisation of either the metabase or content files is based on serving from a network share. I’d be interested to know to what degree this impacts performance, and the best way to do this while avoiding a single point of failure.

I think I’ll probably worry about getting everything on to IIS7 then look at the best way to achieve this.

Worth reading the details over at FontShop.

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.

TypeKit will still provide you access to a wide range of fonts for a low subscription fee, and will also go a long way to serving up the most appropriate format to different user agents.

Nice to see things moving forward and the industry starting to address the massive market that has been pretty much ignored to date.

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.

Designing a magazine for print is much more a labour of love than dynamic content injected into a CMS template – each feature is specifically put together with the design working in harmony with content. Generally publishing on the web is very different – there will be a single generic design and set of templates that present any article in exactly the same way. One of the few examples I can think of that breaks this trend is alistapart, where each article is uniquely illustrated prior to publication.

I’m interested to see where the balance will lie when publishing content for a tablet. It could range from having a dedicated production team within a publication to hand craft a unique design for each issue, to basic templated content within a standard framework.

In any case there is now a very definite case for sorting out workflow and access to content so that a publisher can easily target multiple platforms.