Archive: October, 2016

MaintainableCSS - an approach to writing modular, scalable and maintainable CSS | By Adam Silver

Adam Silver has written a free online book all about writing maintainable CSS. It dives straight into naming things and takes it from there.

MaintainableCSS is an approach to writing modular, scalable and of course, maintainable CSS.

Carousels Don’t Have to be Complicated - The Media Temple Blog

If you have to use a carousel, it doesn’t have to be complicated. Chris runs through some of the options out there. It turns out you can get surprisingly far with CSS alone.

A Book Apart, Demystifying Public Speaking

Lara’s new book really is excellent. I was lucky enough to get an early preview and here’s what I said:

Giving a talk in public can be a frightening prospect but with Lara Hogan at your side, there’s no limit to what you can accomplish. This book is your shield and sword. Speak, friend, and conquer!

Is DNA the Future of Data Storage? - WSJ

It’s still many years away from being a viable storage option, but here’s the latest on using DNA to back up our collective data.

Magnetic tape may survive a few decades, and DVDs even longer, but they are by no means immortal. Data stored in DNA, provided it’s kept cold and dry, could last for thousands of years.

Mapping the Sneakernet – The New Inquiry

When it seems like all our online activity is being tracked by Google, Facebook, and co., it comforts me to think of all the untracked usage out there, from shared (or fake) Facebook accounts to the good ol’ sneakernet:

Packets of information can be distributed via SMS and mobile 3G but also pieces of paper, USB sticks and Bluetooth.

Connectivity isn’t binary. Long live the papernet!

Last year Benedict Evans wrote about the worldwide proliferation and growth of smartphones. Nolan referenced that post when he extrapolated the kind of experience people will be having:

As Benedict Evans has noted, the next billion people who are poised to come online will be using the internet almost exclusively through smartphones. And if Google’s plans with Android One are any indication, then we have a fairly good idea of what kind of devices the “next billion” will be using:

• They’ll mostly be running Android.
• They’ll have decent specs (1GB RAM, quad-core processors).
• They’ll have an evergreen browser and WebView (Android 5+).
• What they won’t have, however, is a reliable internet connection.

This is the same argument that Tom made in his presentation at Responsive Field Day. The main point is that network conditions are unreliable, and I absolutely agree that we need to be very, very mindful of that. But I’m not so sure about the other conditions either. They smell like assumptions:

Assumptions are the problem. Whether it’s assumptions about screen size, assumptions about being able-bodied, assumptions about network connectivity, or assumptions about browser capabilities, I don’t think any assumptions are a safe bet. Now you might quite reasonably say that we have to make some assumptions when we’re building on the web, and you’d be right. But I think we should still aim to keep them to a minimum.

It’s not necessarily true that all those new web users will be running WebView browser like Chrome—there are millions of Opera Mini users, and I would expect that number to rise, given all the speed and cost benefits that proxy browsing brings.

I also don’t think that just because a device is a smartphone it necessarily means that it’s a pocket supercomputer. It might seem like a reasonable assumption to make, given the specs of even a low-end smartphone, but the specs don’t tell the whole story.

Alex gave a great presentation at the recent Polymer Summit. He dives deep into exactly how smartphones at the lower end of the market deal with websites.

I don’t normally enjoy listening to talk of hardware and specs, but Alex makes the topic very compelling by tying it directly to how we build websites. In short, we’re using waaaaay too much JavaScript. The message here is not “don’t use JavaScript” but rather “use JavaScript wisely.” Alas, many of the current crop of monolithic frameworks aren’t well suited to this.

Alex’s talk prompted Michael Scharnagl to take a look back at past assumptions and lessons learned on the web, from responsive design to progressive web apps.

We are consistently improving and we often have to realize that our assumptions are wrong.

This is particularly true when we’re making assumptions about how people will access the web.

It’s not enough to talk about the “next billion” in abstract, like an opportunity to reach teeming masses of people ripe for monetization. We need to understand their lives and their priorities with the sort of detail that can build empathy for other people living under vastly different circumstances.

That’s from an article Ethan linked to, noting:

When I read articles defining “the mobile web” as “decent hardware and evergreen browsers”, I start thinking hard about our industry biases.

— Ethan Marcotte (@beep) October 13, 2016

The Ruins of Dead Social Networks - The Atlantic

Digital seems like it’s forever because it’s infinitely reproducible, but someone has to think to make that canonical copy or it’s gone-gone.

In this five-year old eulogy for a BBS, Alexis Madrigal ponders the deaths of social networks. Friendster, MySpace, Vine …plus ça change, plus c’est la même chose.

Discovery of peculiar periodic spectral modulations in a small fraction of solar type stars

We find that the detected signals have exactly the shape of an ETI signal predicted in the previous publication and are therefore in agreement with this hypothesis.

jwz: They Live and the secret history of the Mozilla logo

Jamie Zawinski tells the story of how John Carpenter’s They Live led to Shepard Fairey’s Obey Giant which led to Mozilla’s logo.

So that was the time that I somehow convinced a multi-billion dollar corporation to give away the source code to their flagship product and re-brand it using propaganda art by the world’s most notorious graffiti artist.

ZEIT – Next.js

