AppCache and SSL

. No comments.

UPDATED POST:

We have just hit a bit of an issue with AppCache whilst we were deploying a new version of a client site. It’s not really a bug, but more a lack of clarity in the current documentation and different implementations in the browsers.

It has taken me sometime to understand how the NETWORK: section of the AppCache actually works. In the end, I had to build a series of AppCache tests to figure it out.

The story

We setup the NETWORK: section of the AppCache to point at a rest API


NETWORK:
//example.com/api/*

# This code is an incorrect use of AppCache

Breaking AppCache

As we deployed our site we wanted to run the API that is on another domain under SSL. So we changed the URL in the NETWORK: section so it started with https and added the certificate to the site. i.e.


NETWORK:
https//example.com/api/*

# This code is an incorrect use of AppCache

At this point Chrome stopped making API requests, we were only initially testing with Chrome.

First mistake – putting the * wildcard in the wrong place

Our first mistake is that we wrongly added the * wildcard to the end of the URL. Each entry in the NETWORK: section can be one of three types. These entries are usually added as a new line directly under the NETWORK: section header. The entry types are:

  • * wildcard on its own
  • relative or absolute URL
  • URL “Prefix match”

Examples of the correct use of AppCache NETWORK: section


NETWORK:
/data/api/
https//example.com/api/
*

“Prefix match” URL

A “Prefix match” is a strange concept – it’s a URL that is used as a “starting with” matching pattern. If your API has many endpoints but they all live in the path http://example.com/api/ then that’s all you need to add to the NETWORK: section. The * wildcard can only be used on its own and means any URL.

Second mistake – URLs should have the same protocol and domain as the manifest

There are other rules that effect the use of URLs in the NETWORK: section. All URLs have to use the same protocol scheme i.e. http or https and be from the same domain as the manifest.

Browser implementations of these rules do differ, Firefox is strict and insists on the same domain, where as other browsers only insist on the same protocol scheme. See the test examples I have built to demonstrate this.

In effect, that means to get good support across the major browsers you can only use URLs in the NETWORK: section if they are to the same domain as the manifest.

The fix is to use the * wildcard and not URLs

The vast majority of sites sidestep the complexities of URLs, by just applying the * wildcard on its own i.e.


NETWORK:
*

This will work with the manifest on one scheme (http) and the API on another (https). The wildcard does not have the same rules as URLs.

You have to ask why the hell the authors of the specification added all this complexity if all that happens is that everyone applies the * wildcard.

Thanks to Jake Archibald for some pointers to the answers as I waded my way through this.

Response Day Out Conference

. One comment.

I went to the Responsive Day Out event

Web and asset fonts

There were a number of good practical take aways from Richard Rutter, Josh Emerson and Andy Hume talks on web fonts. Josh’s talk had a couple of neat ways of progressively enhancing content with resolution independent icons stored as a web font. I particularly liked the use of a data attribute in the HTML and content attribute in the CSS in his code examples


// CCS
[data-icon]:before{
   content: attr(data-icon);
   font-family: 'Cleardings';
   speak: none;
}

// HTML
<a data-icon="&#xe012;" href="http://twitter.com/clearleft">
@clearleft
</a>
});

I also thought the use of ligatures to allow the replacement of words in your text with single icons was good. Take a look at the forecast.is example site Josh put together to illustrate the approaches he talked about.

Part of Andy’s talk on “The Anatomy of Responsive Page Load” covered the method the Guardian mobile site is using to load and cache its custom web fonts. It is a form of progressive enhancement, where only browsers that pass the following tests display the custom font:

The server then sends a base64-encoded font so it can be cached client-side in localStorage for reuse on further page requests.

Patterns of navigation

David Bushell took an in depth look at UI patterns use for navigation. He divided the common patterns found in current responsive design into five :

His talk finished with a useful list of considerations you should be focusing on when making responsive design choices about navigation.

