Archive: December, 2015

150

	5th	10th	15th	20th	25th	30th
12am
4am
8am
12pm
4pm
8pm

Wednesday, December 30th, 2015

Lesson learned—when ordering a drink of porter in the States, I need to pronounce my Ts as Ds: “pôrdər”.

Monday, December 28th, 2015

The App-ocalypse: Can Web standards make mobile apps obsolete? | Ars Technica

I really, really want to like this article—it’s chock full of confirmation bias for me. But it’s so badly-written …I mean like, just the worst.

Here’s an actual sentence:

So with a capable, HTML-based platform and a well-designed program that makes good use of CSS, one site could support phones, tablets, PCs, and just about anything else with one site.

So, yeah, I’m still linking to it, but instead of it being for the content, it’s because I want to lament the dreadful state of technology writing.

JavaScript: 2015 in Review

Use a framework if you must but never presume it’s viable over the long-term. Newer and better alternatives will appear before you’re half-way through your project. Never forget frameworks are an option — you don’t have to use one.

Touch Keyboard Type ‘Cheat Sheet’ - Labs - Baymard Institute

A useful primer on which combinations of attributes and values work best for which form fields: type, autocomplete, autocorrect, and autocapitalize.

Mobile browser vendors have faced a dilemma for quite a while. They’ve got this double-tap gesture that allows users to zoom in on part of a page (particularly handy on non-responsive sites). But that means that every time a user makes a single tap, the browser has to wait for just a moment to see if it’s followed by another tap. “Just a moment” in this case works out to be somewhere between 300 and 350 milliseconds. So every time a user is trying to click a link or press a button on a web page, there’s a slight but noticeable delay.

For a while, mobile browsers tried to “solve” the problem by removing the delay if the viewport size had been set to non-scalable using a meta viewport declaration of user-scalable="no". In other words, the browser was rewarding bad behaviour: sites that deliberately broke accessibility by removing the ability to zoom were the ones that felt snappier than their accessible counterparts.

Fortunately Android changed their default behaviour. They decided to remove the tap delay for any site that had a meta viewport declaration of width=device-width (which is pretty much every responsive website). That still left Apple.

I discussed this a couple of years ago with Tess (my go-to person on the inside of the infinite loop):

She’d prefer a per-element solution rather than a per-document meta element. An attribute? Or maybe a CSS declaration similar to pointer events?

I thought for a minute, and then I spitballed this idea: what if the 300 millisecond delay only applied to non-focusable elements?

After all, the tap delay is only noticeable when you’re trying to tap on a focusable element: links, buttons, form fields. Double tapping tends to happen on text content: divs, paragraphs, sections.

Well, the Webkit team have announced their solution. As well as following Android’s lead and removing the delay for responsive sites, they’ve also provided a way for authors to declare which elements should have the delay removed using the CSS property touch-action:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

So to get the behaviour I was hoping for—no delay on focusable elements—I can add this line to my CSS:

a, button, input, select, textarea, label, summary {
  touch-action: manipulation;
}

That ought to do it. I suppose I could also throw [tabindex]:not([tabindex="-1"]) into that list of selectors.

It probably goes without saying, but you shouldn’t do:

* { touch-action: manipulation; }

or:

body { touch-action: manipulation; }

That default behaviour of touch-action: auto is still what you want on most elements.

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Friday, December 25th, 2015

Thursday, December 24th, 2015

Ba-doom sith!

It snowed and snowed on Hoth, but Santa never came—what did that make Luke, Han, and Leia?

…

Rebels without a Clause!

Went to see The Force Awakens for the second time.

Enjoyed it even more.

Tuesday, December 22nd, 2015

Sunday, December 20th, 2015

Saturday, December 19th, 2015

Tom Waits Map | A map of places from Tom Waits songs

This geography lesson makes a nice companion piece to Johnny Cash has been everywhere, man.

getify/You-Dont-Know-JS

Graham—whose opinion I trust completely—has been raving about these books. And Kyle Simpson is a super-smart guy. So I reckon I should make these JavaScript tomes my holiday reading.

SpaceHolder – A space-themed image placeholder service.

We’ve got Space Ipsum for text. Now we have SpaceHolder for images.

Photo upload and progressive enhancement for FixMyStreet / mySociety

Matthew describes a very nice bit of progressive enhancement for drag’n’drop file uploads (similar to the CSS Tricks article I linked to recently).

It uses the Dropzone JS which looks like it aligns nicely with the progressive enhancement approach.

Friday, December 18th, 2015

Temporary Constellations — Buckley Williams

This is a really lovely project by Dan and Nat—Christmas cards featuring the fleeting invisible constellations formed by the mesh of GPS satellites within which our planet lies.

Building the UX London website by Charlotte Jackson

Charlotte talks through some of the techniques she used when she was building the site for this year’s UX London, with a particular emphasis on improving perceived performance.

Sirloin of beef with beef shin croquette.

Thursday, December 17th, 2015

Pseudo and pseudon’t

I like CSS pseudo-classes. They come in handy for adding little enhancements to interfaces based on interaction.

