Making the web better for authors as well as users

My first website

Today, I found my first website.

The datestamp on the file says December 7, 1996. So, about 17 years ago. I was a freshman in college, messing around with Netscape Composer on my Apple Performa in my dorm room.

You can look at the site, in all its HTML 3.2 glory, right here:

By all accounts, this is a terrible website.

I had discovered the magic of tiled backgrounds. So, surprise surprise, the text is completely illegible. If you want to read it, you’re better off highlighting the text, so you can at least get a consistent background color. I’d suggest that another alternative is viewing source, but really, you don’t want to go there.

I vaguely remember an even more awful version of this page, with more spinning animated gifs. I am fairly certain an animated envelope and smiling Mac graced the screen. Perhaps I edited this file, and that earlier version is gone, or perhaps I misplaced the folder.

In any case, this is the earliest website I can find that I made.

What makes the web great

In the past 17 years, I would like to believe I have learned a few things. I have studied design. Hopefully I commit fewer crimes against layout, typography and color theory. HTML5, CSS3 and JS allow me to do far more than I ever could back then.

And yet, this perfectly awful website is a good reminder of what made the web great. Of what makes the web magnificent.

For all I remember, this website only lived on my computer. Maybe even on the campus network. I very much doubt a domain name ever brought this website to the outside world. So what did it matter?

For a while, when you googled Marc Drummond, you would find an article on the Foundations of Ancient Greek Science. I came across it a number of years ago and thought it seemed strangely familiar. I checked my hard drive and discovered that yes, I had written the essay. This bothered me, because the online version didn’t have my citations. And I discovered that a number of educational sites had linked to this essay.

I can’t find those links today, a reminder that the Internet is not in fact forever. I think the article had been posted on Geocities, which would explain its disappearance. In any case, I always wondered how my article had gotten online, and now perhaps I know, as the essay is also linked on my very first horrible website.

Somehow, this little essay I had written for a freshman science class had traveled across the web for several years. Maybe a decade. Some teachers thought it an interesting resource to share with students. Maybe it had an impact. Or maybe not.

The point is that this only appeared on the Internet because Netscape Composer had made it simple for me as a freshman in college to share my thoughts with the web.

The sharing web

Now my full-time job is sharing information on the web. And like others, I spend quite a lot of time working to ensure that as many people as possible can access the information my organization shares.

Accessiblity. Responsive design. Usability. Information architecture.

We have a lot words to describe how we make the web better for those trying to use it.

Sometimes I worry, however, that we forget the other side of that equation.

The web is a miraculous transformation of the human experience not only because so many people can read what we share, but because so many people can share what we read.

There are far more ways for us to share our thoughts widely than what was available in HTML 3.2 on Netscape.

Anybody can chat on Twitter or Facebook and find an audience, large or small. Setting up a WordPress blog is pretty simple to do. You can share more complex information with more complex tools like Drupal.

We have a wide variety of tools, some simple but easy, along with others that are more complex but more powerful. That wide range allows anybody to share on the web.

Yes, that sharing gets messy. Don’t read the comments, for goodness sake. Still, that person who makes a terrible little website, with an awful web tool, that we can all agree is substandard, might just go on to make better things 17 years later.

Sharing responsive images

Like many others, I have spent a great deal of time learning how to adapt to the way the web has changed. Tools like responsive design are tricky, but they let us reach more people. They help make the web better.

And yet, some of the pieces of this newer, fancier web are quite difficult indeed. Responsive images in particular is something I have talked about at events and conferences.

I have generally been a member of Team Picture rather than Team Srcset, as far as responsive images go. Srcset is good and well for switching out higher resolution versions of images, but the syntax for switching based on viewport switching is... lacking.

We are told that the syntax of picture is too verbose and too difficult for browsers to parse. It may well better match how web authors work with media queries, but no matter. The algorithms are too difficult, we are told.

So we search on.

Client hints

We are told that it will be easier if we all just upgrade our servers so we can use Client Hints. We web authors will simply alter our .htaccess files and set up RegEx on our server to define how the server will choose which image source to deliver based on information from the browser, such as resolution or maybe even viewport width. Client Hints will involve less markup in the HTML, so it will be better.

Responsive image container

Or perhaps in a few years a new responsive image format will be available. We could embed different layers of an image, from small to large, in one image container. Diff layers could allow us to use art direction to provide closely cropped versions at smaller sizes and wider crops at larger sizes. If we’re lucky, once this format is available, we will actually get tools that simplify this for us, maybe Photoshop, maybe something else. We will be embedding our layout details in our image files. But it was one file rather than many, so it will be better.


If we are not able to get the picture element standardized anytime soon, that is ok. We might be able to improve the speed of a polyfill for picture through the use of web components. Web components allow you to create custom elements through the use of HTML templates, imports, shadow DOM, JS and more. The short version is that you could create a web component for picture (the working title is x-picture) that would work faster than just picturefill. Yes, you would have to download two to three JS files, but this could load images faster, if there are no blocking scripts. You can even extend a web component, creating your own template where you define your standard media queries and file name patterns once, then just use one element in your markup, hero-img for example, rather than the numerous elements used in picture. Better performance, better markup, so it will be better.


