Is this thing on?

SVG Animation (based on SMIL) and CSS Animation offer some similar features for animating Web content. Harmonising these two technologies has been considered on a number of occasions but a path forward has yet to be established. In response to a feature-by-feature comparison of the two technologies the question was raised, “What are the animation features required, prioritised by use case?” (Meeting minutes which lead to Action-48) although a closely related question was, “What would it take to make CSS Animations achieve feature parity with SVG Animations?”

From face-to-face meeting on Web Animations, as discussed here. There is now a CSS-SVG Effects Task Force activity on this.

It has taken time, but by now CSS and SVG are on the same team, which is kind of a precursor to make the specifications well-integrated as well.

There has been a lot of talk about HTML5 video, codecs, containers, and the lot. That certainly matters, but it isn't something I care about. Assuming the browsers could agree on some standard media codec plug-in interface, like they have done before, browsers shouldn't be different from any other media player like VLC. That way it wouldn't be a major work to update the browsers and the spec itself to new formats. Problem solved.

Read more...

This entry was actually made, well conceptualised, back in early July when I wrote several entries on HTML5 and XHTML2. If I made it then it could be considered prophetic, though it would only show a Nostradamus-style prophetic ability ("there will become a war, and in that war some people will suffer badly"). I lost that opportunity, but if something is worth doing, it is worth doing very, very slowly. And trust me, there will become a war, and in that war some people will suffer badly.

Read more...

Even after the death-of-XHTML2, syntax debate still dominates the day. Here is my contribution.

The XML story

In the beginning was SGML. There is a lot to be said about SGML so I won't. HTML was specified to be an application of SGML, but that never happened in practice. Among browsers Opera kept the pretence of supporting SGML for the longest time, causing us a lot of trouble because Opera behaved differently from every other browser. DocBook is another known SGML application, but in general SGML was no success.

About a decade ago a small group of people started a reformulation of the old SGML standard, First they did it outside of the W3C and later, when the success became apparent, within the W3C. The story of this simplified SGML, now known as XML, may be best told via the annotated XML, by Tim Bray, one of the principal authors. Essentially XML is angle brackets and a number of production rules on top of Unicode (for a fuller description see Comparison of SGML and XML).

Read more...

The CSS 2.1 specification was recently refused entry into the (almost) safe harbour of Candidate Recommendation (CR) status again (for what is it? the fourth time?). This means that the spec is still in a you-can't-believe-a-word-of-this Working Draft state, just like it was seven years ago. This can be summed up in the word frustrating.

To be fair the goalposts have not only been shifted from when Tantek Çelik originally suggested CSS 2.1 one Sunday afternoon, but completely replaced. Originally the idea was just to remove the parts of CSS 2 that nobody wanted to implement. This could have been done in months. It would essentially be a profile of CSS 2, "CSS 2—The useful bits".

Instead CSS 2 was fully rewritten in tedious detail, the goal was now the interoperable CSS 2. This in itself was a good thing. It is much better that the spec is unambiguous than having incompatible implementations of the same, vague, spec. The ones having already implemented CSS 2 would need to adjust their products, but for new CSS 2.1 user agents getting it right the first time is much cheaper, not to speak of the millions of web designers that don't have to make specific hacks for every browser in existence.

But there is a diminishing return. The optimal time/clarity moment was probably when it was first submitted for CR, three years or so ago. This is not to say that what was done after that was unnecessary, but the extra clarity we have gotten for increasingly obscure issues have simply not been worth the additional years. They would have to be resolved at one point or another, but are errata or CSS3 material. The fatigue in the working group and impatience in the designer community is also starting to show, those that haven't given up on it years ago.

It is also slightly unfair. SMIL 2.1 had its first (and last!) working draft in February 2005, and a finished recommendation in December 2005. Were they that more efficient? No, but evidently their goal was to push out a spec as soon as possible rather than solving underlying problems, and crucially nobody outside the working group cared.


With this as a background it is none too surprising that a discussion on wither working group, even in some cases whether working group, has started. One solution I find particularly unconvincing is the argument that the CSS working group should follow the lead of the new HTML working group which currently has 405 self-invited experts, and the number is growing. That is the classic "the project is late, let's throw in many more people" approach. This behind the scenes report may be the best summing up of the situation.

The other symptom is an earlier call for CSS 2.2, reminiscent of my suggestion in 2002 or thereabout of a CSS 3.1. The big problem was as evident then as now. CSS 2.1 may have taken way more time and effort than was originally intended, and now we suffer from it. But sooner or more likely later it will be done. CSS3 on the other hand is a monster many times bigger than CSS 2(.1), the chances of it being fully done, let alone implemented, any time soon is nil. So what about the designers that have waited patiently on rounded corners for a decade and now have the outlook of having to wait another decade so that at least their children will be able to specify it in their style sheet?

David Baron, of the Mozilla organisation, has a well-written entry starting with SVG 1.2 and continuing on how the W3C works, arguing that "We should work on, and implement, the standards that we think are appropriate for Web browsers, and ignore the rest. We should spend our time improving what Web developers and users want, not waste our time improving what is less important or criticizing what isn't going to work in the first place."

Attended the W3C Technical Plenary, in Cannes, France. W3C has played the United Nations of Web standards for a decade now. In that period they have created 85 recommendations (finished specifications). In the works are 2 proposed recommendations, 28 candidate recommendations, and 111 working drafts, 25 of which are in last call (actually a few more, but I dropped some of the more process-oriented documents from the list).

The World Wide Web comprised three standards initially, URL, HTTP, and HTML. The URL, the location of a resource, was the crucial one. It created one standardised way of describing an address. The HTTP transport protocol allowed any machine to pick up or send to that resource, and HTML like this included the URLs as hypertext links. WWW built upon existing Internet standards as well as predecessors like Gopher, FTP, and Enriched Text.

