Ire Aderinokun:

在网格容器内，有网格单元格。 任何使用 grid-template-* 属性定位和调整大小的单元格都构成显式网格的一部分。 任何未使用此属性定位/调整大小的网格单元格都构成隐式网格的一部分。

了解显式网格和隐式网格非常强大。 这是我的快速解读

• 显式： 你定义一个网格并将项目放置在你想要它们去的确切位置。
• 隐式： 你定义一个网格并让项目尽可能地落入其中。

网格可以同时是两者！

Dave Rupert:

我所有的客户平均使用大约 30 个第三方脚本，但与利益相关者讨论减少这些脚本时，最终会得出“如果我们将它们全部异步加载怎么办？” 这是一个很好的反驳，因为加载第三方脚本有正确和错误的方式，但仍然存在成本，这笔成本会转嫁给用户。 这就是我想要调查的。

是的，性能是一个主要问题。 但不仅仅是加载时间和这些脚本的最终权重，还有各种各样的问题。 戴夫列出了隐私、渲染阻塞、争夺 CPU 时间、争夺网络连接线程、数据和电池成本等等。

戴夫的搭档 Trent Walton 也在 深入思考第三方脚本，他在 最新的 ShopTalk Show 中谈到了这一点。

查看 Paolo Mioni 对 单个脚本的调查 以及它能做到的邪恶事情。

Kelly Sutton 给出了关于代码评审的良好建议。 很难选出一个最喜欢的。 我喜欢所有关于注意语气和让每个人都参与进来的东西，但我认为计算机化也很重要

如果计算机可以决定并执行规则，那就让计算机去做。 争论空格与制表符不是对人时间的有效利用。

关于技巧 #6：当使用的工具可以提供帮助时，这很酷，例如 GitHub 的这个新功能，代码建议可以变成提交。

JavaScript 中的依赖项非常简单。 除非 library 存在，否则我无法编写 library.doThing()。 如果库以某种基本方式发生变化，事情就会崩溃，希望我们的测试能够捕获它。

CSS 中的依赖项可能更加抽象。 Robin 在我们的时事通讯中刚刚写道 某些类（例如 position: absolute）的样式如何依赖于其他类（例如 position: relative）的样式，以及这如何有时会变得 — 最好 — 晦涩。

设计也存在依赖项，尤其是在设计系统中。 Nathan Curtis

你首先发布 icon，然后发布依赖于它的其他组件。 然后，icon 添加了次要功能或遇到了破坏性更改。 如果你更新了 icon，你不能停在那里。 你必须将这些更改传播到库中的所有依赖于 icon 的组件。

“如果我们升级并破坏了一个组件，我们必须遍历并修复所有依赖的组件。” — Jony Cheung，Atlassian 的 Atlaskit 软件工程经理

最大的变化发生在最小的组件中。

Nils Binder 讲解了如何通过向属性传递八个值，使用 border-radius 来操作元素，例如

.element {
  border-radius: 30% 70% 70% 30% / 30% 30% 70% 70%;
}

这是一个非常酷的技术，他还开发了一个名为 Fancy-Border-Radius 的小型 Web 应用程序，用于查看这些值在实践中的作用。 它允许你以任何你想要的方式操作形状，然后将代码直接复制粘贴到你的设计中

酷吗？ 我认为这种技术可能非常有用，如果你不想使用 SVG 来包裹一些内容，因为我最近看到很多网站使用“斑点”作为图形元素，而这无疑是一种有趣的新方法。 但这也让我想知道有多少相对古老而熟悉的 CSS 属性有一些隐藏的、在等待我们发现的秘密。

继续阅读 →

Hotjar 是你的团队需要的一切

如果你是一名 Web 或 UX 设计师，或者从事 Web 营销，Hotjar 将帮助你改进网站的性能。 免费试用。

没有，实际上没有。

我在 2011 年的 对 ::nth-everything 的呼吁 中试图阐明对它的需求。

Jeremy 在 2018 年在这里对这个问题进行了新的思考，他指出第一次公开表达对此的需求是在 15 年前。 所有相同的用例现在仍然存在，但可能略多，因为 Web 排版从那时起已经有了很大发展。 我们想要做更多事情（以及实现它的技巧）都更加强烈。

我似乎记得我们没有这些东西的主要原因不一定是像 布局悖论 这样的预期问题，而是世界上不同的类型化语言。 也就是说，有些语言中的单个字符就是单词，文本从不同的位置开始，并朝不同的方向运行。 “第一个”和“行”的含义可能会变得模棱两可，而规范不喜欢这种模棱两可。

<person>、<subhead>、<location>、<logo>… 提出一个你认为有用的 HTML 元素列表并不难。 所以，为什么我们不这样做？

Bruce Lawson 对此进行了解释。 结论基本上是我们并不真正需要，也许也不应该这样做。

据我统计，我们现在有 124 个 HTML 元素，其中许多对许多 Web 作者来说是未知的，或者经常混淆在一起 — 例如，<article> 和 <section> 之间的区别。 这让我觉得学习所有这些不同元素的认知负担越来越重。

Brad Frost 前几天在问这个问题…

Sass 人员，你们怎么做，为什么？ pic.twitter.com/dIBA9BIuCO

— Brad Frost (@brad_frost) 2018 年 10 月 1 日

.c-btn {
  &__icon {
      ...
  }
}

我想从技术上讲这是“嵌套”，但选择器最终是扁平的

.c-button__icon { }

问题是你是否这样做，或者只写出整个选择器，就像你对普通 CSS 所做的那样。 Brad 的帖子提到了两种方法的所有优缺点。

对我来说，我坚定地站在不“嵌套”的阵营，因为它让搜索选择器变得困难得多。 我绝对依赖能够在项目中搜索完全展开的类名，讽刺的是，就在 Brad 发布那个民意调查的时候，我被一个像这样的组合类难住了，并在我的一个代码库中改变了它。

Robin Rendle 也指出 搜索的困难 是一个问题，他给出了一个明显走得太远的例子！

Rachel Andrew 的最新文章中有很多值得引用的内容，都是关于 CSS 以及我们在社区中如何谈论它

CSS 被认为是这种脆弱的语言，我们跌跌撞撞，尝试一些东西，看看什么有效。 尤其是在布局方面，我们不是按照规定使用该系统，而是经常利用语言中的某些东西来实现比它最初设计得更复杂的布局。 我们不得不这样做，否则就只能满足于非常简单的网页。

Rachel 继续争辩说，我们可能不应该因为 CSS 如此奇怪而贬低它，因为 CSS 的工作原理和方式有充分的理由 — 更不用说随着时间的推移，它变得越来越可预测和强大

经常有人谈论那些以 CSS 为主要专长领域的开发人员如何感到自己的技能被低估。 我认为，将 CSS 说成这种古怪、怪异的语言，对我们来说并没有帮助。 CSS 与其他任何东西都不一样，因为它存在于一个与其他任何东西都不一样的环境中。 但是，我们可以开始将其理解为一种设计的语言，具有很大的一致性。 它有编码规则，我们可以开发出解释和教授它的方法，就像我们可以教我们的团队使用 Bootstrap 或最新的 JavaScript 框架一样。

我倾向于 有同样的感受，我一直都在思考如何最好地回答那些认为“CSS 很蠢很奇怪”的人。 试图解释为什么你的职业和专业领域是有用的，有时会让人沮丧。

我想开始这样做最好的方法是站起来说：“不，CSS 并不蠢也不奇怪。 CSS 很棒！”