Jeremy Keith Interview

Today I have the pleasure of sharing with you an interview I conducted with Jeremy Keith as I was doing research for a book on print CSS.

We dig into print CSS and CSS and the web in general. I think you’re going to love this.

As an intro, let me steal from Jeremy’s about page

My name is Jeremy. I make websites.

This oversimplifies things but I think this is a very pure description of Jeremy’s work. He is a practitioner of the web and one of the finest minds in our industry. Suffice to say I was excited to get speaking to him.

This is a long one so I will get right down to it.

So, print stylesheets. Are they a necessity in 2017?

Well, Depends on the website, right? I mean on any web project you’re going to have priorities, and the priorities have be based on the nature of the website, the nature of the audience for the website, etc. For some cases, mobile for example, is a really high priority. On others maybe mobile isn’t really considered, although that’s less and less these days.

Print stylesheets are another medium, kind of like mobile in a way, and depending on the content, could be really important. If I was building a recipe website in 2017 I’m absolutely going to have print stylesheets and I think that will be revealed by even a quick bit of user testing.

As long as you had a reasonably varied number of participants, I think pretty early on it would probably come up. “Oh yeah, for this use case I would print out the recipes.” On that kind of site I think there would be few people who thought “Oh yeah, printing out the recipes, we didn’t think of that.”

There are probably entire other websites where it’s just not going to come up in any kind of research though - particularly transactional stuff or when you’re talking about stuff where people fill in forms. It’s pretty unlikely that there’s any kind of print equivalent of that, so it totally depends.

On a recipe site it’ll be a priority to have print stylesheets, whilst a more transactional site, where the user’s inputting a lot of information the priority of print stylesheets is going to be considerably lower. I still think it would be nice if we had boilerplates at least, if we could just made it part of our workflow.

Developers seem to like boilerplates, it’s like they’ve started a project and they’ve immediately got all the scaffolding already. They don’t even know if they’re going to use it yet, but they know they’ve got their build tasks and they’ve got all that stuff ready to go.

I’m more of a fan of waiting until you know that you need a tool before putting it in, but if you’re going to have a boilerplate, why not throw in some really simple print rules that you probably use on every project? Almost like the way people tend to throw in a CSS reset or normalize into every project, you could throw in a print stylesheet as well.

You kind of touched on this, but there seems to be a bit of perception amongst developers or development teams that print really is a “nice to have”. Do you think that’s something that needs to change, where it does get fair consideration, or will it always be “Ok we’ll make the website and then if it comes up in user testing we will retro-fit something”?

I would like it if developers are making that decision consciously. Then if someone consciously decides “Oh yeah print stylesheets aren’t a priority for this site” that’s absolutely fine.

But I think the situation is that people aren’t even thinking about the question, it literally doesn’t cross their mind. I’d at least like people to be aware that it’s a question they should be asking. Even if the answer’s still ‘no’ at least the question came up.

It’s kind of an analogous situation, when I talk about long-term thinking a lot, digital preservation, to me the biggest task is just getting people to even realise that there could even be a problem. The stuff you’re putting online and storing on your hard drives could be gone in 20, 30 years. I’m not saying you should find a solution to that, I’m just saying just be aware it’s a thing that exists. It’s kind of the same with print stylesheets because I don’t think developers are choosing not to use print stylesheets, I think it’s more that it literally hasn’t crossed their mind.

There may even be plenty of good developers who’ve been building websites for a few years now who might not even be aware that print stylesheets exist. It used to be that there was more talk about print stylesheets maybe 12, 15 years ago, considerably more than there is today. So it’s entirely possible that if you got started on the web 3 or 4 years ago, you did some coding course, you got a job, you’re making websites, and you might never even have come across the concept of print stylesheets.

So the awareness that it’s a possibility I think would just be nice. And then like I said I’m totally fine if someone decides “I choose not to have a print stylesheet”.

