Tag Archives: standards

On Responsive Images — An interview with Dr. Stanley Dards

Wanting to serve different size images to different size screens is nothing new but at last the web has a practical solution for responsive images and art direction. Thanks to a lot of hard work by a lot of people, the Responsive Images Community Group has achieved the goal of seeing its API becoming a valuable building block of the web.

The <picture> element and its related srcset and other attributes are already being incorporated in Blink, Gecko and WebKit, have been included in the HTML5 validator and are part of the WHATWG HTML5 spec. A triumph of common sense and cooperation — hurrah!

To celebrate this, I was lucky enough to interview Dr. Stanley Dards, the wise old man of the web, to get his unique insight on the topic.

And here’s a good practical summary of responsive images and how you can use them today.

Joining the W3C!

W3C logoI’m delighted to announce that from today, I’m officially joining the W3C!

After four wonderful years at Opera it was difficult to think what could follow it but being able to contribute to the open web as part of the W3C and still remain in Japan is as close to a dream-come-true as it gets.

Keio University Shonan-Fujisawa campusI’m based at Keio University’s Shonan-Fujisawa campus (SFC) which is a haven of trees and ducks just outside Tokyo. The new colleagues I’ve met or spoken with both in Japan and scattered around the world have been super welcoming so I feel at home already.

The work I’ll concentrate on will be a mixture of communicating with developers, businesses and media about the W3C’s mission and progress, together with more focussed work coordinating with device-related groups such as web and TV, automotive, signage, etc.

There’s not much more to say other than a big thanks for the kind wishes and support I’ve received to get here. I hope I can do my bit to reinforce the web as The Platform For All.

Examples of digital signage (videos)

Digital signage is a form of electronic display that shows television programming, menus, information, advertising and other messages.

Digital signage is a growing industry around the world but there is particularly strong interest here in Japan and neighbouring South Korea. Most recently, local businesses are focussing more and more on digital signage built with web technologies. However there seems to be some concern that existing standards (HTML5, CSS3, SVG, etc.) don’t address all the issues for web-based signage to really take off. For this reason, the Web-based Signage Business Group was set up as part of the W3C community.

In order to fully understand what’s required before more specific action is taken, use-cases and real-world examples are necessary. It’s often underestimated just how varied digital signage can be so here I’d like to show a few interesting examples from the Far East.

Funky-sized 360-degree display

The resolution of this display in Hikarie, Tokyo, is about 4,000 x 100 pixels. It makes designing for mobile devices look like child’s play! The content is mostly informational consisting of a floor guide, event information, a horizontal clock, etc. shown repeatedly. The back-to-back displays are sometimes in sync and sometimes show differing content.

Side-by-side advertising and info displays

Also from Tokyo is this contrast of digital signage usage. The left-hand screen shows a selection of 15-second and 30-second adverts based on a pre-determined order and frequency. The right-hand screen shows information about the train which is shown in timed mini-loops e.g. Japanese first, English second, but these are interrupted by external triggers such as the train arriving at a station.

Transparent product display

I couldn’t resist this South Korean example — it’s so cool! It was spotted by Rich Tibbett in Seoul and although it seems to be presumably a simple timed loop, it has a few points of interest. Obviously the transparent screen is one, but also the use of a skewed video whose timing has to be perfectly synchronised with the accompanying animation.

Addition: Vending machine with signage

As suggested by Karl in the comments, here’s a digital vending machine with a discreet built-in camera just above the screen. Normally it operates as a sign showing video adverts but when it detects a person in front of it, the video overlays disappear and it operates as a regular, albeit animated, vending machine. I did hear an unnerving rumour that it has the ability to detect characteristics (a person’s rough age, gender, etc.) to customise how it displays content but I have no solid information.

If you know of other interesting examples, feel free to leave a link in the comments section.

Web API Design – a definitive guide

Cover of Web API Design book“Web API” is a confusing term. It can refer to interfaces to be implemented by web software such as browsers, for example the W3C geolocation API, etc. It can also refer to how a web service exposes its data, and it’s in this context that Brian Mulloy has written what I hope will become the bible of REST-based API design. His ebook, entitled Web API Design, is available for free (well, in return for your email address).

As web developers, we want APIs that are easily-understandable and consistent, resulting in less time reading documentation and more time experimenting and being pleasantly surprised that something just works.