I haven’t made a website with React, but if and when I do, this Node.js framework looks like it aligns nicely with my priorities. It’s all about the universal JavaScript (the artist formerly known as isomorphic JavaScript).

Working with mobile technology - Digital Service Manual - GOV.UK

Excellent guidelines from GDS on providing services that work well on mobile. The watchwords are:

• responsive design,
• progressive enhancement,
• open data, and
• emerging technology (service workers, notifications, etc.).

Native and hybrid apps are rarely justified.

Photo Toning with Gradients & Blend Modes

This use-case for blend modes is making me thirsty.

Also: look who’s blogging again!

Web Bloat Score Calculator

Here’s an interesting metric for measuring performance: take the overall page weight of a URL and divide it by the file size of the screenshot of that URL.

Introducing the Web Share API  |  Web  |  Google Developers

This is an interesting API that just landed in the newest version of Chrome behind a token—it gives you programmatic access to the OS’s share functionality via a (secure) website.

Paul finishes this rundown with the interesting bit:

Future work will also level the playing field for web apps, by allowing them to register to be a “share receiver”, enabling web-to-app sharing, app-to-web sharing and web-to-web sharing.

Maybe I’ll get to see a native “huffduff this” option in my lifetime.

I’ve spent the past few months preparing a new talk for An Event Apart San Francisco (and hopefully some more AEAs after that). As always happens, I spent the whole time vacillating between thinking “this is good!” and thinking “this is awful!” I’m still bouncing between those poles. I won’t really know whether the talk is up to snuff until I actually give it to a live audience.

Over the past few years, my presentations have built upon one another. Two years ago, my talk was called Enhance! and it set the groundwork for using a layered approach to web design and development. My 2016 talk, Resilience, follows on with a process and examples for that approach (I also set myself the challenge of delivering a talk about progressive enhancement without ever using the phrase “progressive enhancement”).

My new talk goes a bit meta, but in my mind, it’s very much building on the previous talks. The talk is all about evaluating technology. I haven’t settled on a final title, but I was thinking about something obtuse, like …Evaluating Technology.

Here’s my hastily scribbled description:

We work with technology every day. And every day it seems like there’s more and more technology to understand: graphic design tools, build tools, frameworks and libraries, not to mention new HTML, CSS and JavaScript features landing in browsers. How should we best choose which technologies to invest our time in? When we decide to weigh up the technology choices that confront us, what are the best criteria for doing that? This talk will help you evaluate tools and technologies in a way that best benefits the people who use the websites that we are designing and developing. Let’s take a look at some of the hottest new web technologies like service workers and web components. Together we will dig beneath the hype to find out whether they will really change life on the web for the better.

As ever, I’ll begin and end with a long-zoom pretentious arc of history, but I’ll dive into practical stuff in the middle. That’s become a bit of a cliché for my presentations, but the formula works as a sort of microcosm of a good conference—a mixture of the inspirational and the practical, trying to keep a good balance of both.

For this new talk, the practical focus will be on some web technologies that are riding high on the hype cycle right now: service workers, web components, progressive web apps. I’ll use them as a lens for applying broader questions about how we make decisions about the technologies we embrace, and the technologies we reject.

Technology. Now there’s a big subject. It’s literally the entirety of human history. I had to be careful not to go down too many rabbit holes. I’m still not sure if I’ve succeeded, but I’ve already had to ruthlessly cull some darlings.

One of the nice things that the An Event Apart crew started doing was to provide link lists for each talk to attendees. That gives me an opportunity to touch briefly on a topic in the talk itself, but allow any interested attendees to dive deeper at their leisure.

For this talk on evaluating technology, I’ve put together this list of hyperlinks for further reading, watching, listening, and researching…

Links

• Design Principles
• The Extensible Web Manifesto
• Developer Fallacies

• Service Workers

  • My First Service Worker
  • Making A Service Worker: A Case Study by Lyza Danger Garnder
  • The Service Worker Lifecycle by Ire Aderinokun
  • An Offline Experience With Service Workers by Brandon Rozek
  • Offline Content With Service Workers by Mike Riethmuller

• Web Components

  • Web Components
  • Responsible Web Components
  • Extensible Web Components
  • Uncomfortably Excited by Alex Russell
  • My Lightning Talk On Web Components by Soledad Penadés
  • Practical Questions Around Web Components by Ian Feather
  • Web Components And Progressive Enhancement by Adam Onishi

• Progressive Web Apps

  • Home Screen
  • Regressive Web Apps
  • The Progressive Web App Dev Summit
  • The Imitation Game
  • Progressive Web Apps: Escaping Tabs Without Losing Our Soul by Alex Russell
  • The Building Blocks of Progressive Web Apps by Ada Rose Edwards
  • Progressive Web Apps: The Long Game by Remy Sharp
  • What, Exactly, Makes Something A Progressive Web App? by Alex Russell

People

• Rosalind Franklin, 1920–1958
• Margaret Hamilton, 1936–
• Tim Berners-Lee, 1955–
• Grace Hopper, 1906–1992
• Hedy Lamarr, 1914–2000
• Ada Lovelace, 1815–1852
• James Burke, 1936–
• Kevin Kelly, 1952–

Papers

