I stumbled across Garann Means's excellent blog post “no country for old hackers” and sure enough it resonates deeply. Web hacking used to be a pretty damn daft calling when you consider what you could actually do, but it sure was fun. It's certainly true that with great power comes, well, stuff that's a bit too easy. Code that works the first time over. Tricks that, erm, what tricks? You just google what you want to do, download the right library, and your problem's solved before you even knew you had one. But all is not lost!

A little while back you might recall that Paul Rouget posted a little demo about Experimenting with HTML5 and native controls. The title is broad but much of the content is about a cool demo of what can be done if browsers implement the HTML menu element. Allowing a site to integrate with the native UI is a powerful approach to making the web easier to use and increase its world domination but it naturally comes with its share of potential security issues.

Interfaces regularly require constant identifiers. You have a node and you want to know if it's an element or a comment. You have a message and you want to know if it's email or SMS. That makes sense. What baffles me is why in designing these APIs we insist on naming things with numbers when we could name them with, you know, names.

There is a lot of thinking going on around the possibility of using well-known Web technologies in order to create not-served-from-HTTP, not-running-in-the-browser, having-access-to-powerful-additional-APIs applications. I very much applaud the first two aspects, the third is more problematic. Not served from HTTP is great because there's a bunch of stuff that I just want to do locally. Some things are great for the cloud, but I like my local drive and there's a lot of information on it that I want to stay there. Not running in the browser is good too (even if it's using the same engine) — frankly there are only so many tabs you can handle. Heightened access is, however, something that we should be a lot more careful about.

Sometimes words have interesting origins. According to his Wikipedia entry, Draco was a 7th century BCE Athenian legislator who replaced the system of oral law and blood feud with a written code, posted clearly in public so that none could ignore it. By our lily-livered modern criteria, his laws are deemed harsh because the few offences that didn't call for meting out the death penalty enslaved their authors. But putting his deeds in context, one has to admit that a written, shared law that is not subject to arbitrary interpretation and the whims of elders is very much a progressive step.

The process of getting a technology standardised and adopted (not necessarily in that order) across a broad spectrum of industry and community can be a complex one, with many failure points. Amongst the problems that a group may face is when the opinions of some (louder) members can give the impression that they represent the group's consensus, causing those who disagree to leave post-haste (it's not as if there wasn't a lot of work to be done elsewhere already). And as we all know, once someone has formed a negative opinion and discussed it around them, it can be very difficult to change it back no matter what the facts say — all you get from there on is confirmation bias.

It's always good to stat the year with a little humour. It's cold and damp outside, the new year party was a disappointment despite you not expecting anything from it, and, if you're me, you went to Spain on vacation and never one to go without having tried local world-renowned specialties you came back with a nasty strain of influenza. All in all, it's a good moment for some cheering up.

A common preoccupation of philosophy is the study of fallacies. I'm unsure how it became this common, I can only presume that scaring up a shared definition of what the truth is has over time proven to be such a dastardly headache-inducing activity that coming up with a list of every way in which one can be wrong might have seemed easier — if only because not only can you drink at the same time, but being drunk is actually a superior methodological approach to producing what is indeed a very, very long list. Or maybe it is because after a few years' worth of honest debate, the young, starry-eyed philosopher grows tired of having his buttocks handed over to him in separate bags by less honourable wranglers. Schopenhauer's Art of Being Right certainly lends credence to the latter.

Many of you are likely to be familiar with HTML5 Boilerplate. If not, I encourage you to check it out, it's a very useful template to bootstrap any HTML5 page you may wish to produce. It includes a number of tricks and best practices that you probably want to use, or at the very least be aware of. One of its most useful parts is that it includes a number of shims that help produce HTML that works pretty much everywhere. I was using it the other day, and though Hey, wouldn't it be nice if we had the same for SVG?

There are many ways of getting someone to do something that you would like them to. You can ask nicely, you can put a gun to their head, you can wallow in the dust and kiss their boots. You can turn on your irresistible Bambi eyes and stare until you prey can only give up. The latter is my personal superpower, but that's not what brings us together today. What brings us together, on this page, at this instant, is Bruce Lawson.

As many noticed on Twitter this morning, Google pulled off one of its neat little logo tricks with a bunch of bouncy balls that fly all over the place. Useless. Very DHTML. But hey, it works on we the geek crowd.

There are days on which you whip out your text editor, take a deep and fulfilling breath, set your jaw to its squarest, type line after line of code as clouds drift by in fast motion, run your code, and it just works. Right there. Right now. Smooth. And then there are days like today when it seems the Universe is bending itself not just backwards but into exotic topologies to tell you you shouldn't be writing code. Days, for instance, very much like today.

WebIDL is a schema language for APIs that is being used (primarily) as part of W3C specifications in order to define various interfaces. If you've read any recent API specification, you've read WebIDL. It is abstract enough that using it one could generate interfaces for a great number of programming languages, but given its origin it is only normal that the vast majority of the time it is used to produce Javascript bindings.

Back in the late XXth century I used to be a big fan of the Persistence of Vision Raytracer (aka POV-Ray). My general lack of design taste, at best very fuzzy understanding of what I was doing, and a sluggish P166 combined to keep me from ever doing anything really good with it, but still I toiled the nights away making shiny metal balls that would reflect checkerboards in misty mornings.

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.