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.

Another excellent website on British butterflies, particularly good for comparison of caterpillars and chrysalis shapes, to go with the previous entries on butterfly photographs and moths.

A really succinct quote from Seth on glass-is-unoptimised thinking (as opposed to cyber-optimism or cyber-pessimism, which I agree are both untenable outlooks):

Technological change doesn’t always make things better. It often comes with significant side effects and costs. And yet, thanks [to] the vigilance and hard work of some folks, technology also has a long track record of making us safer, healthier and even happier.

The cyber-realist sees both and is focused on being careful about systemic change and lock-in, especially for cultural and organizational changes that are hard to walk away from.

I know very little about Edward Tufte, but they clearly have quite the following in the design/typography space. Tufte CSS is a project aiming to emulate various tenets that Tufte used to design their books and articles, but with a focus on how they might work on the web. The result is a very pleasing library of CSS classes and defaults that looks pretty decent, in a slightly old-fashioned, Victorian way (which I'm obviously all for).

On a more personal level, I find the use of "sidenotes" (their term), figures, epitaphs, and simple layout rules most interesting; there are definitely a few ideas here that I find inspirational.

[PS thanks to Jeremy on the IndieWeb chat for linking me to this project, and Edward Tufte in general, following a discussion on whitespace and typography.]

On sidenotes, which (on smaller screens) collapse and become togglable text that expands between paragraphs; neat UI/UX:

Sidenotes are like footnotes, except they don’t force the reader to jump their eye to the bottom of the page, but instead display off to the side in the margin.

Sidenotes are a great example of the web not being like print. On sufficiently large viewports, Tufte CSS uses the margin for sidenotes, margin notes, and small figures. On smaller viewports, elements that would go in the margin are hidden until the user toggles them into view.

On the project (I just liked the sentiment 😂):

Tufte CSS is merely a sketch of one way to implement this particular set of ideas.

If you're new to (or unsure of) CSS transforms at all, I can't think of a better explanatory introduction than this.

Plus, once again, Josh has managed to teach me some new tips and tricks about a topic I thought I had pretty well covered. In this case, the revelation of the (much cleaner, imo) turn unit for rotational amount:

The turn unit represents how many turns the element should make. 1 turn is equal to 360 degrees.

It's obscure, but well-supported; the turn unit goes all the way back to IE 9!

Cathy has produced an exceptional overview of modern responsive/intrinsic design best practices. From fluid units, to content-led design, to subgrid, pretty much every current or on-the-horizon feature of CSS/HTML is covered.

That includes some very interesting thoughts on the potential limitations of container queries, which was nice to see. Plus, what is hands-down the best explanation of how the new min(), max(), and clamp() functions actually work (maybe this time it'll stick 😄).

On the fact that design has fundamentally changed (oh how this resonates right now):

What I learned the hard way was that you can’t just add responsiveness at the end of a project. To create fluid layouts, you need to plan throughout the design phase.

On the benefits of subgrid in CSS (their example showing cross-component adaptation is simple yet very clear):

CSS Grid allows us to separate layout and content, thereby enabling flexible designs. Meanwhile, Subgrid allows us to create designs that can adapt in order to suit morphing content.

On the core of responsive/intrinsic/inclusive design today:

Good design for the unexpected should allow for change, provide choice, and give control to those we serve: our users themselves.

CEDARS+ is a new font categorisation system by the folks over at ilovetypography. Rather than trying to define fonts by fairly abstract categories like neogothic or Didone, ILT have come up with a system that breaks a font down into specific traits:

• Contrast
• Energy
• Details
• Axis
• Rhythm
• Structure
• + (basically anything else; allowing them to more easily extend relevant filters based on alphabet or character sets, thereby supporting a wider range of languages and writing systems)

It's a neat idea explained more fully in the introductory blog post, but I honestly didn't think a huge amount about it until I saw it in action on their font search engine. Being able to filter fonts by the physical characteristics, such as slant or line thickness, just feels a whole lot more intuitive to me, particularly as someone who couldn't name more than a half dozen "traditional" font categories. Hopefully, more places adopt the system in the future.

Jeremy covers the recent Chrome alert() controversy very clearly, but I'm a particular fan of their points about the underlying assumptions that have made these kinds of breaking changes something that can be considered.

The concept that the web is the purview of "web developers"; that programmers alone build websites – it's a dangerous, naive, and deeply problematic sentiment. As Jeremy puts it:

You can choose to make [the web] really complicated. Convince yourself that “the modern web” is inherently complex and convoluted. But then look at what makes it complex and convoluted: toolchains, build tools, pipelines, frameworks, libraries, and abstractions. Please try to remember that none of those things are required to make a website.

This is for everyone. Not just for everyone to consume, but for everyone to make.

On the removal of anything from web technologies:

I know that removing dangerous old features is inevitable, but it should also be exceptional. It should not be taken lightly, and it should certainly not be expected to be an everyday part of web development.

As someone who has been involved in a greenfield design system build for the last six months, I empathise a lot with Amy's well-worded explanation of why content design should never be overlooked.

I'd even go a stretch further, and just say that design systems can only thrive when all front-end disciplines are brought together early, and actively lean on each others speciality knowledge. Design systems can be used to scale best practices, or bad practices, equally, so best to catch things early and bake good ideas in at a foundational level.

On why content matters, and how design systems can scale little issues rapidly into big problems:

Leaving content out of the equation damages the user experience, and when we do this at the level of design systems, we’re allowing that experience to scale.

On the long term repercussions of not involving specialists early in ideation:

It means content designers have to spend time identifying and correcting widespread issues they probably would have caught at the root, had they been involved in the design of the system component or pattern.

On why consistency in language across a site is a core requirement:

Perhaps I’m biased, but I’d wager that using different words to describe the same actions, processes and information is the most damaging and confusing kind of inconsistency of all.