• Reports and Working Notes on DNA by Rosalind Franklin
• I, Pencil by Leonard E. Read
• HTML Design Principles edited by Anne van Kesteren and Maciej Stachowiak
• Sketch of The Analytical Engine Invented by Charles Babbage by L. F. Menabrea with notes upon the memoir by the translator Ada Augusta, Countess of Lovelace
• The Coming Technological Singularity: How to Survive in the Post-Human Era by Vernor Vinge

Presentations

• The Real World of Technology by Ursula M. Franklin @ the CBC Massey Lectures, 1989
• The Triumph Of Technology by Lord Sir Alec Broers @ the BBC Reith Lectures, 2005
• How Technology Evolves by Kevin Kelly @ TED, 2005
• When Ideas Have Sex by Matt Ridley @ TED, 2010
• How I Built A Toaster—From Scratch by Thomas Thwaites @ TED, 2010
• Admiral Shovel and the Toilet Roll by James Burke @ dConstruct, 2012
• Unexpected Item In The Bagging Area by Dan Williams @ dConstruct, 2013
• Hypertext As An Agent Of Change by Mandy Brown @ dConstruct 2014
• The Humane Representation Of Thought by Bret Victor @ the UIST and SPLASH conferences, 2014
• Our Comrade The Electron by Maciej Cegłowski @ Webstock, 2014
• Step Off This Hurtling Machine by Alex Feyerke @ JSConf.au, 2014
• The Moral Economy of Tech by Maciej Cegłowski @ the Society For The Advancement Of Socio-Economics, 2016

Books

• The Real World Of Technology by Ursula M. Franklin
• The Rational Optimist by Matt Ridley
• What Technology Wants by Kevin Kelly
• The Inevitable by Kevin Kelly
• Where Good Ideas Come From: The Natural History of Innovation by Steven Johnson
• How We Got To Now: Six Innovations That Made The Modern World by Steven Johnson
• 101 Unuseless Japanese Inventions: The Art of Chindogu by Kenji Kawakami
• The Toaster Project (Or A Heroic Attempt to Build a Simple Electric Appliance from Scratch) by Thomas Thwaites
• Connections by James Burke

kdeldycke/awesome-falsehood: Curated list of falsehoods programmers believe in.

A collection of assumptions programmers often make.

“Dates and Times” is tied with “Human Identity” for the most links.

On Style Maintenance | CSS-Tricks

This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.

I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.

I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.

Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!

The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.

There’s a lot of really good stuff in here to mull over.

My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.

The Palate Deck: Playing Cards for Beer Tasting by Dave Shea — Kickstarter

Dave’s Kickstarter project looks like it could be very handy on Fridays a beer o’clock in the Clearleft office.

Simple, semantic and responsive tables (part II) – Design Today – Wouter Hillen

This uses generated content in CSS to make the aria-label attributes visible on small screens—clever!

Refreshing The Verge: no platform like home - The Verge

Mandy is fighting the good fight for the open web from within Vox Media. Her publishing tools have been built with a secret weapon…

This practice — which I refer to unoriginally as progressively enhanced storytelling — also has the added benefit of helping us make our content more accessible to more kinds of users, especially those with disabilities.

Overview | Atlassian Design Guidelines

A nicely-documented styleguide from Atlassian. It’s not a component library, though—there’s no code here.

Daring Fireball: Why Do Websites Publish AMP Pages?

John is rightly puzzled by AMP:

Can someone explain to me why a website would publish AMP versions of their articles?

Sadly, there is an answer to that question: if a website is so bloated and horrible to use that people won’t stick around to read an article, then AMP starts to look like a good option.

But I don’t have an answer for John’s other question:

Why would any website turn their entire mobile audience — a majority share of their total audience, for many sites today — over to Google?

NASA – Past and Present Dreams of the Future | Benedict Redgrove

A selection from an ongoing photography project—seven years and counting—leading up to the launch of the Orion project.

Rockets of India – Medium

The fascinating history of India’s space program is the jumping-off point for a comparison of differing cultural attitudes to space exploration in Anab’s transcript of her Webstock talk, published on Ev’s blog.

From astronauts to afronauts, from cosmonauts to vyomanauts, how can deep space exploration inspire us to create more democratic future visions?

Flex-grow 9999 Hack

This is an unintuitive—but very handy—use of of the flex-grow property. The use-case outlined here is fairly common.

Part 3: We might not need quantity queries thanks to Flexbox | Charlotte Jackson, Front-end developer

I love the way that Charlotte is documenting her learning process. In this third part of the quantity queries + flexbox saga, it turns out that flexbox is capable of doing the magic all by itself!

How the Web Became Unreadable

Kevin writes a plea on Ev’s blog for better contrast in web typography:

When you build a site and ignore what happens afterwards — when the values entered in code are translated into brightness and contrast depending on the settings of a physical screen — you’re avoiding the experience that you create. And when you design in perfect settings, with big, contrast-rich monitors, you blind yourself to users. To arbitrarily throw away contrast based on a fashion that “looks good on my perfect screen in my perfectly lit office” is abdicating designers’ responsibilities to the very people for whom they are designing.

The Web Platform Podcast : 111 Extensible Web Components on Huffduffer

I spoke my brains in this podcast episode, all about web components, progressive enhancement and backwards compatibility.