For me one of the strongest points David made was all the ways someone can now interact with navigation i.e. mouse, keyboard, touchpad, touchscreen, stylus, voice, movement, remote and games-pads. True device independence is not just about screen size, a point massively reinforced in Anna Debenham’s talk. Her love of game consoles always heartens me and is a good antidote to those who consider the web a web-kit monoculture. Take a look at her console site its a great resource.

Progressive enhancement

Both Andy Hume and Tom Maslen have been involved in building large-scale responsive sites for the Guardian and BBC respectively. Their talks both focused around the practical use of progressive enhancement. Tom laid out the much talked about “Cutting the Mustard” concept from the BBC i.e. dividing user agents by modern functionality support.

The BBC’s core experience of HTML4 is delivered to all browsers, but an enhanced JavaScript experience is loaded onto any browser that supports the following:

  • querySelector
  • localStorage
  • addEventListener

I was impressed with the script loading optimisation the Guardian is using. Somehow the new async and defer properties for a script tag had passed me by. 


<script src="app.js" async defer></script>

This allows a script to load directly after the HTML at the same time the CSS is loading. They fallback to use appendChild(script) on browsers without support for these new properties. This support detection has to be done server-side.

Media queries (the future or not)

More than one speaker said that they expected their use of CSS media queries to reduce as we move through the next couple of years. I got the feeling that these comments are a mixture of a response to both an over fixation on this area of CSS, but also a belief that other elements of CSS will play a much larger part in creating fluid layouts in the future.

So it was interesting that Bruce Lawson’s talk about future standards development centered so heavily around new media queries that can target device types like touch and remote. This felt like a mixed message.

Things that where un-said

There are two topics I would really liked to have heard about. These are the two difficult subjects of display advertising and web apps vs responsive design

I thought the approach my friend Jeremy Keith took in sidelining the subjects and the people asking about them was not as productive as maybe getting speakers to hit the subject full on. To be fair these issues were most likely out of the scope of this event, but they will be the anchor around responsive design’s neck and they deserve a honest straight-up engagement.

Death of Photoshop and winging it

Sarah Parmenter started the day by being honest and saying she often feels she is just winging it while creating responsive web designs. Her comfortable and well-homed design processes of the past had been lost in the move to responsive design.

A few of the speakers also made reference to the fall from favor of the Photoshop centered design workflow. With some contempt being levelled at the idea of the ‘deliverable’, a Photoshop layout given to a client as if it were the end point in its own right.

I think both points are rooted in issues of client communication.

Photoshop has not been removed from our toolkit, just its output can no longer be the crutch by which we dumb down the way we communicate complex design problems to our clients.

This new world of thousands of device formats and usage contexts means we have to draw clients more fully into the design process with all the subtle and complex trade offs involved in resolving a responsive design.

I am sure Sarah is not winging it; just like most of us feeling the uncomfortable uncertainty that always comes with change.

Thanks

The event was a thought provoking day of responsive web design. Even if I have not mentioned all the speakers, they all did a great job. Thanks to Jeremy and Clearleft for putting on the event. The day was split into groups of 3 speakers all doing a 20 minutes slot with a small joint Q&A session together. A good format I hope they will use again.

Speaker’s slides

Speaker’s notes

Audio recordings of talks

Write ups by other people:

Brand new microformats 2 parser

. 7 comments.

I have just released a brand new microformats 2 parser for node.js. You maybe thinking microformats are so 2006, but this is new. Hear me out…

Demo API
http://microformat2-node.jit.su/

Try the API with:
http://the-pastry-box-project.net/
http://microformats.org/

New life in the semantic web

A lot has changed in the last couple of years; the search engines have started to use semantic mark-up to improve their listings. Google’s rich snippets feature has created a secret army of SEO people who are quietly marking up big parts of the web with semantic data. Not that there are not already billions of microformats on the web.

