AI 摘要：这篇文章系统梳理了 CSS 中各种布局（Grid、Flexbox、Block、绝对定位等）的对齐机制，总结了 -content、-items、*-self 等属性在不同语境下的行为逻辑，重点在于区分 内容层级 (content level) 与 项目层级 (item level) 的对齐方式。文章核心思想是：对齐总和尺寸 (sizing) 与剩余空间 (free space) 的关系密不可分，不同布局模型下默认值和可用属性会有所不同，理解其背后的逻辑远比记忆“如何写出居中”更重要。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. Alignment 理论
• CSS 对齐有两个层次：content level（容器内整体内容）、item level（单个元素）。
• 三类主要属性：place-content / place-items（全局），place-self（单个元素）。
• 属性分为两大轴向：align-（垂直/交叉轴），justify-（水平/主轴）。
• 对齐效果依赖剩余空间是否存在，“normal” 默认等同于 stretch。

2. Grid Container
• content 概念在 Grid 对应 grid cells，item 对应 grid items。
• -content 控制网格单元整体在容器内的分布；-self 控制 item 在单元格内对齐。
• auto 与 1fr 表现不同：auto 利用对齐缩放元素；1fr 会占满剩余空间导致无对齐空间。
• 元素跨多格时，对齐发生在其 grid area 内。

3. Flexbox Container
• 与 Grid 相比更复杂；main axis 与 cross axis 的切换是难点。
• 横向（默认 row 模式）：只有 content level 对齐，使用 justify-content。
• 纵向：存在 content 和 item 两级对齐，align-items / align-self 针对单个 item。
• flex-wrap 决定是否启用纵向 content 对齐；flex-grow 消耗剩余空间，可能使对齐无效。
• 改变 flex-direction 会交换主/交叉轴，导致属性在不同维度表现不同。

4. Block Container 与 Inline 元素
• Block 布局默认垂直堆叠：垂直轴只有 content level 对齐，水平轴有 item level 对齐 (justify-self)。
• Inline 元素的对齐靠 text-align，不是 CSS Alignment 模块。
• 内联+块元素混合时，浏览器会生成 anonymous block boxes 来容纳内联元素，但这些匿名盒不能直接对齐。

5. auto margins
• margin: auto 本质是将剩余空间转换为 margin，因此其视觉效果类似居中。
• 区别在于 place-self: center 保留空隙，而 auto margin 会填满空间。
• 在 Flexbox 主轴上 auto margin 始终生效，甚至在没有 item-level 对齐的场景下。

6. 绝对定位元素
• 对齐基于 containing block 或 inset-modified containing block(IMCB)。
• 可通过 place-self 直接居中，替代传统的 top:50% + transform 技巧。
• margin: auto 亦可应用，但需显式指定 width/height。

7. Safe Alignment
• 当内容溢出 (negative free space) 时，safe 关键词可避免内容被裁剪到不可见区域。
• 如 justify-self: safe center，可保证在可滚动环境不导致内容不可到达。
• auto margin 天然是安全的，因为只考虑正向剩余空间。

Tom Miller takes inspiration from a rainbow of crayon colors by wearepretendfriends for this brilliant GSAP-fueled SVG animation.
Tom Miller 从 wearepretendfriends 的彩虹蜡笔颜色中汲取灵感，制作了这个精彩的 GSAP 驱动的 SVG 动画。

Orbs N Ringz
Matthias Hurrle carves out a set of polished shapes in this "Fun little shader doodle, heavily influenced by KomaTebe's tw_OrbsNRingz. I just wanted to recreate it with only a fragment shader so I could play around with it."

AI 摘要：本文介绍了 CSS 新推出的 @function 规则，展示了如何通过自定义函数为样式表带来逻辑能力，使 CSS 更加动态、可维护，并提升设计系统的表达能力。作者通过五个实用案例（数值取反、透明度管理、流体排版、条件圆角、响应式侧边栏）以及一个 Bonus 案例（light-dark 主题切换函数），说明了现代 CSS 在逻辑处理和组件化方向上的巨大潜力，并展望了未来 @mixin 和 @apply 等特性的应用场景。