SpaceTime Coordinates Memento ~ your personal place in space by govy — Kickstarter

This is a rather lovely idea—a disc with eight rings, each marked with the position of a planet, the arrangement of which corresponds to a specific date.

Fermat’s Library | Why the Internet only just works annotated/explained version.

A ten-year old paper that looks at the history of the ARAPNET and internet to see how they dealt with necessary changes.

Changing a large network is very difficult. It is much easier to deploy a novel new protocol that fills a void than it is to replace an existing protocol that more or less works.

Maintaining and organising a pattern library - FutureLearn

Alla looks at a few different ways of organising the contents of a pattern library, based on her experience with the FutureLearn team.

Building Social: A Case Study On Progressive Enhancement – Smashing Magazine

A step-by-step walkthrough of layering on enhancements to a site. The article shows the code used, but it isn’t really the code that matters—it’s the thought and planning that went into it.

Progressive Misconceptions, From the Notebook of Aaron Gustafson

Good stuff from Aaron…

Progressive enhancement embraces the idea of experience as a continuum rather than some singular ideal.

Progressive enhancement should not be viewed as a challenge to JavaScript any more than concepts like namespacing, test driven development, or file concatenation & minification are; it’s just another way to improve your code.

Progressive enhancement’s focus on providing a baseline experience that makes no assumptions about browser features will provide a robust foundation for any project.

Laurie Voss has written a thoughtful article called Web development has two flavors of graceful degradation in response to Nolan Lawson’s recent article. But I’m afraid I don’t agree with Laurie’s central premise:

…web app development and web site development are so different now that they probably shouldn’t be called the same thing anymore.

This is an idea I keep returning to, and each time I do, I find that it just isn’t that simple. There are very few web thangs that are purely interactive without any content, and there are also very few web thangs that are purely passive without any interaction. Instead, it’s a spectrum. Quite often, the position on that spectrum changes according to the needs of the user at any particular time—are Twitter and Flicker web sites while I’m viewing text and images, but then transmogrify into web apps the moment I want add, update, or delete a piece of text or an image?

In any case, the more interesting question than “is something a web site or a web app?” is the question “why?” Why does it matter? In my experience, the answer to that question generally comes down to the kind of architectural approach that a developer will take.

That’s exactly what Laurie dives into in his post. For web apps, use one architectural approach—for web sites, use a different architectural approach. To summarise:

• in a web app, front-load everything and rely on client-side JavaScript for all subsequent interaction,
• in a web site, optimise for many page loads, and make sure you don’t rely on client-side JavaScript.

I’m oversimplifying here, but the general idea is:

• build web apps with the single page app architecture,
• build web sites with progressive enhancement.

That’s sensible advice, but I’m worried that it could lead to a tautological definition of what constitutes a web app:

1. This is a web app so it’s built as a single page app.
2. Why do you define it as a web app?
3. Because it’s built as a single page app.

The underlying question of what makes something a web app is bypassed by the architectural considerations …but the architectural considerations should be based on that underlying question. Laurie says:

If you are developing an app, the user ideally loads the app exactly once — whether it’s over a slow connection or not.

And similarly:

But if you are developing a web site consisting of many discrete pages, the act of loading goes from a single event to the most common event.

I completely agree that the architectural approach of single page apps is better suited to some kinds of web thangs more than others. It’s a poor architectural choice for a content-based site like nasa.gov, for example. Progressive enhancement would make more sense there.

But I don’t think that the architectural choices need to be in opposition. It’s entirely possible to reconcile the two. It’s not always easy—and the further along that spectrum you are, the tougher it gets—but it’s doable. You can begin with progressive enhancement, and then build up to a single page app architecture for more capable browsers.

I think that’s going to get easier as frameworks adopt a more mixed approach. Almost all the major libraries are working on server-side rendering as a default. Ember is leading the way with FastBoot, and Angular Universal is following. Neither of them are doing it for reasons of progressive enhancement—they’re doing it for performance and SEO—but the upshot is that you can more easily build a web app that simultaneously uses progressive enhancement and a single-page app model.

I guess my point is that I don’t think we should get too locked into the idea of web apps and web sites requiring fundamentally different approaches, especially with the changes in the technologies we used to build them.

We’ve made the mistake in the past of framing problems as “either/or”, when in fact, the correct solution was “both!”:

• you can either have a desktop site or a mobile site,
• you can either have rich interactivity or accessibility,
• you can either have a single page app or progressive enhancement.

We don’t have to choose. It might take more work, but we can have our web cake and eat it.

The false dichotomy that I’m most concerned about is the pernicious idea that offline functionality is somehow in opposition to progressive enhancement. Given the design of service workers, I find this proposition baffling.

This remark by Tom is the very definition of a false dichotomy:

People who say your site should work without JavaScript are actually hurting the people they think they’re helping.

He was also linking to Nolan’s article, which could indeed be read as saying that you should for offline instead of building with progressive enhancement. But I don’t think that’s what Nolan is saying (at least, I sincerely hope not). I think that Nolan is saying that we should prioritise the offline scenario over scenarios where JavaScript fails or isn’t available. That’s a completely reasonable thing to say. But the idea that we should build for the offline scenario instead of scenarios where JavaScript fails is absurdly reductionist. We don’t have to choose!

But I can certainly understand how developers might come to be believe that building a progressive web app is at odds with progressive enhancement. Having made a bunch of progressive web apps—Huffduffer, The Session, this site, I can testify that service workers work superbly as a layer on top of an existing site, but all the messaging around progressive web apps seems to fixated on the idea of the app-shell model (a small tweak to the single page app model, where a little bit of interface is available on the initial page load instead of requiring JavaScript for absolutely everything). Again, it’s entirely possible to reconcile the app-shell approach with server rendering and progressive enhancement, but nobody seems to be talking about that. Instead, all of the examples and demos are built with an assumption about JavaScript availability.

Assumptions are the problem. Whether it’s assumptions about screen size, assumptions about being able-bodied, assumptions about network connectivity, or assumptions about browser capabilities, I don’t think any assumptions are a safe bet. Now you might quite reasonably say that we have to make some assumptions when we’re building on the web, and you’d be right. But I think we should still aim to keep them to a minimum.

Tom’s tweet included a screenshot of this part of Nolan’s article:

As Benedict Evans has noted, the next billion people who are poised to come online will be using the internet almost exclusively through smartphones. And if Google’s plans with Android One are any indication, then we have a fairly good idea of what kind of devices the “next billion” will be using:

• They’ll mostly be running Android.
• They’ll have decent specs (1GB RAM, quad-core processors).
• They’ll have an evergreen browser and WebView (Android 5+).
• What they won’t have, however, is a reliable internet connection.

Those seem like a reasonable set of assumptions. But even there, things aren’t so simple. Will people really be using “an evergreen browser and WebView”? Millions of people use proxy browsers like Opera Mini, which means you can’t guarantee JavaScript availability beyond the initial page load. UC Browser—which can also run in proxy mode—is now the second most popular mobile browser in the world.

That’s just one nit-picky example, but what I’m getting at here is that it really isn’t safe to make any assumptions. When we must make assumptions, let’s try to make them a last resort.

And just to be clear here, I’m not saying that just because we can’t make assumptions about devices or browsers doesn’t mean that we can’t build rich interactive web apps that work offline. I’m saying that we can build rich interactive web apps that work offline and also work when JavaScript fails or isn’t supported.

You don’t have to choose between progressive enhancement and a single page app/progressive web app/app shell/other things with the word “app”.

Progressive enhancement is an architectural approach to building on the web. You don’t have to use it, but please try to remember that it is your choice to make. You can choose to build a web app using progressive enhancement or not—there is nothing inherent in the nature of the thing you’re building that precludes progressive enhancement.

Personally, I find progressive enhancement a sensible way to counteract any assumptions I might inadvertently make. Progressive enhancement increases the chances that the web site (or web app) I’m building is resilient to the kind of scenarios that I never would’ve predicted or anticipated.

That’s why I choose to use progressive enhancement …and build progressive web apps.

Oversharing with the browser’s autofill / Stoyan’s phpied.com

Equal parts clever and scary. By using autocomplete in HTML and some offscreen positioning in CSS, it’s possible to extract some unexpected personal information.

I expect browsers will be closing these holes pretty quickly.

Hatnote Listen to Wikipedia

Listen to the sound of Wikipedia’s recent changes feed. Bells indicate additions and string plucks indicate subtractions. Pitch changes according to the size of the edit; the larger the edit, the deeper the note.

Your Social Media Fingerprint

Clever! By exploiting the redirect pattern that most social networks use for logging in, and assuming that site’s favicon isn’t stored in a CDN, it’s possible to figure out whether someone is logged into that site.

The Service Worker Lifecycle  |  Web  |  Google Developers

Jake goes into the details of what exactly is happening when a service worker is installed or replaced.

This is easily the most complex part of working with service workers, and I think I’m beginning to wrap my head around it, but the good news is that, for the most part, you don’t really need to know the ins and outs of this to get started (and dev tools are now making it easier to nuke from orbit if this begins to bite).

Quantity queries and Flexbox part 2 | Charlotte Jackson, Front-end developer

This is so great! Charlotte takes two previous ideas she’s been writing about (quantity queries and flexbox) and puts them together in a new way.

It took me a while to get around what the nth-child selectors are doing here, but Charlotte does such great job of explaining the CSS that even I could understand it.

Technical Credit by Chris Taylor

Riffing on an offhand comment I made about progressive enhancement being a form of “technical credit”, Chris dives deep into what exactly that means. There’s some really great thinking here.

With such a wide array of both expected and unexpected properties of the current technological revolution, building our systems in such a way to both be resilient to potential failures and benefit from unanticipated events surely is a no-brainer.

Addicted to Your iPhone? You’re Not Alone - The Atlantic

The dreadful headline makes this sound like another pearl-clutching moral panic, but there’s some good stuff in this somewhat hagiographic profile.

Harris is developing a code of conduct—the Hippocratic oath for software designers—and a playbook of best practices that can guide start-ups and corporations toward products that “treat people with respect.” Having companies rethink the metrics by which they measure success would be a start.

Thoughtful CSS Architecture | Sparkbox | Web Design and Development

A good overview of ideas and techniques for structuring CSS and naming classes.

Does Progressive Enhancement Have a Place in Today’s Web? - George Brocklehurst, thoughtbot - YouTube

