I've always thought the utility of Tailwind was promising, but it bugged me that the way it worked was so counter to both best practices and the web stack's architecture. Well, introducing Open Props, a Tailwind-like set of importable design tokens that works entirely within CSS, using native functionality, and maintaining best practices 👏

I'm particularly impressed with the custom media queries. They only work with an additional plugin (I'm assuming a polyfill) for now, but they really highlight just how useful that spec will be once it's available. I'm particularly excited by the @media (--safariOnly) {...} syntax 😮

Some very clear criticisms of the whole "comedy shouldn't be censored" mentality. Comedy absolutely should not be censored, but it should be able to be critiqued. As Thought Slime puts it, (some) comedians seem to want a double standard: they want comedy to be seen as thought-provoking and boundary-pushing, but refuse to allow it to be analysed and dissected, stifling critical thought and artistic examination.

The video goes into this a lot more eloquently, but the gist boils down to three main points:

1. It's never "just a joke". Even Edgelord humour comes from a place of personal bias; making a joke that deliberately highlights a negative pattern is fine, but the underlying position is still necessary to review and consider (an example given is how the jokes around Trump and Putin being in a relationship are clearly homophobic, even if that isn't their intent it is part of the message being portrayed). Just because something is funny, doesn't make it just a joke, and most comedians will claim that their comedy is designed to raise a point, so analysis of comedy is sort of integral to it being a thing;
2. Comedy, and comedians, will always goof. They will tell insensitive jokes, they will have cultural blind spots, and even the most careful will screw up. That should be allowed and criticised so that the comedian learns what they did wrong and can remedy it moving forward. It's therefore important that comedy breeds a culture where speaking out is encouraged and where comedians are happy to evolve;
3. Censorship of comedy is bad, but you can't censor criticism of comedy either, they're equally problematic.
   

I also really like their comments on how comedy can just be to make people laugh. Not necessarily to laugh at others (and certainly not to punch down), but that comedy without a hidden message or desire to provoke thought is still comedy, and still has inherent value as an art form and skill.

If you're gonna ask people to be less sensitive and take a joke, maybe you need to be a little less sensitive and accept criticisms of that joke?

I have a vague memory of CSS Regions being talked about, but had completely forgotten them. It turns out that's likely because the spec has effectively been pulled. I think it's technically still out there, but IE11 is the only browser that still has any compatibility with them, so you can effectively treat it as DOA. That's a little bit of a shame, as I quite like the idea of being able to flow content between sections of a page, but Bruce does a good job of highlighting why it didn't work out and what a future second attempt might do better.

On the positive use-cases for Regions:

Some mobile navigations that we see on the web are a duplicated version of the desktop navigation, Regions will give us the ability to flow them instead of duplicated the general structure

The basic idea was to move things from the sidebar into specific regions throughout the content and then making the asides and ads more content aware for smaller screens.

On their downfall (one of the reasons that Safari and Google both pushed to remove them from browsers as the mobile web took off):

Magazine layouts on the web, while they look cool - would inhibit a user from finding what they were looking for in the first place.

An inciteful, well written, and intensely interesting (and important) look at media trends within modern white, liberal culture, focused around Bo Burnham's Inside but touching on a much wider variety of shows, films, and media in general. The core concept of "White Liberal Performative Art" is a particularly interesting lens to group together otherwise seemingly disparate media (for those of us within the white, liberal bubble).

A brilliant tool for quickly troubleshooting or writing regular expressions. Works perfectly for JavaScript syntax in particular.

A wonderfully sarcastic and extremely well-reasoned takedown of everything from software subscriptions to marketing deceptive patterns to NFTs 👍

I've chopped out the middle here, but I really like this sentiment from Seth on the nature of media, control, and the illusion of powerlessness.

Sometimes the media would like us to believe that we’re all astronomers, simply passive witnesses in a world out of our control.

But the world is never out of our influence.

...

The ocean is made of drops. And the drops are up to us. Who else is going to care enough to make an impact?

A website for exporting real-world terrain maps; extremely niche, but also extremely useful if needed.

Ahmad has put together some really interesting examples of where modern CSS techniques can replace traditional use-case for absolute positioning. I'd be really interested to know how some of them work with assistive technologies, but my gut instinct is that they're probably more accessible (on average), too.

One of the most useful techniques is one I have used, but frequently forget: stacking elements using CSS Grid. Ahmad has a particularly useful shorthand for condensing everything down to one grid cell:

.parent > * {
   grid-area: 1/-1;
}

For things like background images on cards, it's great, but the application also shows a way to position small "labels" or "tags"; very clever 👏

They also dive into display: contents, a relatively new addition to CSS that I've not explored at all. The ability to effectively "remove" wrapping elements within Flexbox and Grid contexts is particularly powerful:

<style>
 .wrapper {
   display: contents;
 }

 flex * {
   margin-top: 1rem;
 }
</style>

<div class="flex">
   <div class="wrapper">
      <h2>Title</h2>
      <p>Description</p>
   </div>
   <img src="..." alt="..." />
</div>