[以下是方便搜索索引的大纲 (AI 生成)，请读原文]
1. CSS @function 简介
• 新特性在 Chrome 139 中落地，允许编写自定义函数。
• 与 var() 的静态取值不同，@function 能处理逻辑与参数运算。
• 适合在 设计系统 (Design System) 场景下做动态样式抽象。

2. 五大示例函数
• Negation function：实现取反功能，可用于自动计算负值边距。
• Opacity function：将任意颜色与透明度参数结合，简化半透明色值生成。
• Fluid Typography function：在 clamp() 基础上提供更可读的语义化流体排版，允许不同文本类型按不同速率缩放。
• Conditional Radius function：在元素接近 viewport 边缘时移除圆角，避免布局异常，无需 media query。
• Responsive Sidebar function：根据屏幕宽度调整侧边栏宽度（默认 20ch），有效减少重复的媒体查询逻辑。

3. Bonus：Light-Dark Theme Function
• 扩展原生 light-dark() 的适用范围，不仅局限于颜色，还能应用到边框样式、字体粗细等。
• 结合 if()、:scope、style() 查询与 @function，实现更强大的主题自定义能力。

4. 未来展望
• CSS Functions and Mixins Draft Spec 将继续发展，未来的 @mixin 与 @apply 将支持输出多条样式规则。
• 可以构建类似 utils.css 的工具库，与 reset.css、utils.js 类似，让 CSS 工程化更完善。

AI 摘要：本文深入解析了 CSS 中的对齐 (Alignment) 机制，强调“内容(content)”与“项目(item)”两个层级对齐逻辑在 Grid、Flexbox、Block 以及定位元素中的差异。文章不仅讲述了基础属性（如 align-, justify-, place-* ）的适用场景，还对 auto margin 、绝对定位、以及 safe alignment 等进阶知识点逐一拆解，并指出 对齐始终依赖于尺寸 (sizing) 与剩余空间 (free space)**。这是篇对 CSS 布局本质高度还原的长文，尤其适合想彻底理解 Alignment 背后的逻辑的开发者。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 对齐基础理论 （The Alignment Theory）
• CSS 中存在约 10 个对齐相关属性，常令初学者困惑。
• 对齐分为 content level 与 item level。
• 常用属性类别：
• place-content（容器内容对齐）
• place-items（所有项目的对齐）
• place-self（单个项目的对齐）
• 属性均存在水平 (justify-*) 与垂直 (align-*) 两个维度。
• place-* 为两者速记写法，但常用分开书写。

2. Grid 布局对齐
• Grid Anatomy：容器(container) → 格子单元(cells) → 项目(items)。
• 内容层级：对齐的是 grid cells 作为整体；项目层级：对齐的是 cell 内单个项目。
• start / end 使用逻辑值而非物理 left / right，支持不同语言排版。
• Auto sizing：若设为 auto，grid cells 会填充或收缩，normal 默认值等于 stretch。
• auto vs 1fr 区别：
• auto 可收缩并依赖对齐调整。
• 1fr 吞下所有剩余空间，导致无法再进行 content-level 对齐。
• 跨单元格项目 (grid area)：对齐是在 grid area 内进行，而非单一 cell。

3. Flexbox 布局对齐
• Flexbox Anatomy：容器 → flex lines → flex items。
• 纵向轴 (cross axis)：
• 内容层级对齐：flex lines 可整体对齐。
• 项目层级对齐：item 可在 flex line 内独立对齐 (align-self)。
• 横向轴 (main axis)：
• 仅存在内容层级对齐 (justify-content)，项目不可单独对齐 (justify-self 无效)。
• flex-wrap：
• nowrap 禁止纵向内容层对齐 (align-content 失效)。
• wrap 激活 content-level alignment 即便只有一行。
• flex-direction：行列切换会翻转主轴与交叉轴，因此相同属性可作用于不同方向。
• **flex-grow 与对齐关系：填满剩余空间会禁用对应轴上的 content 对齐。

4. Block 容器与内联元素
• 在 Block container 中：
• 水平：item-level 对齐（justify-items, justify-self），没有内容层级对齐。
• 垂直：content-level 对齐 (align-content)，没有 item-level。
• inline 元素的特殊情况：
• 单纯 inline → 水平继承 text-align，无需 flex/grid。
• 混合 inline 与 block → 浏览器生成“匿名块盒 (anonymous block box)”封装 inline 元素，但这些盒子不可直接对齐。