Take the form-related pseudo-classes, for example: :valid, :invalid, :required, :in-range, and many more.

Let’s say I want to adjust the appearance of an element based on whether it has been filled in correctly. I might have an input element like this:

<input type="email" required>

Then I can write some CSS to put green border on it once it meets the minimum requirements for validity:

input:valid {
  border: 1px solid green;
}

That works, but somewhat annoyingly, the appearance will change while the user is still typing in the field (as soon as the user types an @ symbol, the border goes green). That can be distracting, or downright annoying.

I only want to display the green border when the input is valid and the field is not focused. Luckily for me, those last two words (“not focused”) map nicely to some more pseudo-classes: not and focus:

input:not(:focus):valid {
  border: 1px solid green;
}

If I want to get really fancy, I could display an icon next to form fields that have been filled in. But to do that, I’d need more than a pseudo-class; I’d need a pseudo-element, like :after

input:not(:focus):valid::after {
  content: '✓';
}

…except that won’t work. It turns out that you can’t add generated content to replaced elements like form fields. I’d have to add a regular element into my markup, like this:

<input type="email" required>
<span></span>

So I could style it with:

input:not(:focus):valid + span::after {
  content: '✓';
}

But that feels icky.

Update: See this clever flexbox technique by Kitty Giraudel for a potential solution.

On agile…

Point: http://clearleft.com/thinks/351

Counterpoint: http://clearleft.com/thinks/352

I love this kind of open discussion.

Write What You Know (Now) · An A List Apart Column

Well, this is rather lovely!

I nodded along with host Jen Simmons and guest Jeremy Keith saying some very smart things about the web and its roots as the El train cut across Philadelphia. But at the 48-minute mark things got weird, because Jen and Jeremy basically started writing my column for me while I listened.

Read on for some great advice on conquering your inner critic.

Wednesday, December 16th, 2015

FIFTEEN MINUTES UNTIL THE FORCE AWAKENS!!!

I am positively aquiver with excitement and anticipation!

Setup a Service Worker by Calum Ryan

Calum has set up a Service Worker on his site. Here he muses on the potential for offline experiences.

Natural peer environment by Mikey Allan

‘Sfunny, I was just discussing this with Clare and Charlotte at work: how our office space (and culture) lends itself well to spontaneous exchanges of feedback and opinions.

More Responsive Tapping on iOS | WebKit

This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.

Better Google Web Fonts

A single page showing all the weights available from Google fonts at a glance.

CarbonGraffiti | When agile’s not creative

Jon writes about the difficulty of maintaining an overall design vision when you’re working to an agile methodology, slicing up work into sprints.

This pairs nicely with Mark’s recent podcast episode: On Agile.

Decorating the @Clearleft Christmas tree. 🎄

Interactive Storytelling | Codrops

I think this might be the most tasteful, least intrusive use of scroll events to enhance a Snowfallesque story. It’s executed superbly.

You can read all about the code. Interestingly, it’s using canvas to render the maps even though the maps themselves are being stored as SVG.

(There’s a caveat saying: “This is a highly experimental project and it might not work in all browsers. Currently there is no IE support.” I don’t think that’s true: the story works just in IE …that browser just doesn’t get the mapping enhancements.)

Tuesday, December 15th, 2015

Wondering if @StationCDRKelly greeted @astroTimPeake, @astroTim, and Yuri with bread and salt.

https://adactio.com/journal/9336

What Progressive Web Apps Mean for the Web - Telerik Developer Network

A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.

One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.

Shadows and smoke

When I wrote about a year of learning with Charlotte, I made an off-hand remark in parentheses:

Hiring Charlotte was an experiment for Clearleft—could we hire someone in a “junior” position, and then devote enough time and resources to bring them up to a “senior” level? (those quotes are air quotes—I find the practice of labelling people or positions “junior” or “senior” to be laughably reductionist; you might as well try to divide the entire web into “apps” and “sites”).

It breaks my heart to see so many of my colleagues prefix their job titles “senior” (not least because it becomes completely meaningless when every single Visual Designer is also a “Senior Visual Designer”).

I remember being at a conference after-party a few years ago chatting to a very talented front-end developer. She wasn’t happy with where she was working. I advised to get a job somewhere else After all, she lived and worked in San Francisco, where her talents are in high demand. But she was hesitant.

“They’ve promised me that in a few more months, my job title would become ‘Senior Developer’”, she said. “Ah, right,” I said, “and what happens then?” “Well”, she said, “I get to have the word ‘senior’ on my resumé.” That was it. No pay rise. No change in responsibilities. Just a word on a piece of paper.

I had always been suspicious of job titles, but that exchange put me over the edge. Job titles can be downright harmful.

Dan recently wrote about the importance of job titles. I love Dan, but I couldn’t disagree with him more in this instance.

He cite two situations where he believes job titles have value:

Your title tells your colleagues how to interact with you.

No. Talking to your colleagues tells your colleagues how to interact you. Job titles attempt to short-cut that. They do a terrible job of it.

