Discussing software, the web, politics, sexuality and the unending supply of human stupidity.


A fictional conversation about progressive enhancement

“I am disappointed by modern web development. Too many bloated frameworks, too much JavaScript, single page web apps, hash bang URLs—it’s all a bit over engineered. We have lost the old techniques of progressive enhancement and in return we have ghastly nonsense like infinite scroll which looks nifty but does not really improve the user experience. It all seems a bit like we have reinvented the era of Flash intros but we think it is so much better because we have made all this pointless bullshit in JavaScript rather than Flash.”

“I take your point, granddad. Perhaps this technology is excessive for mere web sites but we are building web apps now.”

“At some point someone will give me a clear explanation of the difference, riiight?

“Well a web app is something you can’t really experience without a whole lot of scripting. Like, you can’t progressively enhance it.”

“So a web app is defined as a system that requires the JavaScript excesses for it to work. And the argument for the JavaScript excesses is that we need it to build web apps. That sounds a teeny bit circular to me.”

“Bah. Logic. I don’t need logic. Just because you can’t fit it into your theological categories doesn’t mean there isn’t a distinction. Like, I can point to clear examples of web apps. Gmail! Google Docs! They don’t make sense if you don’t understand them as apps. They don’t fit that old fashioned web pages with little blobs of progressive enhancement model that you grumpy old Luddites keep banging on about. If I want to build Google Docs, I need to do it in the new way.”

“You make a good point. You do kind of need a modern browser with bells and whistles to be able to edit a spreadsheet in Google Docs. The user experience of using that in Lynx is going to suck, so perhaps you don’t really need that.”

“See, this brave new world of apps is not so scary! Shall I help you with your Gulpfile now?”

“Let’s not be too hasty. I mean the argument is that Google Docs is completely useless without all the modern front end stuff all working.”


“And there is literally nothing you could display to someone viewing a Google Docs spreadsheet or word processing document if, say, their browser had scripting turned off?”

“Absolutely. This is why you need to approach it with an app mindset rather than a document mindset.”

“What is the user editing in Google Docs?”

“Well, rich text files and spreadsheets.”

“Which are types of what?”


“Can you repeat that word for me?”

“Oh fuck. Documents. You got me.”

“So what could you do if the user loads the page in a browser that doesn’t have the capabilities to edit the document?”

“Well, we could display the document, I guess.”

“And what technology do you need to render rich text and tables in browsers?”

“You know the answer already. HTML and CSS.”

“And if your browser can edit the document—”

“—then it loads the relevant code to edit it. It is still progressive enhancement! I get it.”

“And you can even use your silly Node.js reimplementations of GNU Make if it makes you happy.”

Russian translation

I think in the last month or so, I’ve worked out something important about how I think. I go in cycles between wordy things and visual things. It’s almost like seasons: I’ll go for a long time in word mode and then suddenly switch and I’ll be in image mode.

I can trace it through my background. I sort of never thought of myself as good at any of that design stuff (still don’t, really). I once took an after-school art class, and completely surprised myself that I could, with some attention, actually draw better than I thought I could. We were paired up and had to draw them. I had to sit and draw a girl, and spent about an hour intently focussed on the task of sketching, methodically and carefully, barely even seeing the person but just seeing the textures and light.

And then I kind of got thrown into heavy word mode at school. I balanced this with doing a photography course, which eventually led me to art school. Which I quit, and went off and did philosophy: lots of words, few pictures. And I bounce back and forth between the two. This may explain in part why I quit my Ph.D: word overload. I haven’t been reading as much as I used to. I’m kind of worded out. (Writing doesn’t count: that’s just reflexive at this point.)

I think part of what makes building Ferocity quite good fun has been that at certain points, I’ve hit a technical stump, so I close my text editor, check whatever I’m working on in to Git, then find a design task that needs work. And the result is… not bad. I’m no whiz with CSS. I can crash about and get something nice, but I’m basically doing with CSS what newbie programmers do with code: it’s some combination of copy-and-paste programming and cargo cult programming. I’m not proud of this fact.

Well, having realised that I’m now into visual season, I’m going to ride that particular ride for a while. I’m reading up on typography to try and understand it better. I’ve started reading Thinking With Type and then plan to move on to Detail in Typography.

I’m so frequently having to plonk pixels in the right place, whether for my own projects or for other people’s work, I may as well learn to do it well.

Yesterday, while wandering London supposedly for the purpose of collecting data for OpenStreetMap, I also listened to an interview that Jeremy did on a podcast called Shop Talk Show, a front-end web design/development podcast.

Being the sort of person who gets far more excited about things like date-time representations than about CSS, I hadn’t really kept up on the latest on front-end stuff like I probably ought to. Jeremy mentioned supplementing the new HTML5 semantic elements with ARIA roles. I had almost forgotten about our friends ARIA roles. Interesting. As I noodle with making the markup good on Ferocity, I see no reason not to throw ARIA roles into the mix alongside HTML5, microformats and RDFa. Complexity? Pah. I can handle it.

Even more interesting, being the big ol’ RDF dork that I am: ARIA 1.0 §5 defines the ARIA Roles model… in terms of RDF Schema properties. The web is built on interconnectedness—web standards are too. Lovely.

Custom CSS for Wikipedia on iPad

If you go onto the iOS App Store and search for Wikipedia, you’ll find a wide variety of applications designed to make Wikipedia more readable than it is in the browser. I’ve tried a few but they all have one major problem: you can’t edit. The encyclopedia anyone can edit is not editable if you happen to use software specifically designed for the iPad.

I also don’t like the concept of this software: I don’t believe that you need special software to view specific classes of website. The whole idea of site-specific browsers always seemed strange to me: why do I want to waste disk and memory space making a custom application for one particular site, even if it is one of those vaguely defined “web apps”.

Enter CSS and media queries.

Not a lot of people know this but every registered user on every Wikimedia project including Wikipedia can set up a custom stylesheet as well as a custom JavaScript file. See Help:User style for the details.

Here are a few things I’ve got in my vector.css file with annotations:

So, if I want to edit how Wikipedia looks for me, I can just add stuff to my custom stylesheet, and I can use media queries to target specific devices.

I did a little bit of poking around to find out the media query you use that picks out the iPad and then added it to my vector.css file:

The only thing I’ve added here is changing the look of textareas. For some reason, on the iPad textareas would have all the text in a very small sans-serif font (Helvetica probably). Making it bigger and sticking it in a monospace font makes it easier for a nerdy hacker type like me to edit.

Ah, but that’s okay for insufferable Apple users. What about those enlightened, freedom-loving Android tablet users? Well, you can just stack up media queries for different tablets. I found a media query for the Xoom.

As for the Galaxy Tab, that’s a bit harder. It’s pretty difficult to come up with a media query, but you can use JavaScript…

if ('ontouchstart' in document.documentElement) { // code here to load a custom CSS file and insert into the DOM }

You can read more about the interesting issues the Galaxy Tab has here.

Of course, to pre-empt all the “you don’t care about normal people!” stuff, this is definitely for the very small intersection of CSS geeks and the dorkier end of Wikipedians. But there’s an interesting possibility here for the developers at the Wikimedia Foundation and for others trying to work out how to make MediaWiki look great on tablets. You can get the community to help build your mobile version simply by getting them to submit their personal CSS and JS files, combing through them and combining the best bits together.

Update: Steven Walling asked for some screenshots. Here they are:

Here’s what it looks like to edit a page when not logged in:

After I log in, the edit form looks like this instead: