Let Links Be Links · An A List Apart Article
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
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.
If you insist on having “social” sharing buttons, here’s a way to avoid bloating your page unnecessarily.
But you might want to reconsider whether you need them at all.
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.
Advice for writing Sass. I don’t necessarily agree with everything, but on the whole, this is a solid approach.
It’s worth bearing Chris’s advice in mind.
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.
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.
This was a fun podcast—myself and Cyd from Code For America talk to Karen and Ethan about how we worked together. Good times.
The audio is available for your huffduffing pleasure.
A great technique from Heydon for styling radio buttons however you want.
Patty’s excellent talk on responsive design and progressive enhancement. Stick around for question-and-answer session at the end, wherein I attempt to play hardball, but actually can’t conceal my admiration and the fact that I agree with every single word she said.
My name is Jeremy and I am a boring front-end developer.
The Android vs. iOS debate is one hinges around whether you think it makes more sense to target a (perceived) larger market, or target one that the technorati favor. But why choose? Building a good responsive web app has a series of benefits, the primary one being that you target users on every platform with one app. Every user. Every platform. All the time. Release whenever you want. A/B test with ease. Go, go go.
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.
I share the concerns expressed here about the “sizes” attribute that’s part of the new turbo-powered img element (or “the picture element and its associates”, if you prefer). Putting style or layout information into HTML smells bad.
This is a concern that Matt Wilcox has raised:
Change the design and those breakpoints are likely to be wrong. So you’ll need to change all of the client-side mark-up that references images.
I can give you a current use-case: right here on adactio.com, you can change the stylesheet …so I can’t embed breakpoints or sizes into my img elements because—quite rightly—there’s a separation between the structural HTML layer and the presentational CSS layer.
Following on from that post of Jason’s I linked to, Chris also emphasises that, for most use cases, you probably only need to use srcset (and maybe sizes), but not the picture element with explicit sources.
It’s really, really great that people are writing about this, because it can be quite a confusing topic to wrap your head around at first.
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.
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.
I had a good ol’ chat with Justin Avery from Responsive Web Design Weekly. We talk about performance, Responsive Day Out, and yes, progressive enhancement.
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.
An astute comparison of the early years of the web with the early years of the app store. If there’s anything to this, then the most interesting native apps are yet to come. App Store 2.0?
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).
Mark Otto talks through the state of Github’s CSS and the processes behind updating it. There’s a nice mix of pragmatism and best practices, together with a recognition that there’s always room for improvement.
A look behind the scenes of gov.uk. I like their attitude to Photoshop comps:
We don’t want a culture of designs being “thrown over a wall” to a dev team. We don’t make “high fidelity mock ups” or “high fidelity wireframes”. We’re making a Thing, not pictures of a Thing.
We don’t have a UX Team. If the problem with your service is that the servers are slow and the UX Team can’t change that, then they aren’t in control of the user experience and they shouldn’t be called the user experience team.
Here’s an intriguing approach to offering a navigation control that adapts as the user scrolls.
I’m not too keen on the way it duplicates the navigation in the markup though. I might have a play to see if I can find a way to progressively enhance up from a link-to-footer pattern to achieve this.
John peers behind the surface veneer of the web’s current screen-based setting:
The challenge for us as developers and designers for the web becomes less about screens and pixels and buttons and much more about how the web augments our lives, both actively and passively; how it makes us know ourselves and our homes and workplaces and environments better.
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.
With the usual caveat that I wish this were published on Craig’s own site, I particularly like this passage:
Apps, too, are ephemeral. Some of the most ephemeral software we’ve ever produced. Ephemeral if for no other reason than because of their gated homes. Our apps cower below the fickle whim of App Store Gods, struck down for no reasonable reasons or for very reasonable reasons. It doesn’t matter which, the end result is always the same: gone, forever.
A lovely little tale of empowerment through HTML and CSS.
Scott’s trying to find out the best ways to load critical CSS first and non-critical CSS later. Good discussion ensues.