What you need to know are the verbs that your colleagues are adept in: designing, developing, thinking, communicating, facilitating …all of that gets squashed down into one reductionist noun like “Copywriter” or “Designer”.

At Clearleft, we’ve recently started kicking off projects with an exercise called “Fuzzy Edges” that Boxman has been refining. In it, we look ahead to all the upcoming project roles (e.g. “Who will lead playbacks and demos?”, “Who will run stakeholder interviews?”, “Who will lead design direction?”). Together, everyone on the project comes to a consensus on who has which roles.

It’s really, really important to clarify these roles at the start of each project, and it’s exactly the kind of thing that can’t be summed up in a job title. In fact, the existence of job titles can lead to harmful assumptions like “Oh, I figured you were leading playbacks and demos!” or “Oh, I assumed they were running stakeholder interviews!”, or worse: “Hey, you can’t lead design direction because that’s not in your job title!”

The role assignments can vary hugely from project to project, which is great. People are varied and multi-faceted. Trying to force the same people into the same roles over and over again would be demoralising and counter-productive. I fear that’s exactly what job titles do—they reinforce barriers.

Here’s the second reason Dan gives for the value of job titles:

Your title tells your clients how to interact with you.

Again, no. Talking to your clients tells your clients how to interact with you.

Dan illustrates his point by recounting a tale of deception, demonstrating that a well-placed lie about someone’s job title can mollify the kind of people who place great stock in job titles. That’s not solving the real problem. Again, while job titles might appear to be shortcuts to a shared understanding, they’re actually more like façades covering up trapdoors.

In recounting the perceived value of job titles, there’s an assumption that the titles were arrived at fairly. If someone’s job title is “Senior Designer” and someone’s job title is “Junior Designer”, then the senior person must be the better, more experienced designer, right?

But that isn’t always the case. And that’s when job titles go from being silly pointless phrases to being downright damaging, causing real harm.

Over on Rands in Repose, there’s a great post called Titles are Toxic. His experience mirrors mine:

Never in my life have I ever stared at a fancy title and immediately understood the person’s value. It took time. I spent time with those people — we debated, we discussed, we disagreed — and only then did I decide: “This guy… he really knows his stuff. I have much to learn.” In Toxic Title Douchebag World, titles are designed to document the value of an individual sans proof. They are designed to create an unnecessary social hierarchy based on ego.

See? There’s no shortcut for talking to people. Job titles are an attempt to cut out one of the most important aspects of humans working together.

The unspoken agreement was that these titles were necessary to map to a dimwitted external reality where someone would look at a business card and apply an immediate judgement on ability based on title. It’s absurd when you think about it – the fact that I’d hand you a business card that read “VP” and you’d leap to the immediate assumption: “Since his title is VP, he must be important. I should be talking to him”. I understand this is how a lot of the world works, but it’s precisely this type of reasoning that makes titles toxic.

So it’s not even that I think that job titles are bad at what they’re trying to do …I think that what they’re trying to do is bad.

Come to Brighton’s Homebrew Website Club tomorrow in @68MiddleSt…

https://indiewebcamp.com/events/2015-12-16-homebrew-website-club

Maciej Ceglowski - The Website Obesity Crisis on Vimeo

A superb talk on performance, advertising, and the future of the web. No doubt a transcript will appear in due time on Maciej’s site and when it does, I will enjoy it all over again.

Trust me: you’ll want to watch this.

Monday, December 14th, 2015

My latest Twitter bot: @5point9billion (14 Dec., 2015, at Interconnected)

I always loved Matt’s light cone project—it was a big influence on the Radio Free Earth hack that I made with Chloe. Now it has been reborn as a Twitter bot. Here’s Matt’s documentation for his future self:

I haven’t made a habit of project write-ups before, but I’m taking an increasingly “long now” approach to the tech I make and use. How will I remember what I made in a decade? By reading this post.

The web accessibility basics – Marco’s Accessibility Blog

Marco gives a run-down of the basics of getting accessibility right on the web. Nothing here is particularly onerous but you’d surprised how often developers get this wrong (or simply aren’t aware of it).

He finishes with a plea to avoid unnecessary complexity:

If there’s one wish I have for Christmas from the web developer community at large, it is this: Be good citizens of the web, and learn proper HTML before you even so much as touch any JavaScript framework. Those frameworks are great and offer a lot of features, no doubt. But before you use hundreds of kilobytes of JavaScript to make something clickable, you may want to try if a simple button element doesn’t do the trick just as fine!

Sunday, December 13th, 2015

Simplified JavaScript Jargon

An A-Z of JavaScript jargon (although some of the “explanations” could do with de-jargonifying themselves).

Untangling the Tale of Ada Lovelace—Stephen Wolfram Blog

A detailed history of Babbage and Lovelace through the lens of Wolfram’s work today:

Ada seems to have understood with some clarity the traditional view of programming: that we engineer programs to do things we know how to do. But she also notes that in actually putting “the truths and the formulae of analysis” into a form amenable to the engine, “the nature of many subjects in that science are necessarily thrown into new lights, and more profoundly investigated.” In other words—as I often point out—actually programming something inevitably lets one do more exploration of it.

If this piques your interest, I highly recommend the Babbage biography The Cogwheel Brain by Doron Swade.

HIKE - Introduction to accessibility concepts for the Web

It really isn’t hard to get the basics of accessibility right on the web …and yet those basics are often neglected.

Here’s a handy shortlist to run through, HIKE:

H stands for headings and semantic markup.

I stands for images and labels.

K stands for keyboard navigation.

E asks for you to ACT with a little extra love for custom components and more.

(ACT = ARIA, Colour Contrast, Text Size)

Smaller, Faster Websites - - Bocoup

The transcript of a great talk by Wilto, focusing on responsive images, inlining critical CSS, and webfont loading.

When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web app. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”

We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job.

Peaceful Reflection

Paul takes a look back at a time in his life one decade ago. This is a great piece of personal writing.

Saturday, December 12th, 2015

Forget semantic versioning—I like @LyzaDanger’s Service Worker using deities from Greek mythology.

https://www.lyza.com/serviceworker.js

Friday, December 11th, 2015

IonicaBizau/gridly

Grid frameworks don’t get much more minimal than this—eleven lines of CSS:

.row { display: flex; }
.col { flex: 1; }
@media (max-width: 48em) {
    .row { flex-direction: column; }
    .col { flex: 0 0 100%; }
}
.col-tenth { flex: 0 0 10%; }
.col-fifth { flex: 0 0 20%; }
.col-quarter { flex: 0 0 25%; }
.col-third { flex: 0 0 33.3333334%; }
.col-half { flex: 0 0 50%; }

Should’ve been a gist really.

An Event’s Lifecycle: The Highs, The Lows, The Silence // beyond tellerrand

I can certainly relate to everything Marc describes here. You spend all your time devoted to putting on an event; it’s in the future, coming towards you; you’re excited and nervous …and then the event happens, it’s over before you know it, and the next day there’s nothing—this thing that was dominating your horizon is now behind you. Now what?

I think if you’ve ever put something out there into the world, this is going to resonate with you.

Where to start?

A lot of the talks at this year’s Chrome Dev Summit were about progressive web apps. This makes me happy. But I think the focus is perhaps a bit too much on the “app” part on not enough on “progressive”.

What I mean is that there’s an inevitable tendency to focus on technologies—Service Workers, HTTPS, manifest files—and not so much on the approach. That’s understandable. The technologies are concrete, demonstrable things, whereas approaches, mindsets, and processes are far more nebulous in comparison.

Still, I think that the most important facet of building a robust, resilient website is how you approach building it rather than what you build it with.

Many of the progressive app demos use server-side and client-side rendering, which is great …but that aspect tends to get glossed over:

Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering, but this is only one of many options.

I think it’s vital to not think in terms of older browsers “falling back” but to think in terms of newer browsers getting a turbo-boost. That may sound like a nit-picky semantic subtlety, but it’s actually a radical difference in mindset.

Many of the arguments I’ve heard against progressive enhancement—like Tom’s presentation at Responsive Field Day—talk about the burdensome overhead of having to bolt on functionality for older or less-capable browsers (even Jake has done this). But the whole point of progressive enhancement is that you start with the simplest possible functionality for the greatest number of users. If anything gets bolted on, it’s the more advanced functionality for the newer or more capable browsers.

So if your conception of progressive enhancement is that it’s an added extra, I think you really need to turn that thinking around. And that’s hard. It’s hard because you need to rewire some well-engrained pathways.

There is some precedence for this though. It was really, really hard to convince people to stop using tables for layout and starting using CSS instead. That was a tall order—completely change the way you approach building on the web. But eventually we got there.

When Ethan came out with Responsive Web Design, it was an equally difficult pill to swallow, not because of the technologies involved—media queries, percentages, etc.—but because of the change in thinking that was required. But eventually we got there.

These kinds of fundamental changes are inevitably painful …at first. After years of building websites using tables for layout, creating your first CSS-based layout was demoralisingly difficult. But the second time was a bit easier. And the third time, easier still. Until eventually it just became normal.

Likewise with responsive design. After years of building fixed-width websites, trying to build in a fluid, flexible way was frustratingly hard. But the second time wasn’t quite as hard. And the third time …well, eventually it just became normal.

So if you’re used to thinking of the all-singing, all-dancing version of your site as the starting point, it’s going to be really, really hard to instead start by building the most basic, accessible version first and then work up to the all-singing, all-dancing version …at first. But eventually it will just become normal.

For now, though, it’s going to take work.

The recent redesign of Google+ is true case study in building a performant, responsive, progressive site:

With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page. Once the page is loaded and the user clicks on a link, we do not want to perform a full round-trip to render everything again. This is where client-side rendering becomes important — we just need to fetch the data and the templates, and render the new page on the client. This involves lots of tradeoffs; so we used a framework that makes server-side and client-side rendering easy without the downside of having to implement everything twice — on the server and on the client.