5. Auto Margins
• 对齐的是 margin box 而非元素本身。
• margin: auto 会将剩余自由空间转化为 margin，本质是“吞掉空间”的机制。
• 在 Flexbox 主轴下依旧生效，即便没有 item-level alignment。
• 注意：Block 垂直方向 auto margin 无效，需要定义 width 才能触发水平居中。
• 与 place-self: center 的区别：前者 margin box 吞满，后者保持元素周围留有自由空间。

6. 绝对定位元素 (Absolutely-positioned elements)
• 对齐以 containing block 作为参考区域（父级 padding box 或视口）。
• inset 定义内缩区域 (IMCB)，对齐作用在该区域内。
• *-self 属性适用，但浏览器兼容性有限。
• 传统写法 （ left: 50%; top: 50%; transform: translate(-50%, -50%)）依旧可用，但推荐 inset: 0; place-self: center 更直观。

7. Safe Alignment
• 当内容超出容器（负自由空间）时，可仍然对齐，但滚动条可能导致内容不可达。
• 使用 safe 修饰符（如 justify-self: safe center）可避免此问题。
• margin: auto 的对齐方式天然就是“safe”，因其不作用于负自由空间。

8. 总结
• Alignment 逻辑核心：永远依赖剩余空间和元素尺寸。
• Grid、Flexbox、Block 各自有不同的默认行为和适用属性。
• 常见混淆点：
• auto vs normal vs stretch
• justify-items 和 justify-content 适用范围不同
• fr 与 flex-grow 会吞掉剩余空间，从而禁用对齐。

AI 摘要：本文介绍 CSS Mixins 与 CSS Functions 的基本概念、与 Sass 的区别、浏览器支持情况以及实际应用方法。同时，作者还分享了 CSS 工作组（CSSWG）的最新会议进展，包括 Masonry 布局、色域映射、Mixins 与层的交互、以及新提案“功能型捕获”(Functional Capturing) 等。最后还回顾了近期“Winging It”系列中关于容器查询、Popover 定位和 stretch 关键词的讨论。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. CSS Mixins
• 定义与区别：介绍 CSS Mixins 是什么，并对比 Sass Mixins 的差异。
• 用法说明：展示如何在 CSS 中编写和调用 Mixins。
• 兼容性：当前主要由 Chrome (开启 CSSMixins flag) 支持，其他浏览器尚未普遍实现。

2. CSS Functions
• 概念：解释 CSS Functions 的设计背景。
• 使用方法：介绍如何在 CSS 中定义与应用 Functions。
• 支持情况：目前仅在 Chromium 浏览器试验特性下可用，需要开启 Experimental Web Platform Features。

3. CSS 工作组 (CSSWG) 最新动态
• Masonry Display：关于 Masonry 布局模式的进展。
• 色彩标准：就 gamut-mapping 提案达成一致意见。
• Mixins 结合 Layers：讨论条件语句中使用 Mixin 的场景。
• 新提案：Functional Capturing 与 Indirect Cyclic Conditions。
• 参考文档：
• CSS Mixins & Functions Explainer
• W3C CSS Functions and Mixins Module
• Mixins Browser Support: Chrome
• ……

4. Winging It 系列回顾
• Episode 23：庆祝容器查询 (Container Queries) 自 2023 年起在所有浏览器全面支持。
• Episode 22：关于 Popover 的定位技巧，使用 CSS anchor positioning 与 position-area。
• Episode 21：介绍新的 stretch 关键词，与 100% 和 100vh 的差异及应用场景。

AI 摘要：本文介绍了在使用 React 状态管理工具（如 Zustand）与 React Query 结合时，如何避免通过 useEffect 手动同步客户端状态，而是通过 派生状态 (derived state) 的方式更声明式地实现一致性。文中指出派生优于同步，因其能减少副作用，提高可靠性和灵活性，并展示了用户选择和表单默认值处理的实践案例。

很有意思的副标题：劝 Apple 牢记初心，不忘使命，力戒形式主义、官僚主义，坚持实事求是的思想路线，树立正确设计观，真抓实干，改变作风

