Five Questions with Tab Atkins

Avatar of Chris Coyier
Chris Coyier on (Updated on )

DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit!

Tab Atkins (Twitter) is a member of the CSS working group and contributor to several other working groups in the W3C. He works for Google on the Google Chrome Team. Browsers and specs are the bones and blood of our industry so that makes Tab, uhm, a orthopedic surgeon, or something. I ask Tab about all that stuff, and more, below.

*Chris: As a spec writer, what kinds of things are you concerned with when thinking about a new idea for CSS? I know you heavily considered languages when working on the spec for lists. What about things like speed or implementation difficulty? Are there things that would be good for the language of CSS but bad or otherwise not practical for browsers to implement?

Tab: I consider tons of things when thinking up a new idea for CSS. First and foremost is whether the new idea would be useful for authors. Without that, there’s no reason to pursue the idea any further. Before Google hired me to work on specs full time, I was a full-time web dev, so I’ve still got a backlog of things to work through that would have helped me back in my old job.

Another very important consideration is how the new idea will affect CSS as a language. I try to design new features in a manner that’s consistent with existing features when possible, and that I predict will be consistent with new features in the future. Sometimes this yields new ideas, rather than just filtering existing ideas, usually in the form of new knobs I can expose for controlling something that’s currently magic. For example, the marker-attachment property in Lists 3 came partially out of my testing of existing browser behavior for markers. It turns out the control is also useful for internationalization, when one has mixed-direction list items.

An offshoot of that last point is internationalization. CSS 2.1 made a lot of design decisions based on the assumption of a horizontal left-to-right language like English. It was very obviously written by people who speak English or other western European languages. There are a few sops thrown to rtl languages like Hebrew or Arabic, but none at all for vertical languages like Japanese. We try much harder to make all of these languages work as naturally as possible in our newer specs. For example, the values for ‘flex-flow’ in the Flexbox spec automatically respect writing mode and direction, but use natural-sounding names (“row” and “column”) so that authors don’t have to think too hard about them either. A lot of properties that could use ‘left’ or ‘right’ in their descriptions or values now instead use the words ‘start’ or ‘end’, which flip automatically based on whether the language of the element is ltr or rtl (we call these types of values the “logical directions”, as opposed to “physical directions” like ‘left’).

Speed and implementability are important, but never top-level concerns. I generally assume that browsers will figure out how to do whatever’s necessary, and scale things down only when they push back. I’ve been surprised many times in the past both by something being easy or fast that I thought for sure would get shot down, and by things being widely panned that I was certain would be easy or popular.

Finally, every spec has its individual sets of concerns that I need to worry about. As you mentioned, while writing the Lists spec I thought a lot about languages. This permeates the entire spec, from the obvious aspects like the gigantic list of predefined list styles, to less obvious things like the aforementioned ‘marker-attachment’ property, the idea for which came from a 2-day meeting I attended about fixing internationalization problems in HTML and CSS. There’s always a ton of domain-specific knowledge I have to absorb when writing a spec.

*Chris: I know you subscribe to the idea of “Own Your Data.” For instance, not using a third-party service to handle comments on your blog, because that data would be owned by that third-party, not you. How far do you take that idea? Where does that come from?

Tab: I don’t actually handle comments at all on my blog right now, because I haven’t gotten around to writing support for it. ^_^ But yes, I refuse on principle to give my content to a third-party service. I picked up this idea from Tantek Çelik, an all-around great guy who got into Twitter so early he was able to snag one of the 27 single-letter usernames (@t, for those interested).

If you look back in time, you find huge chunks of people’s lives lost from third-party services shutting down. A big, obvious example is the Geocities shutdown from several years back. There are tons of quieter examples, though, of failed social networks or blogging platforms that just reached their end-of-life. If you host your content on someone else’s server, you’re dependent on them staying around forever. When they inevitably shut their doors, they take your data with them. If you own your data and host it on your own domain and servers you control, you’re much less likely to be victim to someone else’s failed business plan.

I don’t take this to extremes, though – I bow to convenience at times. I let Twitter host all of my tweets, because I consider them transient and wouldn’t miss my old stuff if Twitter shut down tomorrow. I let Gmail handle my mail, because it’s just so goddam good and I trust Google to stick around for a while. (Plus, they offer convenient data export, so when they do shut down I should be able to get my data out in a format that I can use.) Tantek goes a lot further. He runs a customized blogging platform called Falcon that hosts nearly all of his content, including things like tweets, and then syndicates it out to third parties like Twitter. I’d like to eventually augment my own blogging platform to do that sort of stuff as well, but I haven’t had the time to focus on it yet.

Even something like hosting my own comments rather than letting Disqus host them isn’t taking things far enough, though. Earlier this year, Tantek ran the first ever IndieWebCamp, a 2-day dev camp focused on the concept of owning your data. One of the most interesting discussion sessions there was about pubsub systems, and how we can leverage them to allow commenters to own their own comments on our blog posts. We already have crappy versions of this in the form of pingbacks, but what if you could post on Twitter or Facebook or your own blog in response to someone’s blog post, and have it show up on the blog? What if other people could continue replying to your comment, and having the entire thing centralized and displayed under the post? We have all the technology to make this happen, and some very smart people are working on making it easy to do.

