A great presentation from Stephen. He takes a thoughtful look at our processes and tools.
Huge have released their tool for generating front-end style guides.
It’s really good to see that Vox are taking measures to fix their atrocious performance problems. The Verge in particular is a case study in how not to serve up text and images on the web. There have been times in the past when I’ve wanted to link to an article there but then thought “I can’t in good conscience put a fellow human through that.”
A tool for getting instant visual feedback on your nth-child selectors. Considering that the way I figure out nth-child selectors is to try randomly changing numbers until it works, this should be quite useful for me.
From the people who brought you youmightnotneedjquery.com comes youmightnotneedjqueryplugins.com.
Don’t get me wrong—jQuery is great (some of the plugins less so) but the decision about whether to use it or not on any particular project should be an informed decision made on a case-by-case basis …not just because that’s the way things have always been done.
These sites help to inform that decision.
A really nicely-documented pattern library.
Here’s the video of the panel I participated in at Edge conference, expertly moderated by Lyza.
Thanks to the video editing, you can’t see the face I’m making when the guy from Facebook talks about user-agent sniffing as a totally cool and reliable way of working.
The full text of Jason’s great talk at this year’s CSS Summit. It’s a great read, clearing up many of the misunderstandings around progressive enhancement and showing some practical examples of progressive enhancement working at each level of the web’s technology stack
Smart thinking from Harry here on a common issue when it comes to naming and styling. As he points out, the solution is not technical, but lies in how you form your mental model:
The design issue here is solved by subtly inverting the problem.
A handy little bookmarklet for doing some quick accessibility checks.
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
Stuart writes up his thoughts on progressive enhancement following the great discussions at Edge Conf:
So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to stop it.
This is a deep, deep dive into responsive images and I can only follow about half of it, but there are some really useful suggestions in here (I particularly like the ideas for swapping out images for print).
An in-depth look at where web components stand today, together with some very good questions about where they might be heading tomorrow.
Handy tips for creating, optimising, and using SVG on the web, be it in CSS or HTML.
The full text of Aaron’s magnificent closing keynote from Responsive Day Out.
A fantastically-detailed write up of the whole day out. Each talk is described, and then the threads are tied together at the end. Great stuff!
As may have become clear from my notes above, Responsive Day Out 3 was a day full of variety. I had the feeling it could have easily been called Web Day Out, and I guess that makes sense, as responsive web design has naturally grown to be a pleonasm in the past few years.
More of this kind of thing, please!
I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).
It’s a shame that the add-to-homescreen part isn’t standardised yet though.
An up-to-date round-up of the various techniques available when you want to provide a fallback for SVG.
A comparison of when to use percentages and when to use vw/vh in your CSS.
A deceptively simple but powerful use of flexbox.
Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
Apart from the best practices that can often be automated, there are many human decisions that have impact on page speed. A way to make page speed part of the conversation and optimising it part of a website’s requirement, is to set a performance budget.
This is a great blow-by-blow account of making an agency website perform better.
I love the side-by-side comparisons with other agencies, including Clearleft—the gauntlet has been thrown down!
I had a lot of fun chatting with Brad and Anna for the final episode of their small batch podcast on style guides and pattern libraries.
More thoughts on the lack of a performance culture, prompted by the existence of Facebook Instant:
In my experience, the biggest barrier to a high-performance web is this: the means of production are far removed from the means of delivery. It’s hard to feel the performance impact of your decisions when you’re sitting on a T3 line in front of a 30 inch monitor. And even if you test on real devices (as you should), you’re probably doing it on a fast wifi network, not a spotty 3G connection. For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast.
Zeldman looks back at Stewart Butterfield’s brilliant 5K contest. We need more of that kind of thinking today:
As one group of web makers embraces performance budgets and the eternal principles of progressive enhancement, while another (the majority) worships at the altar of bigger, fatter, slower, the 5K contest reminds us that a byte saved is a follower earned.
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).
Here’s a really nifty use of the
:checked behaviour pattern that Charlotte has been writing about—an interface for choosing a note from a piano keyboard. Under the hood, it’s a series of radio buttons and labels.
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
And that’s why you always use progressive enhancement!
Brad points out the importance of supporting—which is not the same as optimising for—the non-shiny devices out there.
I really like using the Kindle’s browser as a good baseline for checking that information is available and readable.
I like this nice straightforward approach. Instead of jumping into the complexities of the final interactive component, Chris starts with the basics and layers on the complexity one step at a time, thereby creating a more robust solution.
If I had one small change to suggest, maybe
aria-label might work better than offscreen text for the controls …as documented by Heydon.
On the fifteenth anniversary of A Dao Of Web Design people who make websites share their thoughts.
Paul Ford’s is a zinger:
I don’t know if the issues raised in “A Dao of Web Design” can ever be resolved, which is why the article seems so prescient. After all, the Tao Te Ching is 2500 years old and we’re still working out what it all means. What I do believe is that the web will remain the fastest path to experimenting with culture for people of any stripe. It will still be here, alive and kicking and deployed across billions of computing machines, in 2030, and people will still be using it to do weird, wholly unexpected things.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Here’s a talk give at a community event in London last summer.
Charlotte has experimenting with a nice discrete bit of flexbox on her personal site. Here she documents what she did, and what the fallback is.
Aaron documents his process of implementing Heydon’s clever quantity queries in CSS.
I am really looking forward to hearing Heydon’s talk at Responsive Day Out.
Results of a survey of over 1000 people working on the web. It’s beautifully put together and the overall trajectory regarding responsive design looks pretty positive to me.
Hot on the heels of Github’s pattern library, here’s Heroku’s.
Inspired by Responsive Day Out, the gang at Cloud Four are organising a one-day event on responsive design in Portland on September 25th. It’s gonna be a good one.
Github’s pattern library.
As always, it’s great to see how other organisations are tackling modular reusable front-end code (though I can’t imagine why anyone other than Github would ever want to use it in production).
The responsive BBC News site is live! Hurrah!
Here’s a look at the highs and lows of the site’s story, emphasising the importance of progressive enhancement and all that enables: feature detection (by “cutting the mustard”), conditional loading, and a mobile-first approach.
Practical examples showing where you can use flexbox right now, along with some strategies on how to start doing it.
A terrific little tool from Tim that puts performance into perspective by measuring how much money users are spending just to view your website on a mobile device.
The slides from Katie’s recent talk.
Performance is a rising requirement for building successful websites, but successful performance begins far earlier than development. So how do you get your entire team excited by it, specifically aesthetic-heavy designers?
Because in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.
A terrific bit of smart CSS thinking from Heydon Pickering.
You know he’s speaking at Responsive Day Out, right?
A quick drag’n’drop way to base 64 encode your web fonts so you can stick ‘em in local storage.
This time it’s a great article by Karen Menezes filled with practical examples showing where you can use flexbox today.
A really handy interactive intro to flexbox. Playing around with the properties and immediately seeing the result is a real help.
It will come as no surprise that I agree with every single word that Tim has written here.
Lea wasn’t happy with the lack of styling and extensibility of the datalist element, so she rolled her own lightweight autocomplete/type-ahead widget, and she’s sharing it with the world.
When I look around, I see our community spending a lot of time coming up with new tools and techniques to make our jobs easier. To ship faster. And it’s not that I’m against efficiency, but I think we need to consider the implications of our decisions. And if one of those implications is making our users suffer—or potentially suffer—in order to make our lives easier, I think we need to consider their needs above our own.
A great description of progressive enhancement.
Progressive enhancement in its basic form means not making assumptions
Smart thinking from Sara on providing a PNG fallback to browsers that don’t support SVG. Although, actually what I like about this solution is that it’s less about providing PNG as a fallback, and more about treating PNG as the baseline and SVG as the enhancement (an approach that the picture element is perfect for).
We were discussing the CSS3 grid layout module in the Clearleft office today, so naturally Rachel’s name came up. This is such a great resource for diving into this stuff.
A nice little pattern for generating a swish timeline in SVG from a plain ol’ definition list in HTML.
You know what? Just go and read everything that Jason writes, okay?
Ruddy good stuff.
The engineering benefits of building websites with a layered approach.
Why, yes, I am talking about progressive enhancement yet again! Why do you ask?
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
Simon St. Laurent on uncertainty as a feature, not a bug.
I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.
I really enjoyed chatting with the guys on the The Dirt podcast about progressive enhancement, but my goodness; it certainly sounds like I need to switch to decaf! Yappity-yapity-yap!
This is a talk I gave at An Event Apart about eighteen months ago, all about irish music, the web, long-term thinking, and yes, you guessed it—progressive enhancement.
Rushing doesn’t improve things, it might even slow you down. Focusing on a few things and doing them well is worthwhile. Sharing what you learn—even while you’re still figuring things out—is even better.
We hired Charlotte, our first junior developer at Clearleft recently, and my job has taken on more of a teaching role. I’m really enjoying it, but I have no idea what I’m doing, and I worry that I’m doing all the wrong things.
This article looks like it has some good, sensible advice …although I should probably check to see if Charlotte agrees.
Rob Larsen was published a book with O’Reilly called “The Uncertain Web: Web Development in a Changing Landscape”. I like it:
A refreshingly honest look at the chaotic, wonderful world of web development, with handy, practical advice for making future-friendly, backward-compatible websites.
I don’t agree with the conclusion of this post:
But I think the author definitely taps into a real issue:
The real problem is the perception that any code running in the browser is front-end code.
This is something we’re running into at Clearleft: we’ve never done backend programming (by choice), but it gets confusing if a client wants us to create something in Angular or Ember, “because that’s front end code, right?”
The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.
Designing primarily in a laptop web browser and testing with a mouse rather than fingers may come to look very out of date soon.
I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.
Smart thinking here on the eternal dilemma with loading web fonts. Filament Group have thought about how the initial experience of the first page load could be quite different to subsequent page loads.
You can now read Aaron’s excellent book online. I highly recommend reading the first chapter for one of the best descriptions of progressive enhancement that I’ve ever read.
Good advice from Chris, particularly if you’re the one who has to live with the CSS you write.
As Obi-Wan Kenobi once said, “You must do what you feel is right, of course.”
Kenneth has isolated Chrome’s dev tools into its own app. This is a big step towards this goal:
Why are DevTools still bundled with the browsers? What if clicking “inspect element” simply started an external DevTools app?
With DevTools separated from one specific browser, a natural next step would be making the DevTools app work with other browsers.
Watch this space.
My contribution to this year’s edition of the web’s best advent calendar.
A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.
I completely share Bruce’s concern about the year-zero thinking that’s accompanying a lot of the web components marketing:
Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.
I’m a fan of web components. But I’m increasingly worried about the messaging surrounding them.
Some good practical advice from Tim on setting a performance budget.
Use rule-based metrics to make sure you haven’t overlooked simple optimizations.
Use quantity-based metrics as guides to help designers and developers make better decisions about what goes onto a page.
This isn’t a scientific data sample, but Jonathan’s anecdotal evidence seems to suggest that most web designers and developers are still thinking with a desktop-first mentality. Which is crazy.
A very handy collection from Anna: articles, books, talks, podcasts, and examples of front-end style guides. If something’s missing, feel free to add it.
Focus on what you want to learn; not what you think you should learn.
There is a lot of pressure out there: to learn new things, to spend all your time coding, to be the super developer. I now believe that to be impossible and unhealthy. It means you aren’t living a balanced life and it also means that you’re living under constant stress and pressure.