Why do you think in general browser have been slow to support paged media?

In a nutshell, because it’s invisible.

There’s this essay from years ago by Cory Doctorow called “Metacrap” where he talks about the reason why, in the early days of the web the idea was you’d have meta keywords, meta description to describe your content and that’s what search engines used to index content and weigh up content.

And of course it got spammed.

But even if people were using them in the right way they’d get neglected. The page content would get updated but nobody would update the metadata because it was invisible, and the whole thrust of this essay is describing that invisibility. And it’s kind of the same thinking in the microformats movement as well, it’s that if you want stuff to be kept up to date it should be the same stuff that the end user is seeing, not a separate side by side format, but literally the same stuff that’s being made visible. Because it’s the visible stuff that you keep up to date, it’s the visible stuff you care about.

And when it comes to browser features, the latest CSS layout stuff is visible, the latest animations, that’s visible. It’s all really tangible. And I totally get it because if I was an engineer working on browser stuff, I’d want to be working on the visible stuff because that’s going to get the nice feedback. You get that glow of seeing “oh yeah people are using my stuff and people are excited about what we are doing”.

Print stylesheets fall into that invisible category, the plumbing almost, because it’s an edge case. There’s other situations like this too, for instance, there’s a whole bunch of stuff that got specced in HTML5 and browsers were shipping it. And they shipped it to a certain level and then just left it, and never came back to really fix it. A whole bunch of forms like input type=date. You know it felt like things were going for a while and now we’ve moved on to the next feature. Web components, service workers, something really cool, and nobody wants to work on the plumbing.

Nobody wants to work on the stuff that seems like it’s infrastructure, as opposed to some really cool advancement in technology. And I think the print stylesheets, stuff like paged media, it feels like infrastructure. Nobody would deny that we should have it, it’s not like any browser maker would say “we don’t think this should exist”. It’s not like they think it’s a bad idea, it’s just a bit like hard work. And they do have to prioritise, they’ve only got limited time.

We ended up with this ridiculous situation with responsive images where developers had to crowdfund to support Yoav Weiss so that he could spend the time implementing responsive images in Chrome, because time is money, and browser makers had different priorities.The Chrome team had a different set of priorities, and the only way this was going to get implemented was literally if, developers put their money where their mouth is and spent money funding somebody to put the code into the browser.

The priority of the roadmap for that browser was not in line with having responsive images. And it’s probably the same with print stylesheets. They probably thought “this is the thing we have to do, then this is the stuff we’d like to do” going down, and print stylesheets, I presume, have always been pretty low on that priority list.

On the other hand, browser makers are always saying “Hey developers tell us what you want, tell us what you want”, Some of them even have the places where you can vote up stuff. Now I would imagine that print stylesheets are pretty low on the voting polls compared to the coolest new CSS techniques but maybe there’s a possibility there we could rally the troops and, try and get people to get this message across. But like I say to do that you have to first make sure the troops even know the issue exists.

Whilst we’re on CSS, you’re saying that the new features are the ones that are getting all the limelight. CSS as a technology has been coming on leaps and bounds. With CSS grid coming out recently it’s amazing the stuff we can do. Whenever you first started in web development did you ever think we’d be doing the stuff with CSS that we are doing today?

Maybe not when I first started doing it, but as I thought about the design of CSS over time I did. Because I’m sort of obsessed with design principles, I’ve got this collection of design principles. And one of my favourites on there is a link to Bert Bos’s twenty page brain dump on the principles to keep in mind if you’re designing a format.

It’s meant to be for W3C formats in general, but actually if you look at it, it’s very clearly all the thought that went into CSS. It’s around 20 or 30 things that you’ve got to balance. And you’re balancing things like the power of what you’re doing compared with the learnability of it, how easy it is to pick it up. If you make something really powerful that nobody can learn, and then you’ve kind of failed, right? Or you can make something that’s really easy to learn but you can only to a limited amount of things with it.