This took work. Had they chosen to rely on client-side rendering alone, they could have built something quicker. But I think it was worth laying that solid foundation. And the next time they need to build something this way, it’s going to be less work. Eventually it just becomes normal.

But it all starts with thinking of the server-side rendering as the default. Server-side rendering is not a fallback; client-side rendering is an enhancement.

That’s exactly the kind of mindset that enables Jack Franklin to build robust, resilient websites:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. Server-side rendering was the default; client-side rendering was added later.

The key to building modern, resilient, progressive sites doesn’t lie in browser technologies or frameworks; it lies in how we think about the task at hand; how we approach building from the ground up rather than the top down. Changing the way we fundamentally think about building for the web is inevitably going to be challenging …at first. But it will also be immensely rewarding.

Web History Primer

Written in 2001, this history of the web takes in CERN, hypertext, the ARPANET, SGML, and lots more.

Starting to think that @AllMarkedUp used Killgrave-like mind-control powers to convince half of @Clearleft to get blotto last night.

Really, really enjoying @BrianKardell’s ongoing web history series—can’t wait for part three.

https://briankardell.wordpress.com/

Thursday, December 10th, 2015

Putting My Patterns through Their Paces ◆ 24 ways

Ethan demonstrates progressive enhancement at the pattern level using flexbox.

I’ve found that thinking about my design as existing in broad experience tiers – in layers – is one of the best ways of designing for the modern web.

UNCANNY VALLEY (2015) on Vimeo

A really nicely put together sci-fi short film.

Wednesday, December 9th, 2015

Eight lines that can still be parsed by any of today’s web browsers:

https://gist.github.com/adactio/a515822dcb02ac9a66a7

1990-12-03

A Brief(ish) History of the Web Universe – Part I: The Pre-Web | briankardell

This is a wonderful, wonderful look back at the state of hypertext in the run-up to the creation of the World Wide Web.

My jaw may have dropped when I saw the GML markup.

Now I’m going to read part two.

HTML Developers: Please Consider | HTML5 Doctor

The best ARIA role is the one you don’t need to use.

Kate’s Christmas cards (est.1998) | Flickr - Photo Sharing!

Kate has been hand-making Christmas cards for seventeen years.

2013’s Gizmo Stardust remains my favourite.

Autumn-Earth/serviceWorker.js

Here’s a really nice addition to my Service Worker script—opportunistically add non-critical CSS, JavaScript, and fonts to a cache as you go.

Progressive Enhancement—Ain’t Nobody Got Time for that | GlückPress

Two sides of a debate on progressive enhancement…

Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:

If your content website breaks down from JavaScript issue — it is broken.

Joe Hoyle disagrees:

Unlike Rarst, I don’t value progressive enhancement very highly and don’t agree it’s a fundamental principle of the web that should be universally employed. Quite frankly, I don’t care about not supporting JavaScript, and neither does virtually anyone else. It’s not that it doesn’t have any value, or utility - but in a world where we don’t have unlimited resources and time, one has to prioritise what we’ll support and not support.

Caspar acknowledges this:

I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).

But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:

Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.

CSS Font Rendering Controls Module Level 1

This is already starting to land in browsers, which makes me very happy—the ability to specify how you want fonts to load/swap without needing a clever bit of JavaScript.

Tuesday, December 8th, 2015

briangonzalez/fontprep

The missing font generator for Mac OS X.

Very handy for subsetting fonts for the web. It doesn’t (yet) export WOFF2 unfortunately.

The web will always be a moving target : Eclectic Dreams

Caution:

It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.

Reminder:

The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.

Do not panic:

On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.

Cutting the Mustard Revisited — sixtwothree.org

Jason revisits some cutting-the-mustard techniques, as started by the BBC and refined by Jake. This kind of feature-testing is indispensable for progressive enhancement.

Personally though, I’m still uncomfortable with the assumptions baked into equating particular features with particular browsers …maybe I’ve known PPK too long.

I much prefer to cut the mustard on a case-by-case basis by feature testing the actual APIs I’m about to use in a script. I realise that might be harder to scale, and it’s more verbose, but it’s the only way to be absolutely sure.

The “Blur Up” Technique for Loading Background Images | CSS-Tricks

Quite a few moving parts in this technique from Emil, but it’s very clever.

Monday, December 7th, 2015

Learn to Code HTML & CSS - Beginner & Advanced

This looks like a great resource for anyone setting out to learn how to make websites.

Gethtml - all the html elements

The A-Z of HTML, with an example for each and every element. Comprehensive and impressive.

Old Weather: Whaling

A subset of one of my favourite sites on the web:

Explore the Arctic of the past from the deck of a whaling ship.

Choose your vessel and get transcribing.

philipwalton/flexbugs

A list of known bugs (and workarounds) in flexbox implementations. This is going to be handy to refer back to.

Checking in with Geno and his crew 43 years downstream in our timeline: http://apollo17.org/

Well, our @GeekestLink quiz team—Batmandalorian vs. Supermandalorian—came third …but then again, the team was just myself and @wordridden.

Sunday, December 6th, 2015

