Christian Heilmann

brvty++ ?

Thursday, May 17th, 2012 at 7:16 pm

Discussion. Responsive images. Picture too much? Srcset weird syntax? Brevity argument. Typing hard. People lazy. Let’s go shopping?

In other, more human, words: in the wake of the current discussion about responsive images and solutions using a picture element or the srcset attribute I came across an argument that always annoys me. And I fear that the more we use that argument the more we alienate ourselves from what the web is and how it became what it is now.

It is the argument for brevity in code above everything, especially markup. Shorter is better as it means people can type more and faster and there is less opportunity for doing things wrong. I call shenanigans on this.

XHTML’s failure was not the amount of code

The argument is based on the assumption that XHTML failed because it was far too much to type and too much work. HTML5 is considered superior as we only type what we need and we can even omit a lot of “optional” code as browsers are superb and will fix our omissions for us. We write much less and it still works. We call this pragmatism. Except it isn’t. It is laziness and the arrogant assumption that we write code for browsers to execute instead of people to read.

XHTML did not fail because of the amount of things you had to write. It failed because of the redundant things you had to write, its over-complexity and that it wasn’t supported the way it was meant to in the most used browser at the time.

And even that wasn’t the issue as nobody wrote all these overly complex constructs by hand – we have editors, templates and snippets for that. Code autocompletion is quite common. We were happy adding truckloads of Object/Embed code for movies until video came around and we never typed any of that by hand. We had tools for that.

Be productively lazy

Good developers are lazy in the sense that they don’t want to repeat themselves. Instead of doing the same boring and tedious task over and over again by hand we write a script to do it for us. This is what programming is for: allow humans to do better things than the repetitive tasks computers were made for.

If you write a lot of code and it never gets used that is frustrating. Very much so. It is also pointless work. However, the mistakes of XHTML should not push us into the other extreme of writing code for computers instead of writing code that executes and is easy to understand for people who want to learn or people who will have to maintain what we wrote.

Markup is different to other code

I love markup. I love the idea of – get this – marking up a document. Adding those funky bracket things around text and URLs is not about shifting bytes, accessing a chipset or setting an interrupt. They are there to give meaning to the texts and to the URLs they contain.

Think of them as highlighting texts with a marker and writing lots of explanations in the margins explaining the meaning of the highlighted texts. Think of them as the little booklet you get with Shakespeare’s Julius Caesar explaining to you what political, social or historical tidbits the author talks about that you would never get as you don’t live in that time.

Good markup brings meaning to text. Don’t take that away from the web for the sake of brevity and technical use cases that are possibly very short-lived.

The web we all work in right now isn’t the result of writing very clever and beautiful code nor is it the result of squeezing the last byte out of our documents to make them work perfect in a certain environment. Most of the atomic micro-optimisations and performance testing and tweaking we do can be undone by a single, badly coached and still well-meaning maintainer.

The web is easy to get into – let’s start with a clean slate

The web we have right now is the result of it being the most accessible media out there. You wouldn’t know how to put your photo and a big heading with your name in the newspaper or TV. But you can learn in a few minutes flat how to write a:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Chris' page</title>
</head>
<body>
<h1>Chris rules!</h1>
<img src="http://example.com/chris.jpg" alt="Photo of Chris" 
     title="that's me, that is">
</body>
</html>

Why the doctype, the head, the charset definition and the body? Surely the browser will do that for us?

Because the code above should be the result of someone caring about the web telling you that:

  • The doctype ensures predictability in displaying your page
  • Defining the language means search engines have it easier to index the page and blind users don’t suffer hearing text pronounced in a different language
  • The UTF-8 means that if you need international characters they will show up instead of rectangles or question marks and
  • The head and body makes a clear distinction where your visible content and the instructions for the browser go.

All of this can be violated with intelligent and amazing tricks and still be valid HTML5 and cool. I am quite sure that a few people twitched at the last point and disagreed as you can style title to be visible and scripts can go in the body and there are use cases for inline styles and so on.

The point though is that none of the above hurts a web developer to write and all of it has a purpose. A structure like that makes it easier for people to learn the basics of what we do. It makes our work predictable, clean, maintainable and – at least to me – professional workmanship instead of crazy and cool geek stuff. We get tied up in the latter and one-up each other showing just what is possible and we forget that people are watching and don’t spend the time to learn the basics. Case in point? The excellent learning resource Codecademy lately added a HTML 101 course, omitting the doctype and alternative text for images in the first steps. We start to see teaching as “showing the quickest way” rather than “showing the cleanest way that explains and yields results”.

We value instant gratification over working for achieving a goal. And the gratification you feel when you achieve something you had to work for lasts longer and feels better than the fast variant. This includes making mistakes and learning from them. Giving people an environment that is incredibly forgiving as the first barrier to entry doesn’t help people grow or reach the goal on their own terms.

Fostering a new generation of webmakers

At Mozilla we have a very interesting thing going: we set a goal for ourselves to foster a community of web makers. We do workshops with journalists on how to use the web as a platform for news and entertainment. We show Popcorn as a way to produce news items that can be maintained without re-shooting. We talk to children and find playful ways to get them into making the web rather than ploughing through apps buying them, playing them for a day or so and discarding them to buy the next one. For this, we use markup and a live editor in the browser. Check out the web arcade to see what I mean.

The next generation of people coming into our market should not be virtual couch potatoes who want everything to work magically and discard it when it breaks or gets slow. Tinkering with the web is what got us where we are. Playing with the open technologies and learning from what others did made us the developers we are now. The next generation should be allowed to feel the same excitement about making that we feel now.

Be brief, but stay comprehensible

Writing not much to achieve something isn’t cool. Writing the least amount possible, getting your message across and making it easy for others to build on what you did is. It means you are free to do other, better, and – for you – much more interesting things.

Let’s focus on tools instead of muddling the basics

If you really want people to write less and achieve more, help improve and build tools for creating in a way that shortens the distance between creation and seeing the result. There is a lot of exciting work being done in this field and we need something for those who don’t want to write code. As people in the know we scoff at the Dreamweavers out there, but it is also our fault when bad code ends up on the web as we were too arrogant to help those who simply want to get their content onto the web.

Share on Mastodon (needs instance)

Share on Twitter

My other work: