Continuum

Stop me if you’ve heard this one before. You’re reading an article on Smashing Magazine or A List Apart or some other publication. The article is about a specific feature of CSS, or maybe JavaScript, or perhaps it’s exploring some of the newer additions to HTML. The article is good. It explains how to use this particular feature in your work. Then you read the comments. The first comment is inevitably from someone bemoaning the fact that they can’t use this feature because it isn’t supported in every browser. Specifically, it isn’t supported in some older version of Internet Explorer that they have to support. Therefore the entire article is rendered null and void.

That attitude infuriates and depresses me. It seems to me that it demonstrates a fundamental mismatch between how that person views the job of web development and the way the web actually works.

It is entirely possible—nay, desirable—to use features long before they are supported in every browser. That’s how we move the web forward. If we waited until there was universal support for a feature before we used it, we’d still be using CSS 1.0 and HTML 2.0.

If you use a CSS feature that isn’t supported in a particular browser—like, say, an older version of Internet Explorer—that browser will simply ignore that CSS rule. So you don’t get that rounded corner, or text shadow, or whatever it was. Browsers have the same error-handling mechanism for HTML: if they see something they don’t understand, they just ignore it. The browser will not throw an error. The browser will not stop rendering the page. Browsers are very liberal in what they accept.

It’s a bit trickier with JavaScript: browsers will throw an error; browsers will stop processing the script. That’s why it’s important to use feature detection. That’s also why you definitely don’t want to rely on JavaScript for rendering your content—it’s the most fragile layer of the front-end stack. Note, I’m not saying don’t use JavaScript; I’m saying don’t rely on JavaScript. Otherwise you’ve got yourself a SPOF.

Anyway, my point is—and I can’t believe I still have to repeat this after all these years—websites do not need to look exactly the same in every browser.

“But my client!”, cries the Smashing Magazine commenter, “But my boss!”

If your client or boss expects that a website will look and behave the same in every browser on every device, then where did they get those expectations from? And rather than spending your time trying to meet those impossible expectations, I think your time would be better spent explaining why those expectations don’t match the reality of the web.

It’s like Mike Monteiro says about clients: if they just don’t get something about your design, that’s not their fault; it’s yours. Explaining your design work is part of your design work. It’s the same with web development. It’s our job to explain how the web works …and how the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.

That was true fourteen years ago when John Allsopp wrote A Dao Of Web Design, and it’s still true today. Back then, designers and developers were comparing the web to print and finding it wanting. These days, designers and developers are comparing the web to native and finding it wanting. In both cases, I feel like they’re missing the fundamental point of the web: you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.

Paul Kinlan published a post called This Is the Web Platform where he tabulates the current state of browser support for various features. “Pretty damning” he says:

the feature support that is ubiquitous across the web is actually pretty small especially if you are supporting IE8.

That’s true …from a certain point of view. But it depends on your definition of “support”. If your definition of “support” is “must look and work identically to the latest version of Chrome”, then yes, you’re going to have a smaller set of features you can use (you’re also going to live a miserable existence). But if your definition of “support” is “must be able to access the content and accomplish the task”, then as long as you’re using progressive enhancement, you can use all the features you want and support Internet Explorer 8, 7, 6, 5 …you can support every browser capable of connecting to the internet.

Like Brad said:

There is a difference between support and optimization.

I think part of the problem may be with the language we use. We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.

It’s a subtle Lakoffian thing, but when we talk about “the browser” as if it were a single entity we might be unconsiously reinforcing the expectation that there is one Platonic ideal of browser rendering and that’s what we’re designing for.

There’s another phrase that bothers me, and it’s the phrase that Paul used in the title of his article: “the web platform”. This is something I talked about back in November in my presentation The Power of Simplicity:

But this idea of the web as a platform, I get why from a marketing perspective, we’d want to use that phrase, because it puts the web on equal footing with genuine platforms.

I would say Flash is a platform, and native: iOS and Android and these things. They are platforms, in that it’s all one bundle. And the web isn’t like that.

What I mean is, if you use the Flash platform, then anyone with the Flash plug-in can get your content. It’s on or off. It’s one or zero; it’s binary. Either they have the platform or they don’t. Either they get all your content, or none of your content.

And it’s similar with native apps. If you’ve got the right phone, you can get my app. All of my app. You don’t get bits of my app, you get all my app. Or you get none of it because you don’t have that particular phone that I’m supporting.

And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.

The web is not a platform. It’s a continuum.

Have you published a response to this? :

Responses

Jason Garber

Yesterday afternoon, I posted a little jab at Vine. What you see in that screenshot is a Vine video page completely devoid of usable content owing to a JavaScript error. I’m attempting a pretty typical task and a primary function of Vine’s service: I want to watch Jay-Z’s reaction to Kanye reprising his schtick at the Grammys. As you do.

But I can’t. Something went wrong. You see, Vine’s video pages are built in a way that expects everything goes off without a hitch. The web browser will receive all the necessary assets in the necessary order and execute everything exactly as the developer intended. Unfortunately, that’s not the way the Web often works.

(For those curious, I was using the most up-to-date version of Google Chrome on a MacBook Air running the latest operating system on my home’s broadband Internet connection. Pretty optimal conditions, right?)

So I post about it on Twitter. Friend and colleague Helen Holmes saw my post and kicked off a lengthy back-and-forth that convinced me to commit my thoughts to the page. I’ve been meaning to write about this particular topic for a while and here’s what’s been rattling around in my head.

The Web is a Continuum

The way Vine’s video pages are built illustrates the fault in thinking of the Web as a platform. Platforms are static, defined software environments responsible for running neatly packaged bundles of code: a downloadable native app, an installable desktop application, a Flash movie. iOS, Android, Mac OS X, Windows, Flash—these are platforms.

This is not the Web. Rather, this is not today’s Web. Today’s Web is a continuum.

Today’s Web makes no guarantees. Every bit of code—HTML, CSS, and JavaScript—shipped from a server across the wire acts as a suggestion as to how the browser should interpret and display content. More often than not, everything works planned, but for any number of reasons, a browser could fail to request or render a particular asset. Luckily, browsers are by design resilient in how they handle HTML and CSS. Being liberal in what they accept, browsers will simply ignore any HTML or CSS they don’t understand. Unfortunately, as the Vine example above demonstrates, browsers don’t do so well when encountering JavaScript problems. Rather than carrying on, the browser halts further execution of any script.

That right there highlights the problem with thinking of the Web as a platform. Something will go wrong, even under nearly ideal conditions. And when something inevitably goes wrong, what happens to your website? To your users?

What are we to do? How do we design for hostile browsers?

Experience Layers

Nearly a year ago, I likened the Web to a layer cake. A delicious metaphor, to be certain, but not entirely accurate. In the intervening eleven months, I’ve thought back to that post and the metaphor’s shortcomings. I think I’ve cracked it: The Web is experience layers, built from the bottom up, with each successive layer enhancing the previous.

Practically speaking, this amounts to an initial content layer described using semantic HTML—the Web’s native tongue—enhanced with a layer of style applied with CSS. Embeddable media—images, audio, and video—fall somewhere in the neighborhood of the style layer. Lastly, behavior applied using JavaScript tops out the experience stack.

Lower foundational levels should never rely on higher layers for their primary functionality. Rendering a website’s content, for instance, shouldn’t require JavaScript. Higher levels in the stack should improve the overall experience, hanging on hooks found in the foundational levels (e.g. CSS classes and ID attributes).

Designing from the Bottom Up

In his book Responsive Design Workflow, Stephen Hay details his process for designing in text. The entire book is worth your time, but you can read this particular chapter for free online. Stephen also detailed this technique as well in his presentation at Mobilism back in 2012.

Stephen advocates a content-first approach using plain text. The emphasis on content is critical: everything in your interface is content whether it be the text of an article, the navigation, or control elements like form inputs. It’s all content and it all needs writing.

I love this content-focused approach to design. It just makes sense.

Moving up a layer from plain text, Stephen recommends the popular Markdown text formatting syntax. Markdown is a simple set of formatting rules for describing common text components such as headings and lists and maps closely to the elements in HTML. Awfully convenient. There are a bunch of great Markdown editors available—I use Byword—and every one of them will easily convert Markdown documents to HTML.

Now that you have an HTML file full of well-structured content, you can begin layering on design. This is where existing design tools and techniques like branding guidelines, style tiles, and Photoshop mockups are most useful. The HTML generated from Markdown is barebones, so you’ll want to add additional structural elements as necessary to accommodate your website’s visual design.

This is, to a degree, designing in the browser. I urge you, though, to think of it as designing with the browser. Use the browser as you would every other tool at your disposal.

With your website’s structure and visual design in place, you can bring the whole thing to life with a final layer of behavior applied with JavaScript. As before, this step may involve additional HTML, class names, or ID attributes. That’s okay, but try to keep it lightweight.

Designing in this fashion allows you to easily test along the way—and you should test furiously! Try disabling styles. Does your site still read well? It should if you were rigorous during the content-crafting phase and used Markdown to organize your content. Disable JavaScript and make sure your website’s primary content is still available. Do most of your website’s features still function at a basic level? Most importantly, is your website still accessible in the absence of any one (or more) of these enhancing layers?

