Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!
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:
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
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.
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.
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.
Some excellent research for web developers: find out which unicode characters have the widest support—release useful for choosing icons.
I really like Scott’s approach to defining what “support” means in terms of browsers—it makes a lot sense to break things down to the component level.