Le Web politique français bout aujourd'hui de toutes ses bullesD'aucuns se réjouiront du fait qu'au moins il ne bulle pas de tous ses bouts.. De nombreux politiques se jettent gaiment dans les eaux mouvementées des réseaux sociaux et de Twitter comme autant de brigades de sauvetage aux bronzages galbés un jour de grande alerte près de Malibu. Ces dernières semaines ont vu l'arrivée de nouveaux sites pour le PS comme pour l'UMP, ainsi que de leurs plateformes collaboratives la “CooPol” et les “Créateurs de Possibles”. Cet engouement soudain porte en lui nombre d'innovations dans la façon de faire de la politique en France. La question que je me pose ici est de définir ce qu'elles devraient être.

SVG has grown a lot over the past decade. It is now available in the vast majority of phones, and in all browsers save Internet Explorer. Even there, the SVG Web project has made it possible to use it universally, and as Microsoft has recently joined the SVG Working Group, hope is blooming that the next version of their browser will support it natively. As with any technology that has grown over time, hindsight allows one to evaluate past decisions more clearly. As SVG becomes as ubiquitous a part of the Web stack as HTML or CSS, I believe that it is time to revisit these decisions in order to make it easier to use and evolve going forward. My wishlist for the next version is therefore far more concerned with changing or removing existing parts than with adding new features. This is just an early shopping list, more thinking and discussion is required before actually jumping in with most of these items.

Microparsing has been the topic of much debate, often framed in Yes or No positions. I don't believe it possible to have such a clear-cut position on it, though there is little doubt that it can be used excessively. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

This problem is simple and requires very little explanation. Yet it occurs altogether too often. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Schemata (also known as schemas for the less pedantic) seem for some people to belong to an almost mythical dimension. Not only do many appear to believe that you need a schema to "define a namespace" (whatever that means), but even those bereft of that error altogether too often expect a schema to be step in — cape and superpowers flapping in the wind — to fix parts of language design that they wish not to think about. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

At times it feels like the XML family of technologies is just that: one big family. Likewise web technologies. And you wouldn't want to forget anyone when your baby language is born. Or would you? This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Excessive complexity is a scourge that hurts universally, from the paperwork involved in running the simplest of businesses in France to XML Schema's terminology but it is specifically dangerous in XML language design because it is too easily hidden. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

The penultimate chapter in this series works through a motley list of what I had originally dubbed "Wishful Thinking and Doe-Eyed Beliefs". The idea is that while the heart of a language designer is often in the right place; the problem has more to do with what their hands are doing. One of the most common such wishful contraption is to use a naïve versioning strategy. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

In my experience, language design is nothing if not an enthusiastic moment. The sky is full of pie, and no problem seems nigh — in 1.0 that is. Given a choice between the mother of all hangovers and having to work on version 1.1 of a (naïve) language, I'll take that hangover thank-you-very-much and not just because of all the drinking. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

More complex and harder to specify (or for that matter, decide) properly than lacunae values and syntax-level error handling is the processing of errors at the language level, in the context of a well-formed parse tree that has semantic discrepancies. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Contrary to common belief, apart from a set of specific cases, XML does not save you from having to pay attention to error processing at the syntax level. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

A marked design problem, that leads to violations of the DRY (Don't Repeat Yourself) principle as well as to error handling issues, is the lack of lacunae (or default) values. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

We continue our exploration of XML Bad Practices with issues pertaining to language design in general. Language design sits above the previous considerations yet is hard to set entirely apart from them. Some of the examples here mesh into other previous ones, and some apply outside of XML. This first article looks at inconsistency. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

They are amongst us. I've seen them. Or rather their traces. Some XML languages have very obviously been designed for use by cyborgs. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Attributes feel "cheaper" than elements, and it is therefore tempting to use an attribute for quick labelling of content, even if that label is intended for human consumption. That's what HTML's img does, after all. Well just because it was done many years ago doesn't mean it's really right. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

One of the advantages that XML brings is that elements appear in the context of (at the very least) their parents. When one ignores this aspect, the result is useless extraneous information. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Even when people don't author by hand, they still often have to debug by hand. If a name is hard to memorise, not only will it be hard to write, but it will be hard to spot it misspelt. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

After a number of articles on namespaces bad practices, follow a few that talk of the human in the loop. XML was intended to be human-readable. While that idea may make some people chortle, it is still a worthy goal to design with human readability — and writability — in mind. After all, if all one needs is a way to dump data that is only to be readable by machines in a format available anywhere other options will be faster and simpler, e.g. JSON or YAML. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference. Many of the mistakes in this section are by no means limited to XML, and tend to apply to other contexts — notably programming — as well, but they are nevertheless worth recalling.

The "X" in XML stands for "eXtensible". Yet it is altogether too common to see vocabulary authors try to prevent this extensibility, sometimes on purpose, sometimes unknowingly through XML Schema. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

After looking at various ways in which namespaces can be misused at the vocabulary level, here we have a case of redefining how they work, and how it goes wrong. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Namespaces are defined to be URIs (IRI references for the pedants out there), and while many use HTTP URIs, some use anything else ranging from URNs to URIs with made-up schemes. In this article we look at why the latter's a bad idea. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

After having looked at the issues involved in not using a namespace, we look at those that stem from overdoing them. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

XML namespaces are one of the most hated aspects of the XML family. Not even XML Schema has received as much contempt, and it needed a lot more work and far longer specifications in order to get there. Maybe there will be a second version of the XML stack some day, and when that day comes we can hopefully address namespaces in a way that will cause less acrimony. In the meantime, whether you like or dislike them they are what we have. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

At the XML Prague 2009 conference I presented a paper on "Designing XML/Web Languages: A Review of Common Mistakes". Since much of the subject matter presented there is still the topic of heated discussion amongst specialists I thought it a good idea to make a pass through that paper, updating it based on feedback I have received and newer examples, and post it in blog form. I will post each section here as I go through this process. Today, we start simply with the introduction.

Il y a quelques semaines de ça j'ai participé avec quelques autres gentils rigolos à une table ronde mobile pour l'excellente conférence Paris Web 2009. Pour ceux d'entre vous qui ont 1h18 devant eux, voici la vidéo — on y pose des choses sur la table.

Some people don't support standards enough. Some do. And some support them altogether too much. After a while, one waxes poetic, as it were.

I've been working on W3C Widgets for a while now, and I've been antsy to have a runtime to play with. Some already exist, but none at this time that supports the W3C standard. And because of my work on Device APIs I really wanted a playground in which to try out new stuff. I figured it might be more fun to see if I couldn't just get it all done myself. As a result, today Widgeon was officially released as an early alpha.

SVG has long been available in modern browsers, but it is nevertheless underused. More than anything else this is due to browsers that support it not displaying it in HTML content, restricting themselves to fully proper XHTML with its accompanying media type and compatibility issues. Teleporting over from its home planet, one lone piece of Javascript comes to help humans towards better web graphics.

1520 CEST. 3kg. 51cm. A perfect baby.

SVG and HTML5 canvas have often been pitched as opposites, two technologies occupying the same space only one of which would eventually survive. In fact, few believe that as experience over the past few years has shown that they have different usage scenarios. That being said, too little has been done to bring them together and show how they can complement one another. Here, we take a small extra step in that direction.