Spoiler: the answer is “Yes!”.

It’s a way of building web applications that’s very similar to making a sandwich.

This talk is itself a tasty sandwich of good stuff.

Thimble by Mozilla - An online code editor for learners & educators.

This is a really, really nice tool for creating HTML, CSS, and JavaScript without needing a separate text editor. And then you can publish the results to a URL.

It’s a bit like CodePen but it shows the whole HTML document, which makes it particularly useful for teaching front-end development to beginners (ideal for Codebar!).

CodePen for snippets; Thimble for pages.

Enhancing a comment form: From basic to custom error message to BackgroundSync | justmarkup

This is a truly fantastic example of progressive enhancement applied to a form.

What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.

Superb!

The Amazing Women of CSS

Rachel lists some of the best CSS developers working on the web today:

• Anna,
• Charlotte,
• Estelle,
• Jen,
• Lea,
• Léonie,
• Sara,
• Una,
• Val, and
• Zoe.

You Might Not Need JavaScript

Una has put together a nice collection of patterns that use CSS for interactions. JavaScript would certainly be more suitable for many of these, but they still provide some great ideas for robust fallbacks.

Pragmatic, Practical, and Progressive Theming with Custom Properties by Harry Roberts

Harry demonstrates a really good use for CSS custom properties—allowing users to theme an interface.

The Web is not Fashionable. - The blog of Ada Rose Edwards

This is such a great perspective on what it’s like to build for the web over the long term. The web will always be a little bit broken, and that’s okay—we can plan for that.

The Web has history. If you build with web technology it will stick around. We try not to break the web even if it means the mistakes and bad decisions we have made in the past (and will make in the future) get set in stone.

Dan McKinley :: Choose Boring Technology

A somewhat contentious title but there’s some really smart thinking here about choosing and evaluating technology.

The slidedeck version is even clearer.

Your Private Encrypted Browser | Tenta Browser

A browser for Android that specifically touts privacy and security as its key features.

Taking Pattern Libraries To The Next Level – Smashing Magazine

Here’s an epic brain dump by Vitaly on the challenges of putting together a pattern library and then maintaining it.

Sacrificing consistency for usability is fine. A slightly open-ended, inconsistent but heavily used pattern library is better than a perfectly consistent pattern library that is never used.

Can we stop bad-mouthing CSS in developer talks, please? | Christian Heilmann

I agree with Chris’s conclusion here, but for a different reason. Here’s a shocking thought: what if the cascade is a feature not a bug?

gasp!

(no really; imagine if programmers stopped trying to bend CSS to their immutable will, and instead embraced its declarative power)

You Can’t Get Comfortable Anymore in Web Development | Rey Bango

We should be asking why we need a framework or a tool before just dropping it in. It’s not to say that you shouldn’t learn new things. YOU ABSOLUTELY SHOULD BE CONTINUOUSLY LEARNING! But you should ensure that you have a solid base to work from.

As part of my ongoing obsession with figuring out how we evaluate technology, I finally got around to reading Matt Ridley’s The Rational Optimist. It was an exasperating read.

On the one hand, it’s a history of the progress of human civilisation. Like Steven Pinker’s The Better Angels Of Our Nature, it piles on the data demonstrating the upward trend in peace, wealth, and health. I know that’s counterintuitive, and it seems to fly in the face of what we read in the news every day. Mind you, The New York Times took some time out recently to acknowledge the trend.

Ridley’s thesis—and it’s a compelling one—is that cooperation and trade are the drivers of progress. As I read through his historical accounts of the benefits of open borders and the cautionary tales of small-minded insular empires that collapsed, I remember thinking, “Boy, he must be pretty upset about Brexit—his own country choosing to turn its back on trade agreements with its neighbours so that it could became a small, petty island chasing the phantom of self-sufficiency”. (Self-sufficiency, or subsistence living, as Ridley rightly argues throughout the book, correlates directly with poverty.)

But throughout these accounts, there are constant needling asides pointing to the perceived enemies of trade and progress: bureaucrats and governments, with their pesky taxes and rule of law. As the accounts enter the twentieth century, the gloves come off completely revealing a pair of dyed-in-the-wool libertarian fists that Ridley uses to pummel any nuance or balance. “Ah,” I thought, “if he cares more about the perceived evils of regulation than the proven benefits of trade, maybe he might actually think Brexit is a good idea after all.”

It was an interesting moment. Given the conflicting arguments in his book, I could imagine him equally well being an impassioned remainer as a vocal leaver. I decided to collapse this probability wave with a quick Google search, and sure enough …he’s strongly in favour of Brexit.

In theory, an author’s political views shouldn’t make any difference to a book about technology and progress. In practice, they barge into the narrative like boorish gatecrashers threatening to derail it entirely. The irony is that while Ridley is trying to make the case for rational optimism, his own personal political feelings are interspersed like a dusting of irrationality, undoing his own well-researched case.

It’s not just the argument that suffers. Those are the moments when the writing starts to get frothy, if not downright unhinged. There were a number of confusing and ugly sentences that pulled me out of the narrative and made me wonder where the editor was that day.

