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.

…was the day (today) when I got the message on yellow background that “your draft has been discarded”. Exactly what led to this event I don’t know, Gmail didn’t tell, was it a keypress in the wrong area of the screen, or a connectivity glitch, or a Google employee deciding that “yes, I do want to be evil”, I simply do not know.

A blog entry titled “what is right with CSS” would be far longer, CSS may remain my favourite W3C specs, but on retrospect there are a number of things that haven’t worked out and should have.

Surely the third round of the ninth circle of hell would be filled up with the designers and programmers of Chinese Internet banking sites.

XKCD recently published the future and found through a good number of Google searches that finishing up HTML5 would herald the demise of newspapers and the Third Coming of Christ.

Coincidentally the W3C declared that finally CSS 2.1 had reached Proposed Recommendation status, and surely, surely!, the end, in the form of CSS 2.1 as Recommendation, should be nigh [Note from the future: it became one later same year]. I recapped the story in an almost four year earlier entry, Cruelly Slow Slog, a slog that cruelly continued for four more years. 11 years of labour is not bad for what was intended as a quick fix.

Urban planning and city architecture has traditionally been a closed process between the client and the planner, possibly with a public hearing (too) late in the process.

We are now at a stage technically, and sometimes socially, that this process could be organised differently. It could be more like the process for producing the HTML5 standard for instance, with early prototyping, public involvement with the stakeholders, scenarios and visualisations, and a transparent process.

Any area potentially under development could be put on Google maps, or local equivalents, as well as on a time line for any interested citizen to see or get involved with.

I am interested to know: What “prior art” do you know of in architecture along these lines, how was it done, what were the consequences and lessons?

Many of the developments in the 10 and 11 versions of Opera are important, but personally my key word for these upgrade would be “disappointment”. There is one feature/bug fix which would make a huge difference in my browser use, not when things works smoothly, but be a life saver when they don’t, fixing bug 155102. For such an important bug it has taken its time fixing. It was still there in Opera 9, when finally there was an interest in fixing it, it was still there in Opera 10, and it is still there in Opera 11.

"How unique – and trackable – is your browser?"

This is well and nice, but there is a problem. These configuration details don't usually change very often and there are so many combinations of these configurations that it is possible, even probable, that your personal settings may be globally unique. In other words nobody else will have the settings that your browser has, even if you haven't personalised it. In the words of this site, your browser will have a fingerprint. Where ever it is used it can be identified. …

(more…)

Today at 十/十/十 十:十:十 in your zone is the third last factino second this century.