HTML5 created a third standard of semantic web mark-up to add to the mix of RDFa and microformats. Then the search engines clubbed together and brought us schema.org. After a few catfights between the standards supporter clubs, these events have brought us a small rebirth of the semantic web.

microformats 2

The microformats community has revisited it’s standard and come up with “microformats version 2”. At first, I thought why! I don’t like change unless it gives me something worthwhile. After reviewing the work, I think the wholesale change to a new version of microformats is worthwhile because:

  1. The authoring patterns have been simplified even more and they are based on real life use cases e.g.: <a class="h-card" href="http://glennJones.net">Glenn Jones<a/> is a valid microformat


  2. microformats 2 addresses one of the biggest problems in maintaining microformats in real sites. The class names are now prefixed i.e. class=”fn” is now class=”p-name”. The prefixes like “h-*” and “p-*” tells you a class is a microformat property and helps make sure classes are not moved or deleted by mistake


  3. Like microdata, microformats 2 now has a full specification for a JSON API. This is important as it means the parsers should now have the same output and also browsers could implement this API.

New parser and test suite

Most importantly for me I wanted to help move forward microformats, I liked the fact that the API design aligned microformats 2 a little closer to microdata and RDFa. So I have invested a couple of months of my time to building a brand new JavaScript parsing engine and a comprehensive test suite.

microformat-node GitHub https://github.com/glennjones/microformat-node
Test Suite GitHub https://github.com/microformats/tests

I have just open sourced a new version of microformat-node using this parsing engine. Soon I will create a browser compatible version of the engine and update the microformat-shiv library which powers browser plug-ins etc.

The test suite took a long time to develop, but should provide an excellent starting point for anyone else who wants to develop a new microformats 2 parser. I know Barnaby Walters has already started working with it for his php-mf2 parser.

I hope this work will help microformats and the concept of the semantic web move forward another little step. Enjoy

NodeCopter Brighton & kinect-drone

. No comments.

Last weekend I attended NodeCopter Brighton, a day of hacking AR-Drone’s and node.js. I wanted to control the drone by hand jestures using the Kinect’s motion detection abilities.

Links to the high-res versions (.mov, .mp4 or .ogv) of the video

Hackdays are funny, sometimes everything comes together, other times small things just trip you up. Unfortunately Saturday was a day when nothing seemed to work for me, mainly because I made the mistake of loading the wrong version of a USB driver.

On the upside that day I bumped into Aral getting coffee at Taylor St who pointed me to a project he did using Kinect with processing.

So after a couple of hours of hacking after the event, I could wave my hands and fly a drone. Once I had the right USB driver installed.

Thanks to everyone who made the day possible, I had a great time. I am glad with others, Madgex was able to sponsor the event.

You can download the project from github kinect-drone, enjoy

Faster version of microformat-node

. No comments.

I have just uploaded a new version of microformat-node. The parser now takes between 30-40 milliseconds to parse an average page, about 8 times the speed of the last version.

Features of new version

  • About 8x faster at parsing
  • Will now load onto Windows based hosting solutions correctly
  • Inbuilt cache system, which can be customised
  • Upgraded logging and trace options
  • Upgraded unit test system
  • Added support for JavaScript promise

 

Example: http://microformat-node.jit.su/
Code: https://github.com/glennjones/microformat-node

 

I have changed how the method calls work so if you are using the last version you may have to update your code. The parse methods parseHtml and parseUrl now follow the standard pattern used in node.js and return an error and data object rather than just the data object.

with URL


var microformat = require("microformat-node");

microformat.parseUrl('http://glennjones.net/about', function(err, data){
    // do something with data
});

or with raw html


var microformat = require('microformat-node');

var html = '<p class="vcard"><a class="fn url" href="http://glennjones.net">Glenn Jones</a></p>';
microformat.parseHtml(html, function(err, data){
    // do something with data
});

using a promise


var microformat = require("microformat-node");

microformat.parseUrl('http://glennjones.net/about').then( function(err, data){
    // do something with data
}));