If you look at CSS, it’s this one pattern: selector, property, value. That’s it. They boiled it all down into this one pattern, with a lot of complexity in each bit. There’s complex selectors and there can be complex properties and complex patterns, but the basic pattern you could learn in a day, maybe even an hour. Then you start to realise that it is very extensible.

As long as something can fit into that pattern of selector, property, value then it is open for things that you literally can’t imagine. Like there’s use cases we’re not thinking of today that people 5 or 10 years from now will think of and be able to implement using that pattern.

I was fortunate enough to get speaking to Håkon and he shared with me the original spec that he came up with for CSS. It’s clearly come on a lot since then, but even then you could see the potential. You could see that he was laying solid foundations that wasn’t dictating that this is the full feature set.

It’s pretty fascinating to look back and see some of the other proposals and syntax, other than the selector/property, and sort of imagine what our lives would be like if these other syntax hadn’t worked.

There’s an article that looks into web history, it’s really fascinating to imagine “Oh wow there’s this whole alternative history” a different timeline where we write CSS this way.

But what is fascinating about that early CSS, is that a lot of what they were considering had three levels of priorities;

• The user - the ability of the user to style something was a big factor.
• The browser - as in which browser you choose to use comes with opinions about how default styles are done
• The site author - the person who’s making the site.

And it seems to be that over time, these first two have completely dropped off, and now when we’re building websites with CSS we tend to think “Oh yeah, I’m the author of the CSS. Me.” The browser doesn’t get much of a say other than what it supports and what it doesn’t support, and the user gets pretty much no say these days. Most browsers seem to have taken away the user stylesheet option.

That’s a bit of a shame because I thought it was actually quite a good lesson to keep our egos in check. To remember you don’t have the last word, that the user stylesheet would always be the one that would trump anything you said.

Moving back to specifically print stuff: Whenever you’re developing a print stylesheet for a project is there anything specific you do to test?

I do the bare minimum. Ctrl + P, open as PDF. I don’t do actual printing which I really should. But yeah, just Ctrl + P, see how it’s looking. It’s literally the bare minimum. Just see if there’s anything really egregiously wrong.

If you could have one print related wish come true on the web what would it be?

I would probably say consistency. If we had the same level of consistency in print stylesheet support as we have these days in most other CSS things it would make things a lot easier.

I could probably get away these days with making a website for screens where I’m developing in one browser, maybe I test in one other, and I could put the site live and it would probably be alright. Browsers have gotten pretty good at release cycles and standardising.

I certainly couldn’t do that with print stylesheets.

I’d have to open up each browser and test in each one, then when you make a fix for one and now you’ve just broken it in the other. So consistency, it isn’t about particular features as such because, page-break-inside and page-break-before and page-break-after and all that, that’s the real powerful stuff and that exists, but the consistency would really help I think.

Who are some people that you think are doing amazing work in either the print stylesheet space, or just CSS in general, that folk should be aware of?

Rachel Andrew. For both, because she’s got her public facing work which is very much CSS grid, and layout stuff, on which she’s doing amazing work and really championing it. She’s also got this whole behind the scenes thing going on as well with print CSS.

Not so much in the sense of users printing out websites, but actual publishing houses using CSS to format their books. She’s got so much knowledge there. If I had any questions about print CSS I think Rachel Andrew probably would be the person I’d go to.

Then for CSS in general there’s other people like Jen Simmons, again with the CSS grid stuff. Una Kravets for things like, CSS filters. You’ve got Val Head and Sarah Drasner doing the animation stuff. Then all-rounders like Chris Coyier for CSS Tricks. There’s no shortage of people to think, “Oh yeah that’s my go to person” for any questions on that.

On the print stylesheets I remember one of the first people kind of doing a proper in-depth tutorial, maybe 10 years ago now was Mark Bolton. He took an example, like the Guardian as it was back then, and showed what you would do to support print stylesheets. [Editor note: I can’t find this tutorial anymore, if you have a copy link it up in the comments]

