Y’know, all too often we’re caught up in the latest techniques and technologies. It’s easy to forget that there are people out there trying to learn this whole web thing from scratch. That’s why I think blog posts like this are so, so important!
Based on her experience teaching CSS at Codebar, Charlotte describes how she explains margins. Sounds simple, right? But is that because we’ve internalised this kind of thing? When was the last time we really thought about the basic building blocks of making websites?
Anyway, this is by far the best explanation of margin shorthand properties that I’ve seen.
More of this kind of thing, please!
A note of optimism for digital preservation:
Where a lack of action may have been more of the case in the 01990s, it is certainly less so today. In the early days, there were just a handful of pioneers talking about and working on digital preservation, but today there are hundreds of tremendously intelligent and skilled people focused on preserving access to the yottabytes of digital cultural heritage and science data we have and will create.
An examination of how sites like The Session are meshing with older ideas of traditional Irish music:
There is a very interesting tension at play here – one that speaks directly to the design of new technologies. On the one hand, Irish musicians appear to be enthusiastically adopting digital media to establish a common repertoire of tunes, while on the other the actual performance of these tunes in a live session is governed by a strong etiquette that emphasizes the importance of playing by ear.
There’s an accompanying paper called Supporting Traditional Music-Making: Designing for Situated Discretion (PDF).
We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.
This is a really good primer on all the pieces that make up the Houdini approach to CSS—giving authors access to low-level APIs for rendering.
As is often repeated here, it’s still early days and caution is advised, but it’s still a good idea to wrap your head around what’s coming down the standards pipe.
There’s even more specs in Houdini’s list of drafts, but the future of those is rather uncertain and they are not much more than a placeholder for an idea at this point. Examples include custom overflow behaviors, CSS syntax extension API, extension of native scroll behavior and similar ambitious things that allow you to screw up your web app even worse than ever before. Rejoice!
Bootstrap is a product of Twitter. If you want your team to work like Twitter’s team, then by all means use Bootstrap. Pick up their design language. Their tool chain. Their decisions. Don’t be surprised when it feels off every time you use it. It will.
The same goes for Material Design. Foundation. These are all products built by other teams to work for their process. Their structure.
Finding the right tool is not what I am advocating for. Making it is.
Microsoft are officially on board with implementing Service Workers in Edge:
Roadmap Priority: High — We intend to begin development soon.
Three very easy to implement additions to scrollable areas of your web pages:
role="region", and an
Ooh, I really like this idea! Pointing to your Service Worker the same way you point to your style sheet makes a lot of sense to me.
I love this little markup pattern: simple, accessible and elegant …with some quirky CSS gotchas around styling non-standard prefixed pseudo-elements. They came from the Shadow DOM …dun dun DUN!
Use the right element for the job.
- Does the Control Take Me to Another Page? Use an Anchor.
- Does the Control Change Something on the Current Page? Use a Button.
- Does the Control Submit Form Fields? Use a Submit.
A great description of a solid architectural approach to building on the web (and not just for accessibility either).
The slides from Calum’s presentation at Front-end London.
A complete list of HTML elements, past and present. They’re all hyperlinked to the relevant specs.
Earth as seen on one day in 2015 from Himawari-8. Beautiful.
Some of the explanations get a little ranty, but Heydon’s collection of observed fallacies rings true:
- The gospel fallacy
- The Luddite fallacy
- The scale fallacy
- The chocolate fireguard fallacy
- The pull request fallacy
- The ‘made at Facebook’ fallacy
- The Bob the Builder fallacy
- The real world fallacy
- The Daphne and Celeste fallacy
I’ve definitely had the Luddite fallacy and the scale fallacy thrown in my face as QEDs.
The ‘made at Facebook’ fallacy is pretty much identical to what I’ve been calling the fallacy of assumed competency: copying something that large corporation X is doing just because large corporation X is doing it.
A nicely documented pattern library.
I invite you not just to follow along here as I expand into topics beyond design and technology, but to start your own personal blog up again if you’ve been neglecting it for a while. I’m really interested in the things you are passionate about. I want to learn from you.
A fascinating slice of ethnographic research in Myanmar by Craig. There’s no mention of the web, which is certainly alarming, but then again, that’s not the focus of the research.
Interestingly, while Facebook is all omnipresent and dominant, nobody is using it the way that Facebook wants: all the accounts are basically “fake”.
What I found fascinating are the ways that people have found to bypass app stores. They’re basically being treated as damage and routed ‘round. So while native apps are universal, app stores would appear to be a first world problem.
Now if there were only some kind of universally accessible distribution channel that didn’t require any kind of installation step …hmmm.
A response to a rant I linked to recently.
I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.
The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.
Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.
Codebar had a very good 2015.
Of the 137 workshops run, “100 of those workshops were organised by our two busiest chapters, London and Brighton”—50 each.
I love this. I really love this. Remy absolutely nails what makes the web so great.
There’s the ubiquity:
If the viewer is using the latest technology beefy desktop computer that’s great. Equally they could view the website from a work computer, something old and locked in using a browser called IE8.
Then there’s the low barrier to entry—yes, even today:
It’s the web’s simplicity. Born out of a need to connect documents. As much as that might have changed with the latest generation of developers who might tell you that it’s hard and complex (and they’re right), at the same time it is not complicated. It’s still beautifully simple.
Anyone can do it. Anyone can publish content to the web, be it as plain text, or simple HTML formed only of <p> tags or something more elaborate and refined. The web is unabashed of it’s content. Everything and anything goes.
I might just print this out and nail it to the wall.
If you sit back for a moment, and think about just how many lives you can touch simply by publishing something, anything, to the web, it’s utterly mind blowing.
This a magnificent piece of writing from James …all about pieces of metal fabric.
A single technology – the vacuum-deposition of metal vapour onto a thin film substrate – makes its consecutive and multiple appearances at times of stress and trial: at the dawn of the space age, in orbit and on other planets, at the scene of athletic feats of endurance, in defence and offence in the mountains of the Hindu Kush, on the beaches of the European archipelago. These are moments of hope as well as failure; moments when, properly utilised, technological progress enables us to achieve something which was beyond our capabilities before. And yet: we are still pulling bodies from the water wrapped in material which was meant to send us into space.
A linkbaity title for a ranty post. But it’s justified.
My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.
I think I’ve shown great restraint in not linking to loads of think-pieces about Star Wars and The Force Awakens, because believe me, I’ve been reading—and listening to—a lot.
What Jessica has written here is about The Force Awakens. But more than that, it’s about Star Wars. But more than that, it’s about childhood. But more than that…
What I’m saying is: if you only read one thing about the new Star Wars film, read this.
A lightweight alternative to Modernizr. It doesn’t add classes to your markup so it’s up to what you do with the results of any test.
It’s perfect for cutting the mustard on a case-by-case basis.
It’s okay to feel stress in response to this rapid development. It’s natural. I hate change, I hate it so so much. I like things to be consistent and for it to have it’s own place. If it doesn’t, I get stressed and my obsessive compulsive tendencies run riot in a desperate attempt to preserve order. This both benefits and hinders my work.
Chimes very nicely with the latest episode of Ctrl+Click Cast.
Adam Onishi on teaching and learning:
As web developers, with the constant change in our industry, learning becomes a necessary part of our jobs. However with the right environment I think we can make that learning experience easier and actually a fun part of what we do.
The proxy browser Opera Mini is one of the most popular mobile browsers in the world, and rightly so. Ire Aderinokun has put together a handy collection—based on caniuse.com data—of all the features that are unavailable or only partially available in that browser. The point here is not to avoid using these features, but to make sure you’ve got a solid fallback in place:
This isn’t about bashing the problem, but figuring out the solution.
Well, this is timely! Just today I was having a really good natter with Charlotte about using checkboxes, specifically sending multiple values to the server:
You’ll notice that the
namegiven to each of these checkbox
inputelements is the same: “reservation-requested-device”. The square brackets (“”) at the end of the
nameare the magic bit that allows the values of each chosen “reservation-requested-device” checkbox to be submitted as the value of “reservation-requested-device”.
See, I wasn’t sure whether that was just a PHP thing (the only server-side input-handling I’ve had much experience of) or whether it was a more general way of sending multiple values.
Update: It seems that the square brackets are indeed a PHP thing. Multiple values will be sent in any case. See this test case.
Jake describes the pivotal moment of his web awakening:
I explored the world wide web. I was amazed by the freedom of information, how anyone could publish, anyone could read. Then I found a little button labeled “View source”. That was the moment I fell in love with the web.
It all goes back to having a ZX Spectrum apparently. Pah! Luxury! I had a ZX81—one K of RAM …1K! Tell that to the young people today, and they wouldn’t believe you.
Anyway, this is a lovely little reminiscence by Jake, although I have no idea why he hasn’t published it on his own site.
I got a little verklempt reading this.
Brad follows up with his thoughts on Dan’s article, emphasising the importance of a developer’s role in not just slavishly recreating what’s in a static comp, but seeing through to the underlying pattern beneath:
It’s so incredibly crucial to treat development as a key part of the design process.
A really terrific article from Dan on building pattern libraries. In summary:
- Naming things is hard,
- Separation of content and presentation is A Good Thing.
There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:
When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.
(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)
A terrific analysis of industrial design in film and games …featuring a scene-setting opening that delineates the difference between pleasure and happiness.
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.
A useful primer on which combinations of attributes and values work best for which form fields:
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.
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.
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.
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.
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:
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)
Paul takes a look back at a time in his life one decade ago. This is a great piece of personal writing.
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.
Written in 2001, this history of the web takes in CERN, hypertext, the ARPANET, SGML, and lots more.
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.
The best ARIA role is the one you don’t need to use.
Kate has been hand-making Christmas cards for seventeen years.
2013’s Gizmo Stardust remains my favourite.
The missing font generator for Mac OS X.
Very handy for subsetting fonts for the web. It doesn’t (yet) export WOFF2 unfortunately.
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.
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.
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.
This looks like a great resource for anyone setting out to learn how to make websites.
The A-Z of HTML, with an example for each and every element. Comprehensive and impressive.
A list of known bugs (and workarounds) in flexbox implementations. This is going to be handy to refer back to.
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.
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 next time a user clicks, rather than being sent to the server, the client-side app is in control.
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:
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.
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.
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
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.
This seems like a decent endeavour:
A collaborative research project aimed at designing better tools and practices for learning web development.
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.
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!
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.
A new presentation from the wonderfully curmudgeonly Steven Pemberton, the Nosferatu of the web. Ignore the clickbaity title.
This part really, really resonated with me:
The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
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.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
Here’s Paul’s write-up of his excellent talk at FF Conf.
Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).
As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.
This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.
Rachel outlines the history of the CSS Grid Layout spec so far:
The process works, as slow as it may seem to us who wait anxiously to be able to take advantage of these techniques. I am happy that we are waiting for something that I really believe has the ability to completely change how we do layout on the web.
A lovely little script from Nat to create a nice montage of images. It works by progressively enhancing a regular series of images in the markup.
A tool for generating a pattern library from Markdown comments in CSS. This isn’t the way that I tend to work, but I can see how it would be quite handy.
The comprehensive style guide and pattern library for North Carolina.
Ben and Erin are shipping experimental support for AMP in the latest version of Known, but Ben has some concerns about the balance of power tilting towards one major player, in this case Google:
But it’s Google’s whitelist of approved ad providers that’s most concerning:
We’ve shipped support for AMP because we see potential here, and recognize that something should be done to improve the experience of loading independently-published content on the web. But attempting to bake certain businesses into a web standard is a malformed idea that is doomed to fail. If this is not corrected in future versions of the specification, we will withdraw support.
Had anyone from the archive been in touch with ESPN? Was there any hope that the treasured collection of Grantland stories might remain accessible?
“We don’t ‘get in touch,’” Jason Scott, a digital historian at the Internet Archive, told me in an email. “We act.”
We have made a radio reconnaissance of the star KIC 8462852 whose unusual light curves might possibly be due to planet-scale technology of an extraterrestrial civilization.
Nothing to report yet.
This is such an incredibly useful resource by Steve and Léonie: documenting how multiple screen readers handle each and every element in HTML.
It’s a work in progress, but it’s definitely one to remember the next time you’re thinking “I wonder how screen readers treat this markup…”
I’m so proud of Charlotte right now: last week she gave a conference talk and today she has an article published in A List Apart. Superb work on both fronts!
She does a great job of talking through a collaborative exercise to help teams move from thinking in pages to thinking in patterns.
In a strikingly accurate replica of the original IMP log (crafted by UCLA’s Fowler Museum of Cultural History) on one of the room’s period desks is a note taken at 10:30 p.m., 29 October, 1969—“talked to SRI, host to host.” In the note, there is no sense of wonder at this event—which marks the first message sent across the ARPANET, and the primary reason the room is now deemed hallowed ground.
Be willing to look like a dork:
Embarrassment about what others think has to be the biggest block to any learning. Embarrassment of looking silly. Embarrassment of looking stupid for asking the question everyone else is wondering about but no one is willing to make.
Chimes nicely with Charlotte’s recent piece, Be comfortable looking like an idiot.
Pssst! Wanna read something scary for Halloween? Well, this should make you shit your pants.
Seriously though, if the event described here turn out to be true, it is one of the most frightening moments in the history of our species.
The sad history of
I wish I could share in the closing optimism:
Now imagine the future where Web Components are supported natively, and someone else is allowed to write a <better-input>, an element that is a real, encapsulated DOM element, and not just a div soup. Imagine using this <better-input> that isn’t implemented differently in each browser, that looks the same everywhere, and that probably also knows how to bake you a cherry pie.
But I all I can think is:
Now imagine the future where Web Components are supported natively, and everyone is allowed to write a million variations of <my-idea-of-a-better-input>, an element that is an inaccessible div soup under the hood.
I really like the way that you can literally flip between the source code and the output in this styleguide for The Toast.
There are Inception-like layers of nostalgia here: firstly, this web series of web pages made by Matt are a throwback to an earlier era, and secondly, the story being told goes all the way back to the birth of the ARPAnet.