Heading out to The Caroline Of Brunswick for the Star Wars special @GeekestLink.

Who wants to be on my team?

The Moral Character of Cryptographic Work by Phillip Rogaway (PDF)

It’s a PDF and it’s an academic paper, but this rousing call to arms is a remarkably clear and engrossing read.

With few exceptions, the atomic scientists who worked on disarmament were not the same individuals as those who built the bomb. Their colleagues—fellow physicists—did that. Cryptographers didn’t turn the Internet into an instrument of total surveillance, but our colleagues—fellow computer scientists and engineers—did that.

It concludes with a series of design principles for the cryptographic community:

Attend to problems’ social value. Do anti-surveillance research.
Be introspective about why you are working on the problems you are.
Apply practice-oriented provable security to anti-surveillance problems.
Think twice, and then again, about accepting military funding.
Regard ordinary people as those whose needs you ultimately aim to satisfy.
Be open to diverse models. Regard all models as suspect and dialectical.
Get a systems-level view. Attend to that which surrounds our field.
Learn some privacy tools. Use them. Improve them.
Stop with the cutesy pictures. Take adversaries seriously.
Design and build a broadly useful cryptographic commons.
Choose language well. Communication is integral to having an impact.

We need to erect a much expanded commons on the Internet. We need to realize popular services in a secure, distributed, and decentralized way, powered by free software and free/open hardware. We need to build systems beyond the reach of super-sized companies and spy agencies. Such services must be based on strong cryptography. Emphasizing that prerequisite, we need to expand our cryptographic commons.

Taking Let’s Encrypt for a Spin - TimKadlec.com

Tim outlines the process for getting up and running with HTTPS using Let’s Encrypt. Looks like it’s pretty straightforward, which is very, very good news.

I’m using the Salter Cane site as a test ground for this. I was able to get everything installed fairly easily. The tricky thing will be having some kind of renewal reminder—the certificates expire after three months.

Still, all the signs are good that HTTPS is about to get a lot less painful.

Saturday, December 5th, 2015

Cooking a mega-rib (@wordridden shown for scale).

oldweb.today

Such a vividly nostalgic project. Choose an obsolete browser. Enter a URL. Select which slice of the past you want to see.

Digital archives in action. Access drives preservation.

How David Hume Helped Me Solve My Midlife Crisis - The Atlantic

A fascinating detective story of the Enlightenment, told from a very personal perspective.

People make lovely things—code, stories, ideas—then they share them on their websites, saying “Here. You can have this.”

I love that.

Today I’m linking to—and thanking—@LeaVerou, @Genmon, @Jack_Franklin, @Heydonworks & more…

https://adactio.com/links/archive/2015/12/05

Bliss.js — Heavenly JavaScript!

A small little JavaScript helper from Lea.

The helper library for people who don’t like helper libraries.

Today’s restaurant reviews ( 4 Dec., 2015, at Interconnected)

A wonderful sci-fi vignette from Matt.

Flexbox Grid Finesse | HeydonWorks

Great tips from Heydon on building a real design system using flexbox. Perfect for those times when you can’t predict the amount of content that will be in layout …so, pretty much always.

There’s even a trick in here that kinda sorta gives us element queries.

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.

In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.

The next time a user clicks, rather than being sent to the server, the client-side app is in control.

If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Native or Not? The Untapped Power of Web Apps | Viget

Following on from that last link, here’s an in-depth run-down of what you can do in mobile browsers today. I think a lot of people internalised “what you can’t do on the web” a while back—it’s well worth periodically revisiting the feature landscape to revise that ever-shrinking list.

Perhaps the biggest advantage the web has over native apps is how quickly users are able to engage. All that’s between the user and your content is one click.

What Web Can Do Today

Visit this site using different browsers on different devices to get a feel for what you can do with web technologies.

Native will always be ahead, but the feature gap is closing impressively fast.

Progressive enhancement needs better advocacy • Zetafleet

A rousing call to arms for progressive enhancement. I agree with the sentiment, but I’m less comfortable making assumptions about the reasons why developers don’t use progressive enhancement:

However, what’s actually happening is that “universal access to content” is being subversively replaced with “universal access for a limited subset of users that I care about”.

Honestly, I think that plenty of developers just aren’t thinking about it—especially if they’re relying on a particular tool or framework to save them time and effort (which is not a crime). So that’s why I agree with the title of this piece: let’s talk about this more; let’s make sure developers understand what they’re doing when they make JavaScript a requirement for basic functionality.

I particularly like the point in here about content blockers like NoScript:

In fact, it’s probably more likely that a user will try browsing the Web today without scripting than at any other time since the 1990s.

Friday, December 4th, 2015

Thursday, December 3rd, 2015

I really, really enjoy our Thursday afternoon front-end pow-wows at @Clearleft.

image-set() in CSS seems to be working pretty well in all the browsers that support it …I wonder when they’ll drop the -webkit prefix?

I Dreamed of a Perfect Database | New Republic

A really nice piece by Paul Ford on the history of databases and the dream of the Semantic Web.