If someone is converted to wanting to print well on the web, is there any sort of advice you would give folk, or any resources that you would share

The most recent time I was delving into this was with the Resilient Web Design website / book.

I think I was just Googling and you’ll come across one place that’s for the syntax, like maybe Mozilla Developer Network that says, “Right, here’s the CSS syntax”, but you want somewhere else to tell you “Yeah yeah, but here’s what you need to know about actually using it in production”. Then maybe places like CSS Tricks. I can’t think of anyone in particular, so your book would be very handy.

You said “book / website” when talking about the Resilient Web. Whenever you were writing it, in your head were you writing it as a website or were you writing it as a book?

When I was writing it I was thinking more book. I was thinking it would be like A Book Apart sized thing and probably printed on paper.

Then it was like “Ok now I’ll see, I wonder if anybody wants to publish this?”. I did get in touch with Jeffrey and A Book Apart and they said “It doesn’t really fit with us” because it wasn’t about any particular topic, it was just a sprawling brain dump. After that I realised “Ok I could go to your other publishers” then I thought “No actually I’m happy with it just being on the web.”

Then the more I thought about that I thought “Actually it should be on the web”.

It was really interesting because the actual writing was over a year or maybe a year and a half from when I first began writing it. That makes it sound like it was this big arduous task. It was more that I was doing it on the side.

When I’d have some time I’d sit down. It wasn’t like oh it took me a year and a half to write this thing, it’s more it was a drippy kind of process. But then once I said to myself “I think it’s done”, and I contacted A Book Apart and they say no, I thought ok what’ll I do now, so I made the decision that it should be on the web. The web version should be the canonical version.

I sat down over a weekend to begin the process of designing it for the web because I hadn’t thought about that at all. It was really interesting because even though it took a year and a half to write, by the end of one weekend I thought “Yeah, this looks pretty good”. It was amazing to see, especially today with our complicated workflows, and we think oh it’s so hard to make a website or anything else.

It’s more-or-less a couple of CSS rules for typography and you’re 90% of the way there.

It looked ok to me and I kept thinking that I must be missing something here, but no, this is pretty much what I’m going to ship. It looks fine, looks good, ship it.

The PDF versions that are available on the site are literally me going, Cmd + P from a browser and generating the print versions.

Is there anything else that you’d like to share about print stylesheets or anything else on your mind that you want to talk about?

There is one other case where there is definitely an audience that print is music. I run this Irish music website, thesession.org, and you can generate the sheet music, you can generate as SVGs right there on the page, and I do offer a print version.

But if someone were to print out the whole page there’s text and this SVG thing and then more text. It creates breaking, there’s constantly page breaks inside the SVG, and I’ve tried to do the whole page-break-inside: avoid but that doesn’t seem to be quite right.

I think it’s pretty much an edge case. But that’s the other situation where I’ve started to think about it because that actually does tie into a long tradition of printed matter that isn’t necessarily text based. There’s hundreds of years of this idea of sheet music that you buy music as a written thing that you then play yourself, as opposed to music being audio that you have to listen to. It’s an interesting use case because it’s not text based.

Generally when we’re talking about print stylesheets it’s about making text look good, and this is a weird situation as in a way, sheet music is a form of text, but it’s sort of an image as well.

How can we get that to tie into that long tradition of sharing sheet music? What the web is good at is collapsing geography. It used to be you’d have to travel to another town or you’d have to go somewhere to get your hands on a physical book, and these days you can look at it online and maybe print it out. And it sort of feels like it’s a similar tradition going on there. The web could collapse the geography of getting access to sheet music. It’s a situation where the print use case is high priority, and the browser support is letting it down.

Fin

Thank so you much to Jeremy for taking the time to talk to me about this stuff.

You can find Jeremy on his website.