Or maybe we need yet another syntax. A new option, srcX, is now being discussed, with a series of attributes on an img element, rather than a series of child elements, because that will be easier for browser parsers, and that will be better.

The complexity of performance

All of these solutions for responsive images are complicated. I love picture, but can admit that deciding which image size to use at which breakpoint is difficult at best. The best options I have found involve a good deal of math and sometimes an Excel sheet.

If web design depends on an Excel sheet, maybe something has gone wrong.

All of these solutions have promise. Client hints, a responsive image container, web components, srcX, they all move forward with web performance. And we desperately need better performance.

What I think we often forget is that sometimes performance comes at the cost of complexity for web authors.

Simplifying responsive images

We can do better.

Sassy math

When web authors create their grid layouts with Sass, Compass or another framework, we have options. Sass excels at math, just as Excel does. So if we know the grid columns at each breakpoint, and we know how many columns a type of image takes up at each breakpoint, in theory we should be able to set up a Sass file that just calculates out what image sizes we should use for each breakpoint. That saves on math. It requires a certain amount of knowledge, but when the alternative is Excel, Sass calculations may be better.

Content management systems

I work with Drupal. Drupal 8 will have built-in tools to make responsive images better. Your theme defines its breakpoints. You define what image sizes match up with each breakpoint. With a little setup work, when you upload an image, as a field or with a WYSIWYG, Drupal can generate all the image fields for you, along with inserting picturefill-style markup in your layout where needed. Less muss and fuss is better.

Element queries

I even wonder if we need to loop back to the idea of element queries. Right now we are working very hard on improving performance by starting the download of images sooner. All the work to standardize picture and srcset is really focused on getting browsers to pick up responsive images in the preloader. At that point, the only data that can be used to pick an image source is viewport width. And selecting an image source based on viewport width is difficult, because it involves understanding how your layout shifts at each breakpoint and how that affects image sizes.

We are told that the image preloader increases page loading speed by 20%. I have seen the numbers, and I assume they are accurate. Still, I wonder. Does that vary by the number of images on the page? The size of images? The number of script files blocking downloads?

The idea of element queries is that if you can wait until all of the CSS has been processed, and the parser understands the width of all the layout elements, then responsive images could get much simpler. You could simply say that if the containing element was no wider than 600px, the browser should download an image that is 600px wide. No wider than 400px? 400px wide. And so on and so forth.

Would this mean that images would start loading later in the process? Yes. Would it be easier for authors to set up responsive images on their sites? Probably.

How much would that slow performance? Are there ways to improve performance for an element queries sort of solution? Maybe. Perhaps a web component could help here. Templating could simplify markup so that only one element needed to be inserted into the HTML markup by web authors. Maybe the JS in the component could lookahead and create an array of the possible source sizes for each image, so that at the point layout parsing is complete, all that would be needed is for the correct source to be picked from the array for each image.

There can be only one (or not)

What I really want to get at here is that we are all deadset on finding the one true solution for responsive images. That solution has to provide the best possible performance, both for the end user and for browser parsers.

But maybe what we really need is a range of solutions.

Maybe we need to be reminded that while making the web great for those who access information is very, very important, we still need to make it doable for nearly anybody to share information, too.

There could be a range of options for responsive images. From options that are easier, but slower, like element queries, to higher performance options that are more complex, like Client Hints and a web component version of picture.

Web authors can choose the solution that works for them. Depending on their skill level. Depending on their server setup. Depending on their content management system.

A different sort of elitism

We are told that it is elitist to try to make our websites with the assumption that everybody has the latest and greatest web browsers, with the fastest connections. The alternative is progressive enhancement for users.

What I’d love to see is more understanding that as we come up with new solutions, we also need progressive enhancement for web authors.

It’s easy to dismiss somebody’s site, because its markup isn’t great. Because it’s not using the right frameworks. Because it’s not quite as fast. Or responsive. Or elegant.

My first website was terrible. At the time, maybe not quite so bad. But still, completely unreadable. If that were the end of the story, if I was told that I had done this wrong, and I was a failure, where would I have been today?

Instead, I improved the websites I made, step by step, as new technologies and skills helped me to make things better.

A different sort of conversation

So that’s what I’d like to talk about. How we can make things better. How we can create tools that start simple (even if they’re not the best), and how we can empower web authors to get better, as they level up, develop new skills and have access to better technologies.

That’s what I’d like to talk about. My daughter just turned a year old, and I haven’t blogged much since then. But this is what I’d like to talk about going forward, particularly with responsive images. How can we make things easier? How can we give web authors the range of tools they need?

Not either or. Not there can be only one. A continuum of better.