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.
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.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
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.
Hot on the heels of Github’s pattern library, here’s Heroku’s.
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?
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.
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!
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.
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.
A handy starting point for creating a front-end styleguide: a single document of HTML elements.
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.
A great primer on using
picture. I think I’ll be referring back to this a lot.
Yesterday, Aaron gave a great talk at BD Conf about forms. In one example, he was using
aria-describedby. I was a bit confused by the differences between
aria-labelledby, so Aaron has very helpfully clarified the distinction.
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
Four different techniques for vertical centring in CSS, courtesy of Jake.
A great technique from Heydon for styling radio buttons however you want.
My name is Jeremy and I am a boring front-end developer.
Some thoughts on progressive enhancement, although I disagree with the characterisation of progressive enhancement as being the opposite choice to making “something flashy that pushes the web to it’s limits”—it’s entirely possible to make the flashiest, limit-pushing sites using progressive enhancement. After all…
it’s much more a mindset than a particular development technique.
Turns out that Brian LeRoux and I gave the same answer to this question:
I think I just saved you a click.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
Soledad Penadés also went to the Extensible Web Summit in Berlin, where she gave a lightning talk. Sounds like it was really good.
This also includes some good advice that, again, Alex might want to consider before denouncing any disagreement on Web Components as “piffle and tosh”:
If the W3C, or any other standardisation organisation wants to attract “normal” developers to get more diverse inputs, they/we should start by being respectful to everyone. Don’t try to show everyone how superclever you are. Don’t be a jerk. Don’t scare people away, because then only the loud ones stay, and the quieter shy people, or people who have more urgent matters to attend (such as, you know, having a working business website even if it’s not using the latest and greatest API) will just leave.
Steve shares my concerns …but he still refers to my post as “piffle”.
I can’t win.
Alex’s response to my post about Web Components, in which he ignores my excitement and dismisses my concerns as “piffle and tosh.”
I gotta say: I think cautious optimism and nervous excitement are healthy attitudes to have about any technology. For Alex to dismiss them so summarily makes me even more worried. Apparently you’re either with Web Components or you’re against them. Heaven forbid that you might voice any doubts or suggest any grey areas.
The beatings will continue until morale improves.
I very much agree with Orde’s framing here: I don’t think it makes much sense to talk about “above the fold” CSS …but it makes a lot of sense to talk about critical CSS.
And, yeah, it’s another example of progressive enhancement.
Alice Bartlett shares her experience of getting aria-live regions to work in a meaningful way.
Harry has written down his ideas and recommendations for writing CSS.
Those lovely people at Filament Group share some of their techniques for making data tables work across a range of screen sizes.
Dan Donald gets to the heart of progressive enhancement:
Assumptions in themselves don’t have to be inherently bad but let’s recognise them for what they are. We know very little but that can hopefully enable us to be far more flexible and understanding in what we create.
Scott shares the code that Filament Group are using to determine which style declarations are critical (and can be inlined) and which are non-critical (and can be loaded asynchronously). It makes quite a difference in perceived performance.
By the way, I really, really like the terminology of “critical” and “non-critical” CSS, rather than “above the fold” and “below the fold” CSS.
Dave wanted to figure out if having a responsive site necessarily meant taking a performance hit, so he ran the numbers on his own site. It turns out all of performance-related issues are not related to responsive design.
Ten facets of web development that you can choose to focus on. One of them is from me …but other nine are worth paying attention to.
Zoe uses one little case study to contrast two different CSS techniques: display-table and flexbox. Flexbox definitely comes out on top when it comes to true source-order independence.
I can relate to every single word that Bastian has written here.
The longer I look at boilerplates, build tools, frameworks and ways to make my life as a developer easier, the more I long for the basics.
Some very handy techniques for working with right-to-left text.
The challenges of maintaining a living breathing front-end style guide for an always-evolving product (the Lonely Planet website in this case).
My interest in rich client-side apps has almost entirely reversed, and now I’m more interested in doing good ol’ server rendering with the occasional side of progressive enhancement, just like we did it in 2004.
This post resonates with me 100%.
I can very much relate to what Dan is talking about here. I have no idea what I do any more.
No doubt we’ll always feel we’re behind the curve as there always seems like more to learn. That’s OK. No-one knows it all, but it is hard knowing what people expect of you.
Derek’s excellent advice on avoiding over-reliance on data attributes has this brilliant nugget of insight:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works
A healthy dose of scepticism about Web Components, looking at them through the lenses of accessibility, security, and performance.
I share some of this concern: Web Components might look like handy ready-made out-of-the-box solutions, but the truth is that web developers have to do much more of the hard graft that was traditionally left to the browser.
Some great thoughts in here about web development workflow and communication between designers and developers.
I believe that the solution is made up of a variety of tools that encourage conversation and improve our shared lexicon. Tools such as styleguides, pattern libraries, elemental and modular systems that encourage access not only by developers, but by designers, shareholders and editors as well.
A great post from Anna on the front-end styleguides she’s worked on for A List Apart and Code for America. ‘Twas a pleasure working with her on the Code for America project.
A-mer-ica! Fuck yeah!
Another front-end style guide for the collection. This time it’s from A List Apart. Lovely stuff!
Like Drew, I’ve noticed some real hostility to the idea of progressive enhancement recently. Like Drew, I don’t really understand where this attitude comes from. It’s not like progressive enhancement prevents you from doing anything you would do otherwise: it’s just another way of approaching the way you build for the web.
I hope I’m wrong, but I suspect that some developers are letting their tools dictate their principles—the tail wagging the dog (where the tail is Angular, Ember, etc.).
The markup for the patterns that Mailchimp use on their products. I love getting a glimpse of how companies handle this kind of stuff internally.
John addresses the price of increasing complexity in front-end development.
Yes, tooling can make our life easier. We type fewer keystrokes, and commit more code. But as software engineers learned a long time ago, most of the life of an applications is not in its initial development. It’s in maintaining it. This is something we on the web have had the luxury of being able to largely ignore up to now. After all, how many of the things you build will last years, decades?
A terrific piece by Remy—based on a talk he gave—on when he uses jQuery and, more importantly, when he doesn’t. His experiences and conclusions pretty much mirror my own, but of course Remy is far more thoughtful and smart than I.
Really good stuff.
This issue of A List Apart is a great double-whammy. Lara Swanson has a ton of practical tips for front-end performance enhancements, and Brian dives deep into making your own icon fonts.
I like the sound of the book that Chris is writing for Smashing Magazine. It sounds like a very future-friendly approach to front-end development.
Everything you ever wanted to know about using SVG today.
A really good introduction to front-end performance techniques. Most of this was already on my radar, but I still picked up a handy tip or two (particularly about DNS prefetching).
At this stage it should go without saying that you should be keeping up with this kind of thing: performance is really, really, really important.