Sometimes I get a little wistful. The vision of a world of connected facts, one big, living library, remains beautiful, and unfulfilled.

One thing though: the scrolling on this page is sooooo janky that I had to switch off JavaScript just to read these words comfortably.

WTF is Solid?- Solid

The new style guide and pattern library for Buzzfeed.

It all looks pretty reasonable on the surface but if you poke around in the CSS, you’ll find 1157 uses of !important. Yikes!

The whole point of having an agreed-upon codebase in a pattern library is so that developers need never reach for nuclear options like !important, so I’m afraid, for me, this is a demonstration of what not to do (in terms of CSS—the output of the HTML in the styleguide looks perfectly fine).

Solid uses immutable, atomic CSS classes…

CSS is “mutable”. By design. I don’t think we should be working against that.

Wednesday, December 2nd, 2015

Performance Calendar » Reducing Single Point of Failure using Service Workers

This is a nifty use of Service Workers—using a cache to mitigate unresponsive Content Delivery Networks.

The stuff in here about Promise.race is particularly useful for “lie-fi” scenarios: instead of thinking about the network connection in a binary way (either it’s available or it isn’t), considering the scenario of a crappy network connection seems more realistic.

A year of learning

An anniversary occurred last week that I don’t want to let pass by unremarked. On November 24th of last year, I made this note:

Welcoming @LotteJackson on her first day at @Clearleft.

Charlotte’s start at Clearleft didn’t just mark a new chapter for her—it also marked a big change for me. I’ve spent the last year being Charlotte’s mentor. I had no idea what I was doing.

Lyza wrote a post about mentorship a while back that really resonated with me:

I had no idea what I was doing. But I was going to do it anyway.

Hiring Charlotte coincided with me going through one of those periods when I ask myself, “Just what is it that I do anyway?” (actually, that’s pretty much a permanent state of being but sometimes it weighs heavier than others).

Let me back up a bit and explain how Charlotte ended up at Clearleft in the first place.

Clearleft has always been a small agency, deliberately so. Over the course of ten years, we might hire one, maybe two people a year. Because of that small size, anyone joining the company had to be able to hit the ground running. To put it into jobspeak, we could only hire “senior” level people—we just didn’t have the resources to devote to training up anyone less experienced.

That worked pretty well for a while but as the numbers at Clearleft began to creep into the upper teens, it became clear that it wasn’t a sustainable hiring policy—most of the “senior” people are already quite happily employed. So we began to consider the possibility of taking on somebody in a “junior” role. But we knew we could only do that if it were somebody else’s role to train them. Like I said, this was ‘round about the time I was questioning exactly what my role was anyway, so I felt ready to give it a shot.

Hiring Charlotte was an experiment for Clearleft—could we hire someone in a “junior” position, and then devote enough time and resources to bring them up to a “senior” level? (those quotes are air quotes—I find the practice of labelling people or positions “junior” or “senior” to be laughably reductionist; you might as well try to divide the entire web into “apps” and “sites”).

Well, it might only be one data point, but this experiment was a resounding success. Charlotte is a fantastic front-end developer.

Now I wish I could take credit for that, but I can’t. I’ve done my best to support, encourage, and teach Charlotte but none of that would matter if it weren’t for Charlotte’s spirit: she’s eager to learn, eager to improve, and crucially, eager to understand.

Christian wrote something a while back that stuck in my mind. He talked about the Full Stack Overflow Developer:

Full Stack Overflow developers work almost entirely by copying and pasting code from Stack Overflow instead of understanding what they are doing. Instead of researching a topic, they go there first to ask a question hoping people will just give them the result.

When we were hiring for the junior developer role that Charlotte ended up filling, I knew exactly what I didn’t want and Christian described it perfectly.

Conversely, I wasn’t looking for someone with plenty of knowledge—after all, knowledge was one of the things that I could perhaps pass on (stop sniggering). As Philip Walton puts it:

The longer I work on the web, the more I realize that what separates the good people from the really good people isn’t what they know; it’s how they think. Obviously knowledge is important—critical in some cases—but in a field that changes so quickly, how you go about acquiring that knowledge is always going to be more important (at least in the long term) than what you know at any given time. And perhaps most important of all: how you use that knowledge to solve everyday problems.

What I was looking for was a willingness—nay, an eagerness—to learn. That’s what I got with Charlotte. She isn’t content to copy and paste a solution; she wants to know why something works.

So a lot of my work for the past year has been providing a framework for Charlotte to learn within. It’s been less of me teaching her, and more of me pointing her in the right direction to teach herself.

There has been some traditional instruction along the way: code reviews, pair programming, and all of that stuff, but often the best way for Charlotte to learn is for me to get out of the way. Still, I’m always on hand to try to answer any questions or point her in the direction of a solution. I think sometimes Charlotte might regret asking me things, like a simple question about the box model.

I’ve really enjoyed those moments of teaching. I haven’t always been good at it. Sometimes, especially at the beginning, I’d lose patience. When that happened, I’d basically be an asshole. Then I’d realise I was being an asshole, apologise, and try not to do it again. Over time, I think I got better. I hope that those bursts of assholery are gone for good.