A Progressive Experience

If you’ve read this far and thought, “Why, that sounds like progressive enhancement,” you’d be correct! Progressive enhancement is the best strategy for building for today’s Web. With so many people connecting to and interacting with the Web on a mind-boggling number of devices of varying screen sizes in an infinite array of circumstances, it’s critical to design layers of experience. Any layer atop another should serve to enhance the base-level experience of the previous. The essential functionality of the base layers should continue to function smoothly in the absence of higher-layer enhancements.

Approaching design through the lens of experience layers is the design strategy for the Web; one that’s better for users and designers alike.

Many thanks to Trevor Davis for reviewing an early draft of this post.

cdevroe.com

Move the web forward March 3, 2014 Jeremy Keith, on his personal blog: It is entirely possible—nay, desirable—to use features long before they are supported in every browser. That’s how we move the web forward. If we waited until there was universal support for a feature before we used it, we’d still be using CSS 1.0 and HTML 2.0. We agree. For our broad features we do our best to make sure our services work in the widest array of browsers possible. However, we are not afraid, nor will ever hold back from, using the most cutting edge features of the web simply because some percentage of people using old terminals at their desk job can’t use them. Move the web forward. #jeremy keith #web View all posts

# Monday, April 23rd, 2018 at 8:42pm

2 Likes

# Liked by Rodney Rehm on Monday, June 29th, 2015 at 2:52pm

# Liked by Molly E. Holzschlag on Tuesday, August 4th, 2015 at 6:58pm

Related posts

content-visibility in Safari

Safari 18 supports `content-visibility: auto` …but there’s a very niche little bug in the implementation.

CSS Day 2024

A genuinely inspiring event.

Days of style and standards

CSS Day 2023 in Amsterdam.

Add view transitions to your website

Enhance your website, progressively.

Supporting logical properties

Using the CSS trinity of feature queries, logical properties, and unset.

Related links

Help us choose the final syntax for Masonry in CSS | WebKit

I really like the way that the thinking here is tied back to Bert Bos’s original design principles for CSS.

This is a deep dive into the future of CSS layout—make a cup of tea and settle in for some good nerdiness!

Tagged with

New Web Development. Or, why Copilots and chatbots are particularly bad for modern web dev – Baldur Bjarnason

The paradigm shift that web development is entering hinges on the fact that while React was a key enabler of the Single-Page-App and Component era of the web, in practice it normally tends to result in extremely poor products. Built-in browser APIs are now much more capable than they were when React was first invented.

Tagged with

An origin trial for a new HTML <permission> element  |  Blog  |  Chrome for Developers

This looks interesting. On the hand, it’s yet another proprietary creation by one browser vendor (boo!), but on the other hand it’s a declarative API with no JavaScript required (yay!).

Even if this particular feature doesn’t work out, I hope that this is the start of a trend for declarative access to browser features.

Tagged with

With great power, comes great creativity: thoughts from CSS Day 2024 · Paul Robert Lloyd

Here’s Paul’s take on this year’s CSS Day. He’s not an easy man to please, but the event managed to impress even him.

As CSS Day celebrates its milestone anniversary, I was reminded how lucky we are to have events that bring together two constituent parties of the web: implementors and authors (with Sara Soueidan’s talk about the relationship between CSS and accessibility reminding us of the users we ultimately build for). My only complaint is that there are not more events like this; single track, tight subject focus (and amazing catering).

Tagged with

An alternative proposal for CSS masonry  |  Blog  |  Chrome for Developers

Rachel responds to Jen’s recent post with the counter-argument; why masonry should be separate from grid.

I’m not entirely convinced. We heard performance issues as a reason why we could never have container queries or :has, but here we are. And the syntax for a separate masonry spec borrows so heavily from grid that it smells of redundancy.

Tagged with

Previously on this day

12 years ago I wrote Responsive day soon

Counting down the days.

21 years ago I wrote Futurlab shindig

I’m down at the Sussex Arts Club enjoying the hospitality of new web kids on the block, Futurlab ("we got rid of the ‘e’ and passed the savings on to you").

21 years ago I wrote The big smoke

Yesterday was my birthday (discretion prevents me from revealing my current age).

22 years ago I wrote Busking

Before I discovered the web (heck, before the web was even invented), I was a busker.

22 years ago I wrote Jeremy the bear

When I was growing up in Ireland, this television programme used to be on.

23 years ago I wrote Mac OS X Roadshow

Jessica and I spent the day at the Mac OS X Roadshow which came to town today. Overall, it was pretty good.