<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Css on MacWorks</title><link>https://macworks.dev/tags/css/</link><description>Recent content in Css on MacWorks</description><generator>Hugo</generator><language>en</language><atom:link href="https://macworks.dev/tags/css/index.xml" rel="self" type="application/rss+xml"/><item><title>Engineer Reads</title><link>https://macworks.dev/docs/week/blogs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/week/blogs/</guid><description>&lt;h1 id="engineering-reads--week-of-2026-05-07-to-2026-05-15"&gt;Engineering Reads — Week of 2026-05-07 to 2026-05-15&lt;a class="anchor" href="#engineering-reads--week-of-2026-05-07-to-2026-05-15"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="week-in-review"&gt;Week in Review&lt;a class="anchor" href="#week-in-review"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;This week’s engineering discourse reflects a mature industry grappling with system boundaries and human intent. From constraining unpredictable AI integrations into strictly bounded functional workflows to leveraging organizational psychology to structure open-source compiler architecture, practitioners are aggressively reclaiming control over non-determinism. We are seeing a distinct pushback against buzzword-driven hype in favor of operational stability, rigorous domain modeling, and trusting native web standards over heavyweight abstractions.&lt;/p&gt;</description></item><item><title>2026-05-15</title><link>https://macworks.dev/docs/week/blogs/engineer-blogs-2026-05-15/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/week/blogs/engineer-blogs-2026-05-15/</guid><description>&lt;h1 id="engineering-reads--2026-05-15"&gt;Engineering Reads — 2026-05-15&lt;a class="anchor" href="#engineering-reads--2026-05-15"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="the-big-idea"&gt;The Big Idea&lt;a class="anchor" href="#the-big-idea"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The maturation of native web standards is eroding the necessity of heavyweight utility frameworks, allowing engineers to reclaim simplicity by lifting framework concepts directly into native implementations. Concurrently, open-source communities are being forced to enact strict moderation boundaries to protect engineering velocity from sprawling ideological debates.&lt;/p&gt;
&lt;h2 id="deep-reads"&gt;Deep Reads&lt;a class="anchor" href="#deep-reads"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href="https://jvns.ca/blog/2026/05/15/moving-away-from-tailwind--and-learning-to-structure-my-css-/"&gt;Moving away from Tailwind, and learning to structure my CSS&lt;/a&gt;&lt;/strong&gt; · jvns.ca
Transitioning away from a framework like Tailwind doesn&amp;rsquo;t require abandoning its structural lessons; rather, engineers can extract its underlying systems—such as preflight resets, utility classes, and typographic scales—and implement them directly in semantic CSS. The author restructures their plain CSS into conceptual components with unique classes, effectively treating stylesheets like isolated Vue or React components to prevent global cascading failures and keep cognitive overhead low. Instead of relying on Tailwind&amp;rsquo;s predefined media query utilities (e.g., &lt;code&gt;md:text-xl&lt;/code&gt;), the native architecture heavily leverages modern CSS Grid features like &lt;code&gt;auto-fit&lt;/code&gt; and &lt;code&gt;minmax()&lt;/code&gt; to construct fluid, responsive layouts without arbitrary breakpoints. The primary tradeoff of dropping the framework is losing its built-in guardrails and relying entirely on personal discipline, though combining native CSS &lt;code&gt;@import&lt;/code&gt; and nesting capabilities with a minimal &lt;code&gt;esbuild&lt;/code&gt; pipeline helps maintain project sanity. Full-stack developers and frontend engineers should read this to understand how modern CSS standards have caught up to utility frameworks, offering the flexibility to write complex layouts that strict utilities fundamentally restrict.&lt;/p&gt;</description></item><item><title>2026-05-16</title><link>https://macworks.dev/docs/week/simonwillison/simonwillison-2026-05-16/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/week/simonwillison/simonwillison-2026-05-16/</guid><description>&lt;h1 id="simon-willison--2026-05-16"&gt;Simon Willison — 2026-05-16&lt;a class="anchor" href="#simon-willison--2026-05-16"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="highlight"&gt;Highlight&lt;a class="anchor" href="#highlight"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The standout update today is the release of &lt;code&gt;datasette-llm-limits 0.1a0&lt;/code&gt;, which introduces a practical way to manage LLM API costs directly within Datasette. It&amp;rsquo;s a highly useful piece of infrastructure for anyone building and exposing AI tools, solving the very real problem of managing usage limits for local or hosted LLM integrations.&lt;/p&gt;
&lt;h2 id="posts"&gt;Posts&lt;a class="anchor" href="#posts"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;[datasette-llm-limits 0.1a0]&lt;/strong&gt;(&lt;a href="https://simonwillison.net/2026/May/15/datasette-llm-limits/#atom-everything"&gt;https://simonwillison.net/2026/May/15/datasette-llm-limits/#atom-everything&lt;/a&gt;)
Simon released an alpha version of &lt;code&gt;datasette-llm-limits&lt;/code&gt;, a new plugin that works alongside the &lt;code&gt;datasette-llm&lt;/code&gt; and &lt;code&gt;datasette-llm-accountant&lt;/code&gt; packages. It allows administrators to configure per-user or global spending limits for LLM usage inside of Datasette. This is a crucial addition for safely scaling AI-assisted database workflows by keeping API usage costs strictly under control.&lt;/p&gt;</description></item><item><title>2026-05-04</title><link>https://macworks.dev/docs/archives/blogs/engineer-blogs-2026-05-04/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://macworks.dev/docs/archives/blogs/engineer-blogs-2026-05-04/</guid><description>&lt;h1 id="engineering-reads--2026-05-04"&gt;Engineering Reads — 2026-05-04&lt;a class="anchor" href="#engineering-reads--2026-05-04"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;h2 id="the-big-idea"&gt;The Big Idea&lt;a class="anchor" href="#the-big-idea"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The defining leverage in modern software engineering is safely raising the ceiling of complexity you can manage as an individual. Whether offloading design constraints to curated color systems or using AI to validate aggressive C memory models, the goal is to reserve human cognitive load for system specifications and architectural correctness.&lt;/p&gt;
&lt;h2 id="deep-reads"&gt;Deep Reads&lt;a class="anchor" href="#deep-reads"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Links to CSS colour palettes&lt;/strong&gt; · jvns.ca · &lt;a href="https://jvns.ca/blog/2026/05/04/css-colour-palettes/"&gt;Source&lt;/a&gt;
The author highlights a practical tradeoff of abandoning utility frameworks like Tailwind for vanilla CSS: the loss of carefully constrained, pre-baked design tokens. While dropping Tailwind reduces tooling overhead, engineers often lack the aesthetic expertise to build cohesive color systems from scratch. To bridge this gap, the post surfaces drop-in alternatives like uchū, flexoki, and reasonable colours, with the latter specifically optimizing for accessibility. The author also points to dynamic generative colors using the CSS &lt;code&gt;oklch&lt;/code&gt; function, while noting that complex color generators often remain difficult for non-designers to leverage effectively. This is a quick but essential read for full-stack developers who want the simplicity of vanilla CSS without shipping visually hostile interfaces.&lt;/p&gt;</description></item></channel></rss>