At around 30 pages long it’s a quick read but gets straight to the point with concrete advice. Right from the start he emphasises a pragmatic rather than theoretically ideal approach — developers should be able to experiment with and learn the API without the documentation — and highlights good and bad examples from popular APIs. Here’s a quick summary of some of his recommendations.

  • Use two base URLs per resource, e.g. /dogs and /dogs/1234
  • Keep verbs out of your base URLs, unless the data is the result of an action, e.g. “calculate” or “translate”.
  • Use HTTP verbs (GET, POST, PUT, DELETE) to operate on the data.
  • For clients that don’t support this, make the method an optional parameter, e.g. /dogs/1234?method=delete
  • Use plural rather than singular nouns.
  • Use concrete rather than abstract names.
  • Put complexities after a question mark, e.g. /dogs?color=red&state=running
  • Be verbose but simple in your error messages, ideally linking to online docs.
  • For specific fields, us a comma-delimted list, e.g. /dogs?fields=name,color,location
  • Use “limit” and “offset” for pagination, e.g. /dogs?limit=25&offset=50
  • To specify formats, use the familiar dot notation, e.g. /dogs/1234.json
  • Use JSON as the default format, following JavaScript conventions for attribute names.
  • Use OAuth 2.0 for authentication.

There seems to be a relative lack of guidance in this field so this book has a good shot at becoming the go-to reference. The result of that would be more consistency between APIs and an easier life for website and app creators. Of course, differences in existing APIs will linger on because of the difficulty in upgrading them once released, but that’s one more reason why it’s important to base an API design on solid guidelines such as these in the first place.

Download the ebook here: offers.apigee.com/web-api-design-ebook/ (no affiliation)

Also, here are a couple of other good resources about designing RESTful APIs:

On vendor prefixes — An interview with Dr. Stanley Dards

At last, the existence of vendor prefixes, one of my pet peeves, is under the spotlight. Also at last, the fact that not all modern browsers are WebKit (shock!) is getting some attention.

I (personally) believe vendor prefixes cause more harm than the problem they were designed to solve, namely how to elegantly introduce experimental features in browsers. My belief is that a non-browser-specific prefix such as -beta- has fewer obstacles to overcome than other proposals. Having said that, there’s clearly no easy, one-size-fits-all answer but hopefully more awareness and public discussion will lead to a more plausible solution.

So far, there have been great contributions to the discussion from all sides. A selection of ones I’ve found valuable, but may not necessarily agree with, are listed here:

And as if that wasn’t enough, here are the insights of one Dr. Stanley Dards:

Opera’s (potential) HTML5 compliance

With HTML5 on its way I thought I’d take inspiration from http://www.w3.org/QA/2008/09/top-500-html5-validity.html who in turn took inspiration from Opera’s QA team and test the front page of a few of Opera’s websites for HTML5 conformity.

Firstly, an important caveat. The HTML5 validator is beta so may have erroneously missed or mis-detected issues. In addition, at the time of writing HTML5 is still a working draft only and public websites should not be expected to support it yet. Not being valid HTML5 means nothing unless the document’s doctype indicates that it’s HTML5, which none of them do at this stage. This is just intended to be a (hopefully educational) “what if” exercise. Having said that, several sites didn’t even validate against current standards – I’m looking at you list.opera.com, widgets.opera.com, bugs.opera.com, portal.opera.com, labs.opera.com and irc.opera.com!

So onto the HTML5 validation results, in no particular order:

HTML5 validator result

This is all academic until we see what errors were found and how to correct them, in other words, what are some of the common changes from HTML 4 to 5 that we may encounter in our own websites?

Not surprisingly, the majority are a result of presentation and markup being strictly separated at last. The following were encountered in this exercise:

  • Attribute size not allowed on element input.
  • Attributes bgcolor, link, alink, vlink not allowed on element body.
  • Attribute width not allowed on element table or td.
  • Attribute border not allowed on element table or img.
  • Attribute bgcolor not allowed on element table, tr or td.
  • Attributes cellspacing and cellpadding not allowed on element table.
  • Attribute align not allowed on element td or div.
  • The center, font and big elements are obsolete.

CSS is the place for presentational items such as these.

Other HTML5-specific errors were mostly as follows:

  • Attribute accesskey not allowed on element a.
  • Attribute name not allowed on element a. (Use id)
  • No whitespace allowed in paths/URIs. (Use %20)
  • The acronym element is obsolete. (Use abbr)
  • Bad values content-type and cache-control for attribute http-equiv on element meta.

Admittedly this only uses Opera’s websites as an example and they are more compliant than most, but I was still surprised at how little work would be needed to make any of these valid HTML5. I wonder if the folks at snapshot.opera.com know they’re already ahead of the game?