A final aspect of Own Your Data that’s very important is preferring well-known text-based formats. I ditched mySQL last year in favor of a bespoke JSON-based datastore for my site. It’s less powerful and less efficient than SQL, but you know what? I don’t need that power. I’m not running a huge corporate site with tens of thousands of visits a day. What I do need is the ability to easily back up my data and, more importantly, restore it in the future regardless of what technologies have gone in or out of favor. We’ll always be able to parse JSON, even if JSON suddenly gets rejected en masse, because it’s just so simple. I write my posts in Markdown and convert them to HTML, again because both of those are well known and easy to parse even if they become unpopular in the future. As far as I’m able, none of my data is stored in a proprietary format, because then I’m at the mercy of the company owning that format. In some cases I must bow to efficiency and use a binary format, such as for storing images or videos, but then I always choose an open well-known format, as it’s more likely that I’ll be able to find decoders for those formats in the future.

*Chris: You work directly for Google. Working on web standards isn’t a directly profitable thing. Is it simple big-thinking like: “Web standards are good for the web and what is good for the web is good for Google.” Or is there more to it?

Tab: No, you pretty much got it. Remember that our corporate motto is “Do No Evil”, so our money-making is done in that spirit. We made Chrome (and made it open-source!) simply to make a better browser (the good) which is good for users (more good!) and ultimately good for Google (the money-making).

Good web standards make the web better. If native apps are easier to write, or prettier, or give you abilities that the web doesn’t have, authors will write them instead of web pages. It’s harder to sell ads on native apps, so Google funds my work on web standards to help plug those deficiencies and make the web the best place to write apps.

Note that my actual work is independent of anything Google might specifically want for its other projects. For example, our various web-apps like Gmail or Docs are just a source of use-cases for new features like any other large app on the web. I do what I think is best for authors and the web, and that lifts everyone’s boats.

*Chris: When Dart was first revealed, people compared it to JavaScript and the common attitude was “JavaScript has already won.” I’m sure that fact that JavaScript has more browser support was not lost on the Dart team. What’s your take?

Tab: Personally, I think it’s ludicrous to try and replace Javascript at this point. The common attitude is right – barring any major missteps or a total feature-freeze for several years, Javascript has already won.

That said, I think Dart will end up being very valuable in many ways. There are a million small ways we could make the web better for authors, but each one individually isn’t of much value and is easy to reject. It’s only when you imagine them all working together that you see the immense value in them. I and other JS hackers within Google, like Alex Russell and Erik Arvidsson, have worked closely with the Dart people to redesign the DOM APIs for Dart to make them smaller, saner, and more consistent with the rest of the language. For example, when you get a list of an element’s children, it’s an honest-to-god List in Dart (similar to JS’s Array), not a special NodeList type that lacks all the useful List functions. Other parts of the API return proper Maps or Sets for the same reason. This means you don’t have to memorize a set of custom-named, low-power functions or attributes for the DOM – you can just reuse all the knowledge you already have. Since this has been done throughout the DOM API, the benefits are clearer, and we can use this to help sell the same improvements for the Javascript DOM APIs.

Tangential to that, Dart is also meant as a server-side language, similar to running JS in Node. There’s nothing wrong with that – the server-side space is wide-open, and doesn’t have the same compatibility and coordination constraints that a client-side language does.

*Chris: In software, it’s smart to worry about feature bloat. You can’t add new features forever without making that software worse. It can become harder to learn, harder to explain, harder to make features intuitive and discoverable, and slower running (to name a few). Do you worry about this with CSS?

Tab: Yes, always. I have a bit of a reputation in the CSSWG for pursuing a lot of new features and syntax, but I’m always conscious of bloat. That concern, though, is in direct competition with other concerns, like making sure the web can match native apps, so I’m always juggling things.

Counter-intuitively, sometimes adding new features makes things less complex, when they’re designed well. Take CSS layout, for example. I’m an old hand at bending HTML and CSS to my will and making semantic markup match the Photoshop mockups I’ve been given. These skills have been hard-won, though, and I know (from helping a lot of other devs) that not everyone has the same facility with it that I do. You shouldn’t have to be a genius to make an attractive, responsive site, but that’s essentially the requirement these days. That’s why you see so many layout frameworks.

We’re solving this problem in CSS by designing new layout models. Block layout and floats were designed for documents, not apps, which is why it’s so painful to use them. Flexbox and Grid Layout are two cooperating attempts to make layout models that are good for applications. I’m working closely with Microsoft (who provides my co-editor on Flexbox, and who is the primary driver for Grid) to keep the specs in sync, so that concepts you learn in one model can be reused in the other model.

Another way we try and keep things simpler is to defer to other languages for things that they do better. There are lots of things we could add to CSS that are currently being done in Javascript. We’ve taken some of them where we can provide a real benefit, like Transitions and Animations, but there’s still quite a lot that JS is just better suited for. SVG is another example. Again, when we can provide a real benefit, like the much simpler and more compact linear-gradient() and radial-gradient() functions instead of the <linearGradient> and <radialGradient> elements, we’ll just copy features into CSS. But quite often these days we’ll just use SVG directly, and define a simple interface to it. For example, the Filters spec has a handful of predefined filter functions with a simple syntax, but lets SVG handle more complex or powerful filters with the existing SVG filter elements, and just provides a way to point to them. Another example is the element() function in Image Values, which can point directly to an SVG paint source like a gradient or a pattern and use it natively. This is somewhat useful now, but will become much more powerful in the future as SVG2 adds things like mesh gradients. I’m a member of the SVG Working Group as well, so I have a good view of how the future will turn out and how we can tune CSS to leverage it more effectively.

*Chris: Thanks Tab!