AI 摘要：本文深入分析了 Apple 在最新系统中引入的 Liquid Glass 材质与新视觉设计系统，指出虽然在界面质感上有一定突破（折射、HDR 高光、动态层级效果），但在实际交互和系统适配上存在明显不足：iOS 标签栏和工具栏设计复杂化、macOS 工期仓促导致界面割裂、Safari 与相机等核心 App 出现交互违和感。作者认为 Apple 为了设计形式感而牺牲了过往的易用性，这种“视觉优先”的改动可能是 Beta 阶段的过度尝试。最后总结：Apple 借由 Liquid Glass 等 shader 技术试图确立设计新高度，但缺乏完整生态适配，反而让用户体验受到冲击。

AI 摘要：本文探讨了字体预加载 (font preload) 对网站性能的利弊。虽然预加载可以减少字体切换导致的双重渲染和版式抖动，但在 Chrome 等浏览器的机制下，可能会推迟 First Contentful Paint (FCP) 和 Largest Contentful Paint (LCP)。文章重点分析了预加载在不同场景下的风险与收益，并提出了实践建议：仅预加载关键字体、自托管字体、谨慎区分文本字体与图标字体。结论是：预加载并非万能方案，而应基于实际数据与场景做针对性优化。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 不预加载字体的情况
• 默认情况下，浏览器会先渲染系统字体，再替换为下载完成的 Web 字体，造成二次渲染与视觉抖动。
• 开发者常用预加载来避免多次绘制。

2. 预加载字体的权衡 (Trade-offs)
• 预加载强制浏览器提前下载字体，但可能延迟首屏渲染。
• 大多数现代浏览器支持 link rel="preload"，但行为存在差异。

3. 浏览器行为与渲染延迟
• Chrome 从 2023 年起更改机制：延迟首屏渲染 (first paint)，等待字体加载完成，从而减少布局错位。
• 这种优化虽然稳定首屏效果，却可能推迟 FCP 与 LCP。

4. Chrome 的预加载超时 (Preloading timeout)
• Chromium 设计了两个超时机制：
• 1500ms 自导航开始计算，避免过长等待。
• 100ms 自最后一个阻塞性资源加载完成开始计算，保证不会显著拖慢首屏渲染。

5. 预加载最佳实践
• 仅预加载首屏必需字体，避免过度使用。
• 始终加上 crossorigin 属性，即使同域下载。
• 尽量自托管字体，避免额外 DNS/TLS 开销。
• 优先预加载文本字体，不建议预加载图标字体（初期核心是可读内容，而非交互按钮）。

6. 结论 (Bottom line)
• 字体预加载可以优化体验，也可能破坏性能。
• 建议从小规模测试入手，基于真实用户数据决策，不盲目“一刀切”。

AI 摘要：这篇文章系统介绍了 CSS 中的颜色插值 (color interpolation) 概念，解释了其在渐变 (gradient)、过渡 (transition)、动画 (animation)、颜色混合 (color-mix) 等场景中的应用。文章重点区分了矩形色彩空间 (rectangular color space) 与极坐标色彩空间 (polar color space)，并详细阐述了色相插值 (hue interpolation) 的四种方法（shorter / longer / increasing / decreasing），展示了如何通过不同插值策略影响渐变、颜色过渡以及动画效果，从而为网页设计实现更自然、更富表现力的色彩体验。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 颜色插值的基础概念
• 定义：在两个颜色点之间计算中间颜色的过程。
• 作用：生成独特色彩、改进渐变、增强动画与过渡效果。
• 典型示例：利用 oklch() 在 CSS 动画中平滑过渡。

2. 应用场景与支持插值的 CSS 功能
• 所有渐变函数 (linear-gradient, conic-gradient 等)。
• color-mix() 函数：可指定色彩空间和插值方法。
• 动画 (animation) 和过渡 (transition)。
• 图像滤镜 (filter)。
• 相对颜色语法 (relative color syntax)。

3. 插值语法与规则
• 一般形式：
color-mix(in <color-space> <hue-interpolation-method>, color1, color2)。
• in 关键字：用于指明插值的色彩空间。
• <color-space>：包括矩形与极坐标空间。
• <hue-interpolation-method>：定义色相插值方式 (shorter / longer / increasing / decreasing)。