The last time I remember reading passages of such poor writing in a non-fiction book was Nassim Nicholas Taleb’s The Black Swan. In the foreword, Taleb provides a textbook example of the Dunning-Kruger effect by proudly boasting that he does not need an editor.

But there was another reason why I thought of The Black Swan while reading The Rational Optimist.

While Ridley’s anti-government feelings might have damaged his claim to rationality, surely his optimism is unassailable? Take, for example, his conclusions on climate change. He doesn’t (quite) deny that climate change is real, but argues persuasively that it won’t be so bad. After all, just look at the history of false pessimism that litters the twentieth century: acid rain, overpopulation, the Y2K bug. Those turned out okay, therefore climate change will be the same.

It’s here that Ridley succumbs to the trap that Taleb wrote about in his book: using past events to make predictions about inherently unpredictable future events. Taleb was talking about economics—warning of the pitfalls of treating economic data as though it followed a bell-curve curve, when it fact it’s a power-law distribution.

Fine. That’s simply a logical fallacy, easily overlooked. But where Ridley really lets himself down is in the subsequent defence of fossil fuels. Or rather, in his attack on other sources of energy.

When recounting the mistakes of the naysayers of old, he points out that their fundamental mistake is to assume stasis. Hence their dire predictions of war, poverty, and famine. Ehrlich’s overpopulation scare, for example, didn’t account for the world-changing work of Borlaug’s green revolution (and Ridley rightly singles out Norman Borlaug for praise—possibly the single most important human being in history).

Yet when it comes to alternative sources of energy, they are treated as though they are set in stone, incapable of change. Wind and solar power are dismissed as too costly and inefficient. The Rational Optimist was written in 2008. Eight years ago, solar energy must have indeed looked like a costly investment. But things have changed in the meantime.

As Matt Ridley himself writes:

It is a common trick to forecast the future on the assumption of no technological change, and find it dire. This is not wrong. The future would indeed be dire if invention and discovery ceased.

And yet he fails to apply this thinking when comparing energy sources. If anything, his defence of fossil fuels feels grounded in a sense of resigned acceptance; a sense of …pessimism.

Matt Ridley rejects any hope of innovation from new ideas in the arena of energy production. I hope that he might take his own words to heart:

By far the most dangerous, and indeed unsustainable thing the human race could do to itself would be to turn off the innovation tap. Not inventing, and not adopting new ideas, can itself be both dangerous and immoral.

Can These Pornographers End ‘MILFs,’ ‘Teens,’ and ‘Thugs’? | The Nation

A fascinating look at an attempt to redefine the taxonomy of online porn.

Porn is part of the ecosystem that tells us what sex and sexuality are. Porn terms are, to use Foucault’s language, part of a network of technologies creating truths about our sexuality.

Reminds of the heady days of 2005, when it was all about tagging and folksonomies.

The project, at its most ambitious, seeks to create a new feedback loop of porn watched and made, unmoored from the vagaries of old, bad, lazy categories.

Is animation “just” an enhancement? + WebGL effects & SVG paths explained - The UI Animation Newsletter  #16.30

Yes! Yes! Yes! Val nails the essence of progressive enhancement:

Never feel like it’s a waste to dedicate time to the enhancements; to put real thought and effort into your animations and what they’ll contribute to the experience. Progressive enhancement is all about freeing up your time to make the enhancements great once you’ve got that basic core functionality covered. That’s the path to making new and wonderful things on the web while also being responsible. It’s quite literally a way to get the best of both worlds.

Jamie and his Lion: The adults who take their soft toys to work - BBC News

Hey, it’s Jamie! (and Lion, of course)

The last day of hot metal press before computers come in at The New York Times | Aeon Videos

The 1978 short film Farewell, etaoin shrdlu documents the changeover from linotype to digital typesetting at The New York Times.

An evenhanded treatment of the unremitting march of technological progress, Weiss’s film about an outmoded craft is stylistically vintage yet also immediate in its investigation of modernity.

The 1989 CBC Massey Lectures, “The Real World of Technology” - Home | Ideas with Paul Kennedy | CBC Radio

I’m about to start reading Ursula M. Franklin’s The Real World of Technology based on Mandy’s recommendation. The audio files from original series of lectures on which the book is based are still available here, but alas not in any huffduffable form.

Why we are suing Apple for better HTML5 support in iOS?

Finally! Apple are being sued for refusing to allow any non-Webkit browsers to be installed on iOS.

I’m not usually in favour of legal action but in this case, there doesn’t seem to be any other recourse.

We would be delighted at Nexedi to create a Web browser for iOS with better HTML5 support based on a recent version of Blink library for example. But as soon as we would publish it, it would be banned from Apple’s AppStore. Many developers have experienced this situation already. Many companies are being hurt by this situation. Some companies have already begged Apple to improve HTML5 support in iOS with little significant results.

Deep-Fried Data

Another typically excellent talk from Maciej, this time to the Library of Congress. Digital preservation, surveillance, machine learning …it’s all in there, and it makes for grim reading, but there’s also optimism:

My dream for the web is for it to feel like big city. A place where you rub elbows with people who are not like you. Somewhere a little bit scary, a little chaotic, full of everything you can imagine and a lot of things that you can’t. A place where there’s room for chain stores, room for entertainment conglomerates, but also room for people to be themselves, to create their own spaces, and to learn from one another.

