Responsive Enhancement ◆ 24 ways
My contribution to this year’s edition of the web’s best advent calendar.
My contribution to this year’s edition of the web’s best advent calendar.
A great primer on using
picture. I think I’ll be referring back to this a lot.
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.
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.
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.
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.
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.
Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?
He’s right, y’know.
Those smart people at Filament Group have gathered their open-source code into one handy place. Useful!
Bruce’s thoughts on ensuring accessibility in Web Components. He thinks that the vocabulary of ARIA is up to the job, so that’s good enough for me.
John shares his concerns about the increasing complexity involved in developing for the web.
In describing her approach to building the wonderful Julius Cards project, Chloe touches on history, digital preservation, and the future of the web. There are uncomfortable questions here, but they are questions we should all be asking ourselves.
I heartily concur with Lyza’s mini-manifesto:
I think we need to try to do as little as possible when we build the future web …putting commonality first, approaching differentiation carefully.
It’s always surprised me how quickly developers will reach for complex, potentially over-engineered solutions, when—in my experience—that approach invariably creates more problems than it solves.
Simplicity is powerful.
A cogent definition and spirited defence of progressive enhancement:
Progressive Enhancement is an extension of our shared values on the web and goes to the root of the web. I believe—and hope you agree—that the web is for everybody and should be accessible regardless of the device a user brings to the party.
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 handy collection of links to web-related podcasts. Go forth and huffduff.
Yet another timely reminder from Tim, prompted by the naysayers commenting on his previous excellent post on progressive enhancement, universal access, and the nature of the web.
A great call-to-arms from Tim, simply asking that we create websites that take advantage of the amazing universality of the web:
The web has the power to go anywhere—any network, any device, any browser. Why not take advantage of that?
Inevitably there is pushback in the comments from developers still in the “denial” stage of coming to terms with what the web is.
An ever-timely call-to-arms from Eric:
Sir Tim Berners-Lee envisioned the web as open and accessible for everyone, no matter where they comes from, what speed their connection is, how capable their browsers are or how good their eyes or hands or both work. I feel proud every day to make that vision reality, and it is the job of web developers to make it a reality.
He’s right. We have tremendous power and privilege, and correspondingly tremendous responsibility.
I wholeheartedly agree with Christian’s diagnosis of the average web page: it’s overweight to the point of obesity. Fortunately Dr. Heilmann has some remedies.
Some great thoughts from Mike Davies about the strengths of the web, prompted by some of the more extreme comments made by James Pearce at Full Frontal last week.
I should point out that James was being deliberately provocative in order to foment thought and discussion and, judging from this blog post, he succeeded.
The Web’s independence from the hardware and software platform people use is a feature. It’s better than cross-platform frameworks which are constantly criticised for not producing exact native-feeling apps on the multitude of platforms they run on. The Web is above that pettiness.
A lovely bit of hypertext.
A good round-up of what web development means today …and what web developers need to do to keep pace.
This thread on whether HTML5 Boilerplate should include Respond.js by default (and whether the CSS should take a small-screen first approach) nicely summarises the current landscape for web devs: chaotic, confusing …and very, very exciting.
This is a great encapsulation of what I’ve been banging on about at conferences for a while now: let’s stop pretending we know the capabilities, network speed or viewport size of a site visitor’s browser.
The video of my talk/rant at the DIBI conference in Newcastle/Gateshead earlier this year, for your viewing pleasure.
A great reminder from Bruce that we need to remember to use cutting-edge web technology responsibly.
A superb post by Dan on the bigger picture of what’s wrong with hashbang URLs. Well written and well reasoned.
Josh explains the pros and cons of embedding background images in your CSS using base 64 encoding.
Tim Bray calmly explains why hash-bang URLs are a very bad idea.
This is what we call “tight coupling” and I thought that anyone with a Computer Science degree ought to have been taught to avoid it.
So why use a hash-bang if it’s an artificial URL, and a URL that needs to be reformatted before it points to a proper URL that actually returns content?
Out of all the reasons, the strongest one is “Because it’s cool”. I said strongest not strong.
A one-stop link shop for resources on web standards.
Nicole proposes an interesting way of clearing floats with a combination of display:table-cell and generated content.
Paul gives an excellent and thorough explanation of why systems thinking is important in web design.
All of this year's 24Ways articles are available as an £8 book with all the proceeds going to UNICEF.
Think Vitamin have been their accessibility material available for free.
How awesome is this? A real-world "print'n'paper magazine" for web developers. "An elegant, timeless, collectable magazine for people who love web design and are intrigued by the possibility of the web"
Sir Tim Berners-Lee and others call for the creation and recognition of a new discipline: "What we really want is for people around the world to start calling themselves web scientists."
Jeremy Zawodny rails against the continuing snobbery towards front-end engineers.
Aaron uses image replacement on an image to provide one image for screen and another print. Very clever.