XTech 2007 | May 20, 2007

Last week I had the pleasure of attending XTech 2007 in gay Paris. I’ve not been to XTech before, but Jeremy spoke there last year and really enjoyed it, so I wanted to check it out.

The conference has been around for many years, and recently changed it’s name from XML Europe, in order to demonstrate a widening of focus. However vestiges of it’s previous incarnation were evident, as the conference had a strong technical theme. The sessions that made up the applications track and core technologies track were way over my head, whereas the open data track was very academic. As such, I spent the majority of my time in the browsers track, occasionally dipping out to watch Simon talk about JavaScript libraries and OpenID, or learn about WiFi rabbits (and before you ask, no, it’s not the kind of rabbit your wife or girlfriend has tucked away in her underwear draw).

The theme of this year’s event was “The Ubiquitous Web”, and there were some fantastic sessions on this subject from Matt Biddulph, Adam Greenfield and Matt Webb. Matt Biddulph talked about the prototyping opportunities of second life, and how it was a great environment to test out spimes and other location aware devices. Matt demonstrated the flickr photo frame he created for himself, as well as a complicated visualisation he created for Nature magazine. He also talked about IBM using ball location data from Wimbledon to replay the matches in second life. However the thing that really got the geek audience excited was the Arduino hardware hacks he’d been doing. I wouldn’t be surprised if half the audience went out and bought kits in time for the next hack day in London.

Adam Greenfield gave a predictably excellent talk based on the themes from his book, Everyware. In it he discussed everything from the unnecessarily complicated digital locks in Korea (who do you call if you forget your passcode?), through to the fantastic usability of the Hong Kong underground Octopus cards, beloved by so many user experience people. Finally, Matt Webb closed the event off with an inspiring keynote on his vision of interaction design.

One of the great things about XTech is the fact that it’s co-hosted by the W3C. As such, there were lots of important W3C people in attendance, and some very interesting discussions to be had. The session I was most looking forward to, and the one I was most disappointed by, was the session on HTML5. As we all know, HTML5 is a pretty hot topic at the moment, and one I’m going to deal with in a later post.

While the panellists introduced themselves I worked up a series of questions about doctypes, presentational elements, timeframes and the lessons we could learn from other interface languages like MXML and ZUL. However I thought I’d open with a quick question about the divergence between XHTML2 and HTML5. I was expecting a short discussion about the different aims of each language, and their various feature sets. What I ended up with was a 20 minute discussion about namespacing and error handling that completely missed the point of the question. If I hadn’t know it already, I came to the realisation in that the W3C is all about creating specifications for browser manufacturers, and not about providing tools for us web developers. But like I said, more on that later.

Thankfully, Molly brought things back down to earth with an excellent talk on the issues both developers and browser manufacturers were facing. In language the average developer (i.e. me) could understand, she demonstrated how different browsers handle something as simple as mixing rgb colour property units. The letter of the spec says that this is illegal, and so the rules should be ignored. Some browsers follow this draconian error handling and fail to display the rules, even though they could. Other, more pragmatic browsers attempt to display what the developer was intending, even if they break the spec. The difference in implementation makes it difficult for developers to obtain predictable results, and difficult for new browsers to decide how to handle these errors. One argument is that the browser manufacturers should stick t the spec, even if it’s wrong. A more sensible approach would be to change the spec. But that’s another story. I hope Molly posts her slides up soon, as it was a very interesting session.

On a more social note, I had a great time hanging out in Paris. I managed to catch up with old friends as well as making some new ones. Being a vegetarian in Paris was pretty hard work, so I ate a lot of bread and salad while I was there. One day it dawned on me that I hadn’t visited Paris for 7 years. It’s so easy getting over to Paris from London on Eurostar these days, there really is no excuse. So I’ve vowed to go back for a weekend this summer, and explore some of the great museums and galleries the city has to offer. Can’t wait.

Comments

W3C is about creating specifications for implementers, not only browser manufacturers. Right now, the discussions on the HTML WG seem to be dominated by the browser vendors, because they have the biggest issue on interoperability right now, specifically the DOM. (I put CSS on the side because it is not the work of HTML WG.)

I’m very interested by “providing tools for us web developers”. What do you mean by providing? What do you mean by tools?