Now that Charlotte has graduated into a fully-fledged front-end developer, it’s time for me to ask myself once again, “Just what is it that I do anyway?”

But at least now I have some more understanding about what I like to do. I like to share. I like to teach.

I can very much relate to Chen Hui Jing’s feelings:

I suppose for some developers, the job is a just a means to earn a paycheck. But I truly hope that most of us are in it because this is what we love to do. And that we can raise awareness amongst developers who are earlier in their journey than ourselves on the importance of best practices. Together, we can all contribute to building a better web.

I’m writing this to mark a rewarding year of teaching and learning. Now I need to figure out how to take the best parts of that journey and apply it to the ongoing front-end development work at Clearleft with Mark, Graham, and now, Charlotte.

I have no idea what I’m doing. But I’m going to do it anyway.

This is a rather lovely moment from 43 years ago: http://apollo17.org/?t=000:02:30

Like kids on a rollercoaster.

Apollo 17 in Real-time

This is rather nice—a Spacelog-like timeline of Apollo 17, timeshifted by exactly 43 years.

Gene and the crew are on their way to the moon …the last humans to ever make the journey.

openHTML

This seems like a decent endeavour:

A collaborative research project aimed at designing better tools and practices for learning web development.

It’s Homebrew Website Club in @68MiddleSt this evening after work—be there and be square.

The System of the World Wide Web

A fascinating ten-year old essay looking at the early days of the web and how it conquered FTP and Gopher.

And though glitz, politics, hard work, and competitors’ mistakes all played a role in the success of the web, there are also aspects of the architecture that ensured the web would catch on. I think the web won because of the URI.

URIs are everywhere, and what’s vaguely funny now is the idea that they’re something special. But they’re very special: URI management is the fundamental consideration behind the design of web sites, web applications, and web services. Tim Berners-Lee originally intended URIs to be invisible, but they’re too useful for that.

Creating a Web Type Lockup | CSS-Tricks

A really great idea from Chris: using SVG to create the web equivalent of type lockups that can scale with all the control you want, while still maintaining accessibility.

Speaking of accessibility, Emil’s comment is very useful indeed.

Strange Horizons Fiction: Let Us Now Praise Awesome Dinosaurs, by Leonard Richardson

A riotously great short story…

“It always comes down to that, doesn’t it?” said the voice in disgust, now circling around Tark. “Whether a successful Internet filmmaker can also be insane. Given that his quote-unquote insanity is also the fuel for his objectively measurable success as an entrepreneur. And whether it makes sense to judge him by the standards of talking dinosaurs from Mars.”

Flexbox’s Best-Kept Secret

I’m filing this one away for future reference: combining flexbox with margin:auto is a magical combination.

Using auto margins with Flexbox is an effective way to get all of the flexibility of css floats, without the nastiness of breaking elements out of the document’s normal flow.

Remember this, future self!

Tuesday, December 1st, 2015

A Little Less Metacrap - Broken Links

Peter writes a follow-up to my post on metadata markup pointing out that Twitter will fall back to Open Graph values.

Flexbox Froggy - A game for learning CSS flexbox

This is superb!

Flexbox can be tricky to get your head around, but this exercise does a great job of walking you through each step in a fun way. I highly recommend trying all 24 levels.

Looking forward to Homebrew Website Club, 6pm-7:30pm tomorrow in @68MiddleSt—happy to chat about Service Workers, AMP, POSSEing to Medium.

Why Implementing Swipe Gestures Causes A Mobile Accessibility Issue

Jennison Asuncion outlines the problem with relying on a swipe gesture for interactions.

I would say that this could be expanded to just about any interaction: it’s always dangerous to rely on one specific gesture. It’s always better to either provide multiple ways of accomplishing a task, or to simply take a declarative approach, get out of the way, and let the user agent handle it.

Drag and Drop File Uploading | CSS-Tricks

This is a terrific example of progressive enhancement in action: going from a simple file input to a lovely interactive drag’n’drop interface.

The code uses jQuery but it could be easily adapted to vanilla JavaScript, and anyway, it’s not so much the code that matters, it’s the approach.

Translating Gender: Ancillary Justice in Five Languages Alex Dally MacFarlane | Interfictions Online

A fascinating look into the challenges encountered translating Anne Leckie’s excellent Radchaai novels into Bulgarian, German, Hebrew, Japanese, and Hungarian.

What is clear in all of these responses is that by examining the notions of ‘neutral’ and ‘feminine’ in grammar and gender through the lens of translation, we reveal their complexity – and some of their possible futures in languages, in both literature and speech.

Learn Sketch 3 - Design+Code

A very handy introduction to Sketch from an iOS-specific book. See also the subsequent chapter, Mastering Sketch 3.

🎶 We Are Models and We’re Loooooking Good 🎶

The proto-internet | Intelligent Life magazine

Mapping the submarine cables of the Victorian internet.

And by the way, why did nobody tell me about Cartophilia before now? I’m very disappointed in you.