This is a great (free!) course on learning CSS from the basics up. Nicely-pitched explanations with plenty of examples.
I don’t think I agree with Don Knuth’s argument here from a 2014 lecture, but I do like how he sets out his table:
Why do I, as a scientist, get so much out of reading the history of science? Let me count the ways:
- To understand the process of discovery—not so much what was discovered, but how it was discovered.
- To understand the process of failure.
- To celebrate the contributions of many cultures.
- Telling historical stories is the best way to teach.
- To learn how to cope with life.
- To become more familiar with the world, and to know how science fits into the overall history of mankind.
This is a truly wonderful web page! It’s an explanation from first principles of how cameras and lenses work.
Then you realise that every post ever published on this personal site is equally in-depth and uses the same content-first progressive enhancement approach.
I’ll be moderating this online panel next week with Emma Boulton, Holly Habstritt Gaal, Jean Laleuf, and Lola Oyelayo-Pearson.
I’m looking forward to it! Come along if you’re interested in the future of design teams.
What will the near-future look like for design teams? Join us as we explore how processes, team structures and culture might change as our industry matures and grows.
This is a nifty visual interactive explainer for the language of CSS—could be very handy for Codebar students.
Having your independent blog is an excellent way to share what you think in a decentralized way, independent of any major company that may add a paywall to it (Medium, I am looking at you).
An excellent and clear explanation of specificity in CSS.
A really great one-page guide to HTML from Bruce. I like his performance-focused intro:
If your site is based on good HTML, it will load fast. Browsers incrementally render HTML—that is, they will display a partially downloaded web page to the user while the browser awaits the remaining files from the server.
There’s a voice inside your head that prevents you from sharing ideas—punch it in the face. - Airbag Industries
When I challenge the idea of topics—especially when I suggest writing about a design topic—the “I don’t know what to write about” excuse goes to level two: Someone has already written about [design topic]. And that might be true, but by Great Gutenberg’s Ghost, if that was a hard requirement for publishing, we’d have one newspaper, a few magazines, and maybe a thousand books. Hollywood would be a ghost town because we got to the end of all of the movie tropes by 1989. We’d have seventy-five songs with lyrics, but re-recorded in every music style and everyone would still hate Yanni. The point is you can’t let the people who have come before you be the excuse to stop you from writing or, frankly, creating.
A great explanation of the curse of knowledge …with science!
(This, by the way, is the first of 100 blog posts that Matthias is writing in 100 days.)
Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have?
I think it’s even worse than that. Not only are potential new devs being put off ever getting started, I know plenty of devs with experience who have pushed out by the overwhelming and needless complexity of the modern web’s toolchain. It’s like a constant gaslighting where any expression of unease is summarily dismissed as being the whinings of “the old guard” who just won’t get with the programme.
John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole.
(Just watch as Lea’s post gets written off as an edge case.)
I really enjoyed having a chat with Ed and Tom on their podcast. It’s aimed at people making a career shift into web development, but that didn’t stop me banging on about my usual hobby horses: progressive enhancement, resilient web design, and all that jazz.
I love how Remy explains front-end development to his kids:
The bones are the HTML. Each bone has a name, we call them tags (or elements).
…the skin and the paint on the skin, this is CSS.
I wrote something recently about telling the story of performance. Sue Loh emphasis the importance of understanding what makes people tick:
Performance engineers need to be an interesting mix of data-lovers and people-whisperers.
Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.
Who hurt you, Robin?
I can see this coming in very handy at Codebar—pop any CSS selector in here and get a plain English explanation of what it’s doing.