Donate money to support Codebar:
By donating to codebar you are helping to promote diversity in the tech industry so that more women, LGBTQA and other underrepresented folks will be able to get started with programming and raise their skills to the next level.
Thanks to jQuery, you probably don’t need jQuery. Just look at all these methods that started life in jQuery, that are now part of the standardised DOM API:
remove()prepend()before()replaceWith()closest()This resonates a lot—we’ve been working on something similar at Clearleft, for very similar reasons:
We rode the folk knowledge train until it became clear that it was totally unscaleable and we struggled to effectively commute know-how to the incoming brains.
At Made By Many, they’ve sliced it into three categories: Design, Technology, and Product Management & Strategy. At Clearleft, we’re trying to create a skills matrix for each of these disciplines: UX, UI, Dev, Research, Content Strategy, and Project Management. I’m working on the Dev matrix. I’ll share it once we’ve hammered it into something presentable. In the meantime, it’s good to see exactly the same drivers are at work at Made By Many:
The levels give people a scaffold onto which they can project their personalised career path, reflecting their progression, and facilitating professional development at every stage.
You can help support the indie web community with their fairly modest costs: about $200 each month for hosting, domain names, and the like. Also:
We want IndieWeb events to be as accessible as possible, regardless of personal barriers. Because of this, we have offered a travel scholarship fund in the past to underrepresented groups thanks to our generous sponsors. Your support will allow us to continue to offer and expand this scholarship fund, helping make sure that IndieWebCamps represent everyone.
Rachel uncovers a great phrase for dealing with older browsers:
It isn’t your fault, but it is your problem.
She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.
Crucially, there’s one message that hasn’t changed in fifteen years:
Websites do not need to look the same in every browser.
It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.
Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.
Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!
I heard nothing but good things about this talk from the Fronteers conference. There’s some great stuff in here—I really like its historical perspective.
Charlotte is a big fan of feature queries.
Eric walks through a really nice use of CSS shapes and @supports on a page of the An Event Apart site.
It’s a nice little illustration of how we can use advanced features of CSS right now, without the usual wait for widespread support.
A thorough explanation of @supports from Jen, with plenty of smart strategies for using it in your CSS today.
Paul argues that the biggest problems for interoperability on the web don’t come from support (or lack of support) for entire features, but from the frustrating inconsistencies when features land in different browsers at different times with different implementations:
- Platform inconsistencies hurt us more than big feature differences, we should start to try and prioritize aligning the platform
- We need better tools to help us understand what the inconsistencies are and guidance on how to manage them
- Developers should raise more issues to keep browser vendors accountable when there are differences
If you’re planning on giving Fractal a test drive, jump into this Slack channel. Mark and others will be able to help you out with any questions that aren’t covered in the docs.
Shamefully, I haven’t been doing one-to-ones with my front-end dev colleagues at Clearleft, but I’m planning to change that. This short list of starter questions from Lara will prove very useful indeed.
Una’s [Instagram filters in CSS}(https://github.com/una/CSSgram) are great, but the browser support for CSS filters isn’t as good as, say, the browser support for canvas. Here’s a clever bit of scripting to polyfill filters using canvas.
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.
On just about every client project that I work on, the subject of browser support comes up. Rightly so. It’s an important issue on which to get mutual understanding and agreement. But all too often, this important question is framed in a binary, true/false, go/no-go way: “Which browsers do we/don’t we support?”
Really, the first thing to get agreement on is not a list of browsers, but what we mean by the word “support”. In my mind, that word implies that a user of a particular browser should be able to accomplish the primary tasks on the website, whether that’s reading an article, booking a ticket, or buying a product. That doesn’t mean that the task must be experienced in pixel-perfect fidelity to an ideal visual design.
But to others, that’s exactly what “support” means. Personally, I’d call that optimisation. As Brad puts it:
There is a difference between support and optimization.
So to put it in glib terms, I support every browser …but I optimise for none.
Alright, fine. But I still need to get to some mutual understanding with a client about which browsers will get the optimised experience and which browsers will simply be supported.
Personally, I like the Filament Group’s approach of discussing this in terms of features rather than browsers. It makes sense to me to say the browsers that support geolocation will get the geolocation features, or the browsers that support offline caching will get the offline caching features. There’s no need to produce a list of what those browsers are for each feature, and in any case, the list would be constantly changing and updating with each new browser release.
But—and this is a big but—nine times out of ten, when the issue of browser support comes up, it isn’t about functionality; it’s about branding. What clients generally want to know is which browsers will get the ideal visual design. Obviously the newer versions of Chrome and Firefox are going to get all the lovely layouts, rounded corners, gradients, transparencies, and animations …but what about older versions of Internet Explorer? Even if users of IE8 and IE7 can accomplish their tasks, will the “degraded” visual presentation hurt their experience?
My hypothesis is that it won’t. Users of older versions of Internet Explorer aren’t doing a side-by-side comparison of the same website opened up in the latest Chrome nightly. Considering what their daily usage must be like—unable to use Facebook, unable to use Google services—I suspect that they are happy just to be able to complete their task, regardless of the site’s visual fidelity.
There’s another viewpoint—one that I’ve heard expressed by clients—that even users of older browsers should still get the ideal, pixel-perfect visual design. The hypothesis here is that, by allowing someone to experience anything less than the perfect presentation, the client’s brand will be damaged in the mind of that person.
Like I said, this is something that comes up on most client projects, and this is the point at which we’d have to come to an agreement about which hypothesis we’re going to go with. Of course I’m going to argue in favour of the first hypothesis, but I’ve come to realise that arguing in favour of either hypothesis is the wrong approach. We shouldn’t be debating this …we should be testing it.
We have two competing hypotheses about a group of users. Instead of trying to read their minds, why not test with that group of users to find out which hypothesis is correct? No matter what the results of the test, they will be valuable either way.
Think about the amount of work that’s going to go in to optimising for older browser versions—it’s going to take quite a bit of time and money. It makes sense to ensure that this time and money isn’t being spent on little more than a hunch that pixel-perfection is important to those users. On the other hand, if the test reveals that actually those users really will have a lesser opinion of a brand unless they get pixel-perfect parity with newer browsers, then you’ll know that the time and money spent making that happen isn’t wasted.
Josh wrote recently that 1 hour of research saves 10 hours of development time:
Or, in longer terms if more people appreciated how one day of user research can save weeks of coding I think they would do it more. It is remarkable what you decide to not build after talking to a few people closely.
When it comes to decisions around browser support/optimisation, I think that even a little bit of up-front research and testing could potentially save a lot of time, money, and heartache. I’m not sure exactly what form the testing should take, but I’m interested in figuring it out.
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.
Primer, but Twitter.
The supersmart Scott Jenson just gave a talk at The Web Is in Cardiff, which was by all accounts, excellent. I wish I could have seen it, but I’m currently chilling out in Florida and I haven’t mastered the art of bilocation.
Last week, Scott wrote a blog post called My Issue with Progressive Enhancement (he wrote it on Google+, which is why you might not have seen it).
In it, he takes to task the idea that—through progressive enhancement—you should be able to offer all functionality to all browsers, thereby foregoing the use of newer technologies that aren’t universally supported.
If that were what progressive enhancement meant, I’d be with him all the way. But progressive enhancement is not about offering all functionality; progressive enhancement is about making sure that your core functionality is available to everyone. Everything after that is, well, an enhancement (the clue is in the name).
The trick to doing this well is figuring out what is core functionality, and what is an enhancement. There are no hard and fast rules.
Sometimes it’s really obvious. Web fonts? They’re an enhancement. Rounded corners? An enhancement. Gradients? An enhancement. Actually, come to think of it, all of your CSS is an enhancement. Your content, on the other hand, is not. That should be available to everyone. And in the case of task-based web thangs, that means the fundamental tasks should be available to everyone …but you can still layer more tasks on top.
If you’re building an e-commerce site, then being able to add items to a shopping cart and being able to check out are your core tasks. Once you’ve got that working with good ol’ HTML form elements, then you can go crazy with your enhancements: animating, transitioning, swiping, dragging, dropping …the sky’s the limit.
This is exactly what Orde Saunders describes:
I’m not suggesting that you try and replicate all your JavaScript functionality when it’s disabled, above all that’s just not practical. What you should be aiming for is being able to complete the basics - for example adding a product to a shopping cart and then checking out. This is necessarily going to be clunky as judged by current standards and I suggest you don’t spend much time on optimising this process.
Scott asked about building a camera app with progressive enhancement:
Snarky Question: How are you supposed to ‘progressively enhance’ an HTML camera app? Show puppies? Not everything devolves to simple markup
— Scott Jenson (@scottjenson) October 25, 2014Here again, the real question to ask is “what is the core functionality?” Building a camera app is a means to an end, not the end itself. You need to ask what the end goal is. Perhaps it’s “enable people to share photos with their friends.” Going back to good ol’ HTML, you can accomplish that task with:
<input type="file" accept="image/*">Now that you’ve got that out of the way, you can spend the majority of your time making the best damn camera app you can, using all the latest browser technologies. (Perhaps WebRTC? Maybe use a canvas element to display the captured image data and apply CSS filters on top?)
Scott says:
My point is that not everything devolves to content. Sometimes the functionality is the point.
I agree wholeheartedly. In fact, I would say that even in the case of “content” sites, functionality is still the point—the functionality would be reading/hearing/accessing content. But I think that Scott is misunderstanding progressive enhancement if he think it means providing all the functionality that one can possibly provide.
Mat recently pointed out that there are plenty of enhancements on the Boston Globe site that require JavaScript, but the core functionality is available to everyone:
@jgarber @mjacksonw Right. Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.
— mat marqNOVEMBER (@wilto) September 25, 2014Scott again:
What I’m chaffing at is the belief that when a page is offering specific functionality, Let’s say a camera app or a chat app, what does it mean to progressively enhance it?
Again, a realtime chat app is a means to an end. What is it enabling? The ability for people to talk to each other over the web? Okay, we can do that using good ol’ HTML—text and form elements—with full page refreshes. That won’t be realtime. That’s okay. The realtime part is an enhancement. Use Web Sockets and WebRTC (in the browsers that support them) to provide the realtime experience. But everyone gets the core functionality.
Like I said, the trick is figuring out what’s core functionality and what’s an enhancement.
Ethan provides another example. Let’s say you’re building a browser-based rich text editor, that uses JavaScript to do all sorts of formatting on the fly. The core functionality is not the formatting on the fly; the core functionality is being able to edit text:
@scottjenson That was how we approached @geteditorially’s rich editor, anyway: start with a textarea, layer on functionality from there.
— Ethan Marcotte (@beep) October 25, 2014If progressive enhancement truly meant making all functionality available to everyone, then it would be unworkable. I think that’s a common misconception around progressive enhancement; there’s this idea that using progressive enhancement means that you’re going to spend all your time making stuff work in older browsers. In fact, it’s the exact opposite. As long as you spend a little bit of time at the start making sure that the core functionality works with good ol’ fashioned HTML, then you can spend most of your time trying out the latest and greatest browser technologies.
As Orde put it:
What you are going to be spending the majority of your time and effort on is the enhanced JavaScript version as that is how the majority of your customers will be experiencing your site.
The other Scott—Scott Jehl—wrote a while back:
For us, building with Progressive Enhancement moves almost all of our development time and costs to newer browsers, not older ones.
Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.
Approaching browser support this way requires a different way of thinking. For everything you’re building, you need to ask “is this core functionality, or is it an enhancment?” and build accordingly. It takes a bit of getting used to, but it gets easier the more you do it (until, after a while, it becomes second nature).
But if you’re thinking about progressive enhancement as “devolving” down—as Scott Jenson describes in his post—then I think you’re on the wrong track. Instead it’s about taking care of the core functionality quickly and then spending your time “enhancing” up.
Scott asks:
Shouldn’t we be allowed to experiment? Isn’t it reasonable to build things that push the envelope?
Absolutely! And the best and safest way to do that is to make sure that you’re providing your core functionality for everyone. Once you do that, you can go nuts with the latest and greatest experimental envelope-pushing technologies, secure in the knowledge that you don’t even need to worry about the fact that they don’t work in older browsers. Geolocation! Offline storage! Device APIs! Anything you can think of, you can use as a powerful enhancement on top of your core tasks.
Once you realise this, it’s immensely liberating to use progressive enhancement. You can have the best of both worlds: universal access to core functionality, combined with all the latest cuting-edge technology too.
Some excellent research for web developers: find out which unicode characters have the widest support—release useful for choosing icons.