Even so going from just three to a couple hundred standards, not including programming languages and frameworks that are standardised elsewhere, has made the web undertaking less seamless. Every standard has been created to solve a particular problem, or in some cases to cause a particular problem, but often with less interest in making it a well-functioning whole. W3C rules states that new standards should build upon existing ones. This is good in that you can reuse what you have already got and bad in that each new specification will be on top of a huge stack of existing ones, so new specs are going from baroque to rococco before they even get started.

One of the terms that cropped up last year was Web 2.0 (for which we can blame O'Reilly). If there is a Web 2.0 it certainly is in first working draft. However the interesting, in fact the necessary, project is to make all these standards work with each other. Not only "Make it work" but "Make it work well".

This will be slow, methodical work with little hype attached to it and it will take time. Realistically it will take another decade. Most, if not all, of the hundred-some recommendations and recommendation-wannabes will have to be reworked. This process, analogous to the development of CSS 2.0 and CSS 2.1, will not add much features to speak of but it will add quality and ease. Call it Web 2.1, the interoperable web. The process has started, and it is causing friction of the good kind. For instance SVG has been used for specific purposes in the past, now that it is getting used for the broader web audience issues that didn't matter matter before matter now. One of the integration tools is the Compound Document Framework that actually tries to integrate different formats into one. This will not solve the problems but will show where most of them are.

In the five years I have been involved with standards I have seen hundreds of demos on how well a particular method solves a particular problem. Now what remains is the problem of how to solve that particular method.

It was natural to start off a series on web elements with a vilified element that never made it into any web standard and never will, the spacer. Often elements are made for minute details that nobody, man or machine, are interested in. Should abbr or acronym be used? Who cares, except the poor web developer confused by reading the literature and trying to do the right thing.

spacer is an element signifying nothing, containing nothing, and displayed as a rectangle of nothing. It is a pure layout hack. You know the the drill. The correct and proper element to use is object, or use img if you have to for compatibility reasons. The spacer is not to be used. And this is a pity. The wonderful thing about spacer is that you know it is a hack and that it is completely devoid of meaning.

When we do Small-Screen Rendering or a voice representation of a page the goal is to remove the useless stuff and present the useful stuff as well as possible. But what is useless? If a tiny image is stretched horizontally or vertically we assume it is a spacer element and remove it. We are practically always right, but still it is guesswork. For all we knew we could have removed useful information. If that img had been a spacer instead we could have removed it with no remorse.

As it happens there is a convention to express that an img has no real significance. The img element has an obligatory alt attribute, if set to an empty string it is a signal that it has no text equivalent and is thus, in the grand scheme of things, useless. <img src="image-address" alt=""> is just another way of saying spacer with a little more colour.

What about object? This is an element that slices and dices but unlike img there is no way to state the difference between <img src="image-address" alt=""> (i.e. this image is expendable) and <img src="image-address"> (i.e. the designer hasn't considered how the image shall be used in other contexts). <object data="image-address"></object> can mean either of these things, we just don't know. Our options are either to make a guess or to force the decision on to the user.


object is the most general and expressive element with the most flexible fallback. Given <object id="a"><object id="b"><b>Markup</b></object></object> the object with id=b will be shown if and only if the object with id=a can't be shown. If neither can be shown <b>Markup</b> will be shown instead. But only the author knows if the fallback is important or not. Unlike the HTTP q property ("q" is for quality) we can't know if the two id=a and id=b objects are equivalent (e.g. Flash and SVG versions of the same graphics) or if id=b is a barely adequate substitute or worse (e.g. a poster imploring the user to download the Flash plugin).

What can we learn from that? The lowly spacer isn't just more expressive for its purpose than the worker img element, it beats the folk hero object. I am not proposing to introduce the spacer element into "polite company", this ugly duckling won't turn into a swan. CSS can do the same job better, though you need Opera if you want to fully represent what the spacer element can do, and much more flexibly. CSS is the language for layout hacks.

But spacer has many of the properties a good element should have. Its use is clear, you won't use it unless you mean it. It tells something the web designer knows the user agent needs to know but can't truly on its own (that this element is used purely for layout purposes). We don't need to know why this layout hack was added, just that it is a layout hack that will not transfer to other layouts.

Yesterday I finally left the HTML working group. While it was a recent discussion that made me ask myself what was the point in staying, I have grown more disenchanted over the years.

Unlike some I don't agree that XHTML 2.0 is an unmitigated disaster. There is much good stuff in the spec. It is also the first structural work on HTML since HTML 4.01, five years ago. In the meantime the focus has been to make HTML XML-compatible and to split HTML into modules. Whether HTML is formulated in XML or in some kind of SGML matters, but it isn't important relative to how the language itself should evolve. HTML 4 is overdue for an update.

XML (and thus XHTML) has two obvious advantages. It separates between syntax errors (well-formedness) and expectation errors (validity), and the character set of the document is not in doubt. The XHTML modularization itself isn't that useful for practical purposes where the conformance rules and the implicit fallback principle (ignore what you don't understand) is what you need. A side effect of the work on XHTML 2.0 is that XHTML Modularization will be updated to actually describe the modules in the document itself, and not by reference to HTML 4.01 as has been the case up until now.

The revolutionary aspect of XHTML 2.0 was overdone. I don't think the W3C, or browser vendors, or web editor vendors, or any other organization or group has control over the web or its formats. I don't overly worry about Microsoft either. They tried to replace the web before and failed spectacularly. They might try again, but if they do they will fail again. The web is the world's largest installed base. It will change, but not on command. A decade ago change by decree might have been feasible, but this is the difference between shepherding a flock of hundreds of sheep and one of several billions. That flock goes where it wants to go, not where we want it to go.