As Ahmad puts it, the .wrapper is now a "hidden ghost" in the DOM, so will not get the margin applied. Better still, you can then reorder the content as if the wrapper wasn't there:

.wrapper {
   display: contents;
}

h2, img {
   order: -1;
}

👆 Will result in the image inserting itself between the headline and description. Useful for components that might want to shuffle order based on API properties, for example.

Finally, there's this little nugget (as well as some generally useful notes on things like aspect-ratio):

No more using position: absolute with CSS transforms. For example, we can use margin: auto to center a flex item both horizontally and vertically.

Somehow, I had no idea that auto margins worked on the vertical axis in Flexbox; that's extremely useful 🤦‍♂️👏

That said, Ahmad does end the article with an example where absolute positioning may be the right solution. I say may because I'm not actually convinced. The alternative shown – negative margins – makes more sense to me in most situations, but a potentially better solution would be to use a background gradient to create the entirely empty "blue box" heading element. It's purely decorative, so why use a DOM node in the first place? That way, the user's avatar doesn't need to be repositioned out of normal flow at all. Just my 2c 😄

Heydon's video is an excellent overview of their much-loved owl selector and "stack" layout pattern. I actually didn't realise that Heydon was the original "inventor" of the owl, though it makes a lot of sense in hindsight 😄 Overall, though, the video is just a treasure trove of interesting ideas and code patterns!

• I really like the idea of using a developer-environment stylesheet to visually highlight issues like missing alt text, overly nested <div> elements, incorrect HTML inclusions etc. as a form of automated testing.
• A key benefit of the "owl" selector (i.e. * + *) is the low (zero) level of specificity that it imbues, making it easy to override. But that means adding :not statements increases the specificity and makes it unwieldy. Better to just use targeted overrides to filter out elements or sections that should not have the styles applied.
• I've been increasingly leaning on CSS custom properties to provide "props" within CSS classes and design system components, a technique that is both incredibly powerful and (once you get used to it) a lot more flexible than actual props, because you get in-built media query support without any JS. Heydon mentions a pattern which I've not thought of, but rather like:

<div class="stack" style="--stack-space: 2em">
  <Elem />
  <Elem />
  <Elem />
</div>

You would then set your .stack class like so:

.stack {
  * + * {
    margin-top: var(--stack-space, 1em);
  }
}

Neat 👍 (Namespacing used to mitigate potential collisions)

• In many ways, universal gap support (so close!) is a direct conversion of the owl operator into a first-class feature. Except gap cannot be overridden with exceptions as neatly; where you want different sized gaps between certain section combinations (still possible, but still requires margin and you just have to be a bit more clear).

Baldur has written a wonderfully paced, deeply interesting post on the whole SPA/MPA (AKA normal website) debate with one critical conclusion: SPAs are fine; MPAs are fine; anything will suck if mismanaged.

It's a surprisingly simple premise, yet they do a very good job of explaining the underlying assumptions and overarching viewpoint. I'm not sure that I'm fully convinced, but I certainly sympathise with a number of the key points, and agree that in a better-managed industry a lot of the current headaches and pain points would be easier to address or remove outright.

The article also contains a wonderful section of real-world examples of idiotic business objectives that is just a joy (albeit a painful joy) to read through. My favourite is:

We need these five features for feature parity with a competitor, but the CEO wants the interface to look ‘clean.’ Can’t we hide the buttons and widgets using hovers? Oh, and make the hovers work on mobile somehow.

On the reality of SPAs:

SPAs are both amazing and horrible. Sometimes in the same project. The web is large; it contains multitudes.

When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts. Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win.

On the problematic tradeoff that a lot of front-end frameworks (particularly those used to make SPAs) fall into, that making their tooling infinitely scaleable also makes it impossibly hard to maintain and increasingly complex (therefore resulting in a never-ending burden on the teams using it):

Which, when they present it as ‘scale’, sounds like a good thing. But it’s absolutely a bad thing when you’re in an industry that’s as mismanaged as ours. We can’t handle complexity. Having no upper limit to it is extremely bad.

On how Basecamp use cooldown periods between sprints (or "cycles") to enable much higher levels of overall productivity and creativity (Baldur covers a good amount of evidence that a lack of breaks during business cycles directly causes project failures, and it honestly makes a huge amount of sense):

Therefore, after each six-week cycle, we schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next.

During cool-down, programmers and designers on project teams are free to work on whatever they want. After working hard to ship their six-week projects, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities.

On how poor management and an over-emphasis on higher-order control results in poorly performing teams and catastrophic websites:

It helps to just understand that the reason why Single-Page-Apps or Hybrid Apps suck isn’t that they suck as a concept. Technology implemented by a dysfunctional organisation is almost always going to suck.

The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps. It’s bad management.

On how the reduced scope of MPAs should be seen as a benefit, not a disadvantage:

As developers, we need to operate under the assumption that good management is the exception, not the norm. Multi-Page-Apps and hybrid frameworks let under-resourced, mismanaged developer teams deliver reliable and safe code. That should not be dismissed lightly.