4. 色彩空间分类
• 矩形色彩空间 (Rectangular color space)：
• 以直角坐标 (XYZ 轴) 形式描述，如 srgb, lab, display-p3。
• 极坐标色彩空间 (Polar color space)：
• 以圆柱坐标形式表示，三个值分别是明度 (lightness)、彩度 (chroma)、色相 (hue)。
• 插值时色相是角度，因而需定义旋转方向。

5. 色相插值 (Hue Interpolation) 四种方式
• shorter：沿最短路径过渡（默认）。
• longer：沿最长路径过渡。
• increasing：始终顺时针方向过渡。
• decreasing：始终逆时针方向过渡。
• 类比时钟：类似指针从一个刻度旋转到另一个刻度，可以走近路或远路，也可强制顺/逆时针。

6. 实际应用场景
• 渐变 (gradient)：利用色相插值生成更自然的平滑过渡。
• 颜色混合 (color-mix)：可指定色彩空间并控制过渡方向，获得更独特的混色效果。
• 动画 (animation)：通过关键帧在不同色值之间平滑过渡，展现动态的色彩体验。

AI 摘要：本文从浏览器为何要限制 JavaScript 定时器 (setTimeout、setInterval 等) 的触发频率谈起，分析了其背后的性能与电池保护原因，并通过实验对比了不同的替代方案（MessageChannel、window.postMessage、scheduler.postTask 等）的性能表现。作者得出结论，scheduler.postTask 是最理想的方案，并进一步探讨了浏览器设计在“开发者自由 vs 用户体验保护”之间的平衡。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 背景与问题提出
• setTimeout(0) 实际上存在 4ms 的强制延迟 (clamping)
• 浏览器通过限制 (throttling) 避免过度消耗电量与降低交互体验
• 不同浏览器和环境对 setTimeout 的限制程度不同（例如后台标签页可达 1 秒，Safari 更严格）

2. 定时器替代方案的演进
• setImmediate：已废弃，仅存在于 IE/旧版 Edge
• MessageChannel.postMessage：常见 hack，但 Safari 有额外限制
• window.postMessage：性能较好，但可能与页面其他脚本冲突
• scheduler.postTask：新兴 API，表现最佳，且与浏览器渲染管线更契合

3. 实验与性能测试
• 测试方法：不同浏览器下运行 101 次迭代，测量定时器延迟
• 结果发现：
• Chrome 和 Firefox 的 setTimeout 明显受 4ms 限制
• Safari 对 setTimeout 和 MessageChannel 的限制更重
• scheduler.postTask 在 Chrome/Firefox 下表现优异
• fake-indexeddb 采用的最佳方案：优先 scheduler.postTask，降级 MessageChannel 或 window.postMessage

4. 浏览器设计哲学与开发者困境
• 设计者分为两派：
• 一派主张强制限制 API 防止开发者“自作聪明”导致性能恶化
• 另一派主张提供灵活 API，让开发者自负责任
• W3C 优先级原则：始终将用户体验放在开发者需求之上
• Scheduler API 的出现，体现了两派的折中：给开发者更精细的任务控制，但仍保持与浏览器渲染流程一致

5. 未来展望与风险
• 目前 postTask/postMessage 暂未遭到限制
• 但若开发者滥用（如滥用高优先级任务），未来也可能被浏览器进一步干预
• 文章提醒开发者谨慎选用 API，避免“自找麻烦”

AI 摘要：本文探讨了 CSS 中 box-sizing 的使用方式，指出将其设置为 inherit 并非最佳实践。继承适合内容相关的属性（如 color 、 font ），而 box 模型 (box model) 属于 box 属性，不应该被继承。文章进一步说明，在现代布局中同时使用 border-box 和 content-box 都很常见，通过统一设置 * { box-sizing: border-box; } 并在局部覆盖即可满足需求，而继承会带来误导和不必要的复杂性。作者最后强调：请不要继承 box 模型。

You bloody motherfucker hacked a reputed account and still not able to steal millions, Shame on you.
Bloody fool, you hacked a massive npm developer account and still cant steal single penny. You are such a looser.