Ultimately you can’t control when and how things go wrong but you do have some control over what happens. This is why progressive enhancement exists.
This really, really resonates with me:
I think the thing I struggle the most with right now is determining when something new is going to change the way our industry works for the better (like responsive web design did 5 or 6 years ago), and when it’s just a fad that will fade away in a year or three (which is how I feel about our obsession with things like Angular and React).
I try to avoid jumping from fad to fad, but I also don’t want to be that old guy who misses out on something that’s an important leap forward for us. I spend a lot of time thinking about the longer term impact of the things we make (and make with).
I find this soooo relatable:
I know when I look at a design (heck, even if I know I’m not going to be building it), my front-end brain starts triggering all sorts of things I know will be related to the task.
Difference is, Chris comes up with some very, very clever techniques.
This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.
If you don’t fancy watching this video, Eric Runyon has written down the salient points about what it means for developers now that websites can be viewed on the Apple Watch. Basically, as long as you’re writing good, meaningful markup and you’ve got a sensible font stack, you’re all set.
Or, as Tim puts it:
When we build our sites in a way that allows people using less-capable devices, slower networks and other less than ideal circumstances, we end up better prepared for whatever crazy device or technology comes along next.
Mandy’s experiments with text effects in CSS are kinda mindblowing—I can’t wait to see her at Ampersand at the end of the month!
A nice intro to variable fonts.
Six steps to kickstart a web performance culture:
- Your dev environment is not your user’s environment
- It’s better to learn the fundamentals than the library
- Get the time to experiment and validate
- Educate your colleagues
- Share and celebrate success (and failure) stories
- Make performance part of your workflow
I think being simultaneously curious and skeptical of new technology is healthy attitude to have.
I want to learn new things in order to keep making good websites. I also think there’s a lot of value in talking about the difficulty in learning new things.
“Ah, this is good news!”, I thought, reading this update about how service worker scripts won’t be cached.
And that was the moment when I realised what an utter nerd I had become.
A thorough explanation of the history and inner workings of Cross-Origin Resource Sharing.
Like tales of a mythical sea beast, every developer has a story to tell about the day CORS seized upon one of their web requests, dragging it down into the inexorable depths, never to be seen again.
I had fun answering these questions.
I was just talking about how browser-based games are the perfect use-case for service workers. Andrzej Mazur breaks down how that would work:
- Add to Home screen
- Offline capabilities
- Progressive loading
Andy Bell is documenting is journey of getting to grips with web components. I think it’s so valuable to share like this as you’re learning, instead of waiting until you’ve learned it all—the fresh perspective is so useful!
In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.
I think Dave is right. At this point, it’s possible to be a React developer exclusively.
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
And, as Jake points out, you either need to go all in or not at all—you can’t really incrementally add Reactness to an existing project.
This ever-growing curated collection of interface patterns on CodePen is a reliable source of inspiration.
When to use
aria-hidden="true", and when you might need
aria-hiddenby itself is not enough to completely hide an element from all users, if that is the end goal.
When to use
aria-hiddencan be used to completely hide content from assistive technology, modifying an element’s
roleto “none” or “presentation” removes the semantics of the element, but does not hide the content from assistive technologies.
It turns out that Diana Smith isn’t just a genius with CSS—she’s a fantastic writer too. This post is somehow heartfelt and lighthearted at the same time. It’s also very humorous, but beneath the humour there’s an excellent point here about the rule of least power …and doing things the long, hard, stupid way.
Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.
That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.
Rafaela Ferro has written a good case study on Ev’s blog of using CSS grid to build some practical image-based responsive components.
Rachel gives a terrific explanation of CSS layout from first principles, starting with the default normal flow within writing systems, moving on to floats, then positioning—relative, absolute, fixed, and sticky—then flexbox, and finally grid (with a coda on alignment). This is a great primer to keep bookmarked; I think I’ll find myself returning to this more than once.