We give tools sometimes like the validator for example or Amaya (authoring tool), but it is not in the main mission of W3C to create tools. We do sometimes.

The way a standard organization is working is to on a specific topic put people who have interests in the market together to discuss about the technology and define it. So that different implementers can work without reverse engineering what others do.

The HTML WG is open, really open. There are subgroups which will work on designing the specifications, some others will create tutorials and guides, etc. These two types of documents are very different and doesn’t address the same thing at all.

Right now, I would say that the WG lacks of two types of persons: Authoring tools developers and Web (scripting libraries, CMS) developers.

There are already teachers, evangelists.

I would like very much to hear about your concerns and discuss them further. You should have come to me during the conference to talk about it.

Thanks for the feedback. When I talked about tools, I was really meaning in the broadest sense. So language features and UI elements that make our lives as developers easier. Things like horizontal sliders and date pickers that currently require script libraries to implement. Now I know this is what the HTML 5 WG set out to do, and seem to be making great progress so far.

My comment was really about the reaction my question got from the panel. Rather than talking about the different purpose or feature sets of HTML5 and XHTML2, it simply sparked a deep discussion on error handling. Now I understand that error handling is very important to browser vendors, but it is much less important to developers.

For instance, from what I understand, there is a desire to get the font element into the spec. This is driven not by a desire for developers to use the font element. Quite the opposite in fact. It’s driven by a desire for browser manufacturers to know what to do with one if they come across it. The problem is, by include the font element in the spec for the purpose of browser error handling, you actually run the risk of legitimising it’s use to developers.

What you end up with is a tension between the needs of the developers and the needs of the browser vendors. And as you mentioned, the browser vendors have the biggest issues with interoperability right now. My suggestion to Hakon was to consider the possibility of “hiding” the part of the spec relating to errors from the web developer. After all, they are really just guidelines for implementation rather than the language specification.

The form this would take is obviously up for debate. So you could have two separate specs, two facets of the same spec with different levels of detail, or a simpler spec with extra “implementation recommendations”. Either one would help show the right information to the right people without introducing outdated elements into the public spec for the purpose of backwards compatibility.

The HTML panel had a too broad subject to discuss. I don’t think you can fit the whole XHTML2 + Xforms and HTML5 (which includes Web Forms 2) into forty minutes. I’m not sure why you suggest specifications are just for browser vendors though. That’s not the case. (Even if it was the case they would still be of huge benefit to authors as all browsers can converge (based on the specification) to do the same thing.)

Anne, you’ve misread my comments. I’m not suggesting that specifications are just for browser manufacturers. What I am suggesting however is it seems that browser implementation and error handling is the WGs main focus, overriding the needs of the developer.

Do you really think that? Doesn’t a developer need interoperable error handling among browsers so that if a mistake sneaks into a public site it won’t make the site render in very weird ways depending on which browser you use?

It would be really good if developers got more involved in this process and in case of the WHATWG some of them have been. The WHATWG has a very open process and has had that since 2004 and yet not so much people from the “web standards” crowd joined. The WHATWG community has tracked blogs and such though to take feedback written there into account. I’m not sure what more we can do.

I think your comment is constructive. I guess it would help if we could reach a point where a group of talented people decide to make progress on a tutorial, best practices guide. Some people on public-html@w3.org have started to push forward this idea. I think it is a very good idea.

We basically need a good (beautiful) design for the documentation [a template mockup would be nice]. Then people working on creating documentation for each part of the specificiation. It could become the ultimate doc for developers. Should it be a wiki or a mix between wiki and html pages?

If you are willing to participate to such an effort. I’m pretty sure we could do that on public-evangelist@w3.org, plus a web site somewhere on W3C HTML space.

Would you be in? There are many people of great values on the Web and doing positive things together will help everyone. I’m willing to prepare a mini guide for writing documentation so it can be homogeneous. I have to go to a conference on next Thursday, then traveling back to Tokyo on Friday. So Monday morning I’m up to start something.

About the author

User Experience Designer and CEO of Clearleft, Andy is the author of CSS Mastery, curates the dConstruct and UX London events and is responsible for Silverbackapp, a low cost usability testing application for the Mac. Andy is a regular speaker at international conferences and was named one of the 100 most influential people in the UK digital sector by Wired Magazine.