What about CSS? Progressive Enhancement & CSS // Speaker Deck

I heard nothing but good things about this talk from the Fronteers conference. There’s some great stuff in here—I really like its historical perspective.

Refreshing The Verge: Facebook video, Google AMP, and the (non)future of the web - The Verge

AMP loads super, super quickly and is simply a better experience right now. So can we add enough design to make an AMP page feel like The Verge?

What a depressing conclusion! But I guess it’s easier than, y’know, actually fixing the bloated Verge website, packed with megabytes and megabytes of invasive trackers. It’s no wonder people prefer the AMP experience. Yet the idea of improving the website isn’t even raised in this whole article.

Then again, this is the same guy who tried to lay the blame for The Verge’s abysmal performance at the feet of web browsers.

@supports will change your life | Charlotte Jackson, Front-end developer

Charlotte is a big fan of feature queries.

Heydon/fukol-grids

The most minimal responsive, flexible grid library you can find. In fact, here’s the whole thing:

.fukol-grid {
  display: flex; /* 1 */
  flex-wrap: wrap; /* 2 */
  margin: -0.5em; /* 5 (edit me!) */
}

.fukol-grid > * {
  flex: 1 0 5em; /* 3 (edit me!) */
  margin: 0.5em; /* 4 (edit me!) */
}

Down with the tool fetish - QuirksBlog

PPK responds in his typically strident way to posts by Tim and Bastian. I don’t agree with everything here, but I very much agree with this:

It’s not about what works for you. It’s about what works for your users.

If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.

If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.

But it’s worth remembering this caveat too.

Hiding inline SVG icons from screen readers | 456 Berea Street

A good reminder from Roger on how to hide images from an SVG sprite from assistive technology (use aria-hidden) and how to expose them (use title elements within the sprite).

Benjamin Parry @benjaminparry ~ Why I Volunteer And Why You Should Too

Benjamin’s retrospective on three years of volunteering at web conferences, some of them run by Clearleft.

A Redesign with CSS Shapes · An A List Apart Article

Eric walks through a really nice use of CSS shapes and @supports on a page of the An Event Apart site.

It’s a nice little illustration of how we can use advanced features of CSS right now, without the usual wait for widespread support.

First Time User Experiences

Krystal’s excellent annotated collection of onboarding examples.

SmashingConf Freiburg 2016 - Paul Lloyd on Designing Systems: Theory, Practice, and the Unfortunate In-Between on Vimeo

The video of Paul’s fantastic talk on design systems.

How to prototype in the browser | GDS design notes

This is a clever quick’n’dirty way of prototyping iterations on an existing site using dev tools and screenshots.

Chasing Tools - TimKadlec.com

I’ve been thinking a lot lately about how we evaluate technologies (it will be the subject of my next talk). Tim is thinking along the same lines. I like his list of four questions to ask when weighing up the pros and cons of any web tool:

1. Who benefits from the use of this tool and how?
2. Who suffers and how?
3. How does it fail?
4. Does the abstraction feed the core?

Fantasy UIs

Interviews with the designers who make on-screen interfaces for sci-fi films.

The Proposal | gablaxian.com

This is how Graham proposed to Linzi …and you can try it out for yourself.

(I must’ve got something in my eye when I got to the end of the level. Weird.)

My site has been behaving strangely recently. It was nothing that I could put my finger on—it just seemed to be acting oddly. When I checked to see if everything was okay, I was told that everything was fine, but still, I sensed something that was amiss.

I’ve just realised what it was. Last week on the 30th of September, I didn’t do or say anything special. That was the problem. I had forgotten my blog’s anniversary.

I’m so sorry, adactio.com! Honestly, I had been thinking about it for all of September but then on the day, one thing led to another, I was busy, and it just completely slipped my mind.

So this is a bit late, but anyway …happy fifteenth anniversary to this journal!

We’ve been through a lot together in those fifteen years, haven’t we, /journal? Oh, the places we’ve been and the things we’ve seen!

I remember where we were on our tenth anniversary: Bologna. Remember we were there for the first edition of the From The Front conference? Now, five years on, we’ve just been to the final edition of that same event—a bittersweet occasion.

Like I said five years ago:

It has been a very rewarding, often cathartic experience so far. I know that blogging has become somewhat passé in this age of Twitter and Facebook but I plan to keep on keeping on right here in my own little corner of the web.

I should plan something special for September 30th, 2021 …just to make sure I don’t forget.

Normalize (CSS) No More. | shaunrashid.com

This crystallises something I’ve been thinking about for a while. There’s a fundamental philosophical idea underpinning CSS reset or normalise boilerplate that feels at odds with the belief that it’s perfectly fine for websites to look different in different browsers and devices.

Magic randomisation with nth-child and Cicada Principle | Charlotte Jackson, Front-end developer

Here’s the really clever technique that Charlotte used on the speakers page for this year’s UX London site.

I remember that Jon was really impressed that she managed to implement his crazy design.

“Resilience” - View Source Conference Closing Keynote by Jeremy Keith - YouTube

Here’s the video of the talk I gave in Berlin recently. I had a lot to squeeze into a short time slot so I just went for it, and I got bit carried away …but people seemed to like that.