Friday, July 21st, 2017
Thursday, July 20th, 2017
Every single browser maker has the same stance when it comes to features—they want to hear from developers at the coalface.
“Tell us what you want! We’re listening. We want to know which features to prioritise based on real-world feedback from developers like you.”
“How about container quer—”
I don’t think it’s an exaggeration to say that literally every web developer I know would love to have container queries. If you’ve worked on any responsive project of any size, you’re bound to have bumped up against the problem of only being able to respond to viewport size, rather than the size of the containing element. Without container queries, our design systems can never be truly modular.
But there’s a divide growing between what our responsive designs need to do, and the tools CSS gives us to meet those needs. We’re making design decisions at smaller and smaller levels, but our code asks us to bind those decisions to a larger, often-irrelevant abstraction of a “page.”
But the message from browser makers has consistently been “it’s simply too hard.”
Now, as I understand it, Houdini is the CSS arm of the extensible web. Just as web components will allow us to create powerful new HTML without lobbying browser makers, Houdini will allow us to create powerful new CSS features without going cap-in-hand to standards bodies.
During the talks, you could send questions over Twitter that the speaker could be quizzed on afterwards. As Philip was talking, I began to tap out a question: “Could this be used to polyfill container queries?” My thumb was hovering over the tweet button at the very moment that Philip said in his talk, “This could be used to polyfill container queries.”
For that happen, browsers need to implement the layout API for Houdini. But I’m betting that browser makers will be far more receptive to calls to implement the layout API than calls for container queries directly.
Once we have that, there are two possible outcomes:
- We try to polyfill container queries and find out that the browser makers were right—it’s simply too hard. This certainty is itself a useful outcome.
- We successfully polyfill container queries, and then instead of asking browser makers to figure out implementation, we can hand it to them for standardisation.
But, as Eric Portis points out in his talk on container queries, Houdini is still a ways off (by the way, browser makers, that’s two different conference talks I’ve mentioned about container queries, just in case you were keeping track of how much developers want this).
However it happens, I’d just love to see some movement on container queries. I’m not alone.
I know container queries would revolutionize my design practice, and better prepare responsive design for mobile, desktop, tablet—and whatever’s coming next.
Wednesday, July 19th, 2017
In which I have a conversation with a polar bear.
Very well-mannered species …I’ll miss them when they’re gone.
Tuesday, July 18th, 2017
Time for another video from Patterns Day. Here’s Sareh Heidari walking us through Grandstand, the CSS framework at the BBC.
Friday, July 14th, 2017
This looks like a sensible way to detect if the user is offline, and provide appropriate feedback, like making certain links or forms inactive.
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.
The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
Thursday, July 13th, 2017
This primer on progressive web apps starts by dispelling some myths:
- Your thing does not have to be an “Application” to be a PWA.
- PWAs are not specifically made for Google or Android.
- PWAs are ready and safe to use today.
Then it describes the three-step programme for turning your thing into a progressive web app:
- The Manifest.
- Go HTTPS.
- The Service Worker.
Tuesday, July 11th, 2017
We don’t want the field to de-democratize and become the province solely of those who can slog through a computer science degree.
So we need new tools that let everyone see, understand, and remix today’s web. We need, in other words, to reboot the culture of View Source.
Patterns Day videos
Eleven days have passed since Patterns Day. I think I’m starting to go into withdrawal.
Fortunately there’s a way to re-live the glory. Video!
And remember, the audio is already online as a podcast.
The videos are coming! The videos are coming!
Here’s the first one: Laura Elizabeth opening the show at Patterns Day.
We’re building on a web littered with too-heavy sites, on an internet that’s unevenly, unequally distributed. That’s why designing a lightweight, inexpensive digital experience is a form of kindness. And while that kindness might seem like a small thing these days, it’s a critical one.
Monday, July 10th, 2017
I love the way Matthias sums up his experience of the Beyond Tellerrand conference. He focuses on three themes:
- Rediscovering originality,
- Storytelling with code, and
- Adopting new technologies.
I heartily agree with his reasons for attending the conference:
There are many ways to broaden your horizons if you are looking for inspiration: You could do some research, read a book or an article, or visit a new city. But one of the best ways surely is the experience of a conference, because it provides you with many new concepts and ideas. Moreover, ideas that were floating around in your head for a while are affirmed.
Sunday, July 9th, 2017
I love seeing people go from Codebar to full-time dev work. It’s no surprise in Zara’s case—she’s an excellent front-end developer.
Thursday, July 6th, 2017
Geek humour is no laughing matter, as Chris demonstrates here with his thorough dissection of that coffee mug.
CSS is weird. It’s unlike any other code, and that makes a lot of programmers uncomfortable. But used wisely it can, in fact, be awesome.
It’s not often I say this, but read the comments.
Tell it, brother!
Wednesday, July 5th, 2017
I frequently see web developers struggling to become better, but without a path or any indication of clear direction. This repository is an attempt to sharing my experiences, and any contributions, that can help provide such a direction.
It’s broken down into four parts:
- 10 Domains of Web Development
- Events and Interaction
- Internationalization / Localization
- Understandability / Content
- Interviewing for Web Developers
- Productivity for Web Developers
- Web Training Hierarchy
- Level 1 - Writing Code
- Level 2 - Accessibility and Security
- Level 3 - Architecture
- Level 4 - Innovation
I don’t necessarily agree with everything here (and I really don’t like the “rockstar” labelling), but that’s okay:
Anything written here is open to debate and challenges are encouraged.
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.