我们正在阅读的一些网络内容，并有一些想法。有我们应该知道的链接吗？告诉我们！
又一年！
你不应该哭，你不应该喊，我告诉你为什么：@BlueBeanieDay 将于 11 月 30 日到来！现在开始分享你的#bbd 照片、链接、文章和视频：https://#/3US4vHBsDR#a11y #WebStandards #InclusiveDesign #ProgressiveEnhancement pic.twitter.com/AiV3ktRqka
— zeldman (@zeldman) 2018 年 10 月 24 日
今年我感觉和过去一样。网络标准，作为一个整体概念，已经完全站稳脚跟，赢得了胜利。这是值得庆祝的，因为没有它们，网络将是一个笑话。因此，现在我们的工作是维护它们。当我们看到浏览器出现问题，并在标准流程之外发布 API 时，我们需要大声反对。这种竞争版本会导致网络回到一个黑暗的地方，在那里我们创建浏览器特定的版本。这会变得很痛苦，我们不再这样做，慢慢地，网络会失去。
Harry Roberts 撰写了一篇关于在一个有非常糟糕的设计缺陷的项目上工作的文章。该网站完全依赖于图像在渲染任何内容之前加载。他深入探讨了为什么这对于可访问性和性能不利，但更进一步地描述了这种问题如何会蔓延到其他问题。
然后 Harry 建议，在开发网站时，我们应该始终问自己一个关键问题：如果这张图片没有加载怎么办？例如，如果用户使用的是低端设备，使用的是不稳定的网络，使用的是一个鲜为人知的浏览器，或者是在没有关键 API 或功能的情况下查看网站……你懂的。
说到这一点，我们之前问过什么是好的前端开发者，我认为在读完 Harry 的文章后，这是对这个问题的最佳答案：好的前端开发者会不断问自己，“如果？”。
Jon Sneyers
FUIF 的主要动机之一是拥有一个设计优先的响应式图像格式，这意味着不再需要生成同一图像的多个变体：低质量占位符、缩略图、许多用于不同显示分辨率的缩小版本。单个文件，在不同的偏移量处截断，就可以做到同样的事情。
FUIF 还远未准备好使用，但这是一个很有趣的想法。我喜欢这样一个想法，即这种格式以这样的方式存储图像数据，你可以只请求文件的前几千字节，从而实质上获得一个低质量的版本，然后根据需要请求更多。看看这个由 Eric Portis 制作的小演示，它通过服务工作者和渐进式 JPEG 来展示它。
如果这个想法最终得到发展并在浏览器中得到支持，Cloudinary 将非常适合利用这一点，因为它们会为当前浏览器提供最佳的图像格式——这对图像性能来说是巨大的优势。
Ire Aderinokun 撰写了一篇很棒的文章，使用循环，以及我们何时可以考虑用其他方法（例如 .map() 和 .filter()）替换它。我特别喜欢她在文章中说的这番话。
正如我之前提到的，循环对于很多情况来说都是一个很棒的工具，这些新方法的存在并不意味着循环就不应该被使用。
我认为这些方法很棒，因为它们提供的代码在某种程度上是自说明的。当我们使用 filter() 方法而不是 for 循环时，更容易在一开始就理解逻辑的目的是什么。
但是，这些方法有非常具体的用例，如果它们没有被充分利用，可能会过度或不足。一个例子是 map() 方法，它在技术上可以用来替换几乎任何任意循环。如果在我们的第一个例子中，我们只想修改原始的 articles 数组，而不是创建一个新的、修改后的、amazingArticles 数组，使用这种方法将是不必要的。重要的是使用适合每种情况的方法，以确保我们没有过度或不足。
如果你有兴趣更深入地研究这个主题，Adan Giese 最近撰写了一篇关于 .filter() 方法的很棒的文章，绝对值得一看。哦，说到很多不同的方法来处理循环，Chris 编制了一个关于循环遍历 querySelectorAll NodeList 的选项列表，其中 forEach 只是众多选项之一。
这是一个由 Das Surma 制作的精彩演讲，他探讨了 Houdini 是什么，以及它有多少在浏览器中实现。如果你不熟悉它，Houdini 是一系列技术和 API，它让开发者能够以基本的方式访问 CSS 属性的工作原理。查看Ana Tudor 对其对动画的影响的深入研究，以获得一些在实践中的精彩示例。
我特别喜欢这个视频的一点是 Das 提到了CSS Paint API，它允许你使用 CSS 做很多奇怪的事情，比如创建“方圆形”形状，以及改变边框的工作方式。它看起来非常强大，它应该在不久的将来赋予我们超能力。Ruth John 在今年早些时候撰写了关于该主题的这篇深入概述，也值得一读。
当你需要在你的界面中添加图标时，整个过程真的很糟糕。“我应该使用所有这些默认的 Bootstrap 图标吗？也许我只会像往常一样使用相同的 Google Material 图标？”
在选择图标集时，一些重要但经常被忽视的事项包括图标的大小、样式、一致性和数量。找到只涵盖你所需用例的一半的图标是令人沮丧的。
我们也一直在经历这种沮丧，并决定做些什么。这最终导致了 Streamline 图标集的创建。
现在，Streamline 3.0 版本包含了 30,000 个图标，有三种不同的粗细，类似于字体系列。有大量选项可以为你的任何界面选择完美的图标，无论是大型 Web 应用程序、文档还是营销网站。
这个平台非常适合 2 人到 200 人的团队——并为每位员工提供相同的透明度水平。
每个项目管理工具都试图做同样重要的事情：让团队保持联系，按时完成任务，并在截止日期前完成重要工作。但市场越来越拥挤，这是有充分理由的——似乎没有哪个平台能够真正理解人们需要看到什么，以及如何显示这些信息，以便它们既可操作/相关又具有上下文。
这就是为什么monday.com 值得一试。该平台基于一个简单而强大的理念：作为人类，我们喜欢感觉自己在为一个更大的共同目标贡献力量——这种理念有时会在我们专注于完成工作的细节时迷失在混乱之中。因此，项目会被放到任务板（可以将其视为数字白板）上，每个人都可以看到其他任何为一组任务做出贡献的人。这种透明度打破了团队之间导致沟通错误和代价高昂的项目错误的隔阂——这是一种美丽而简单的方式，将人们与推动大型商业计划向前发展的流程联系起来。
JavaScript 和图像往往会成为网站速度慢的罪魁祸首，但 Harry 很清楚地解释了为什么 CSS 同样有罪，而且更难处理。
- 浏览器无法在构建渲染树之前渲染页面；
- 渲染树是 DOM 和 CSSOM 的结合结果；
- DOM 是 HTML 加上任何需要对其进行操作的阻塞 JavaScript；
- CSSOM 是所有针对 DOM 应用的 CSS 规则；
- 使用
async和defer使 JavaScript 非阻塞很容易
属性；- 使 CSS 异步要困难得多；
- 因此，要记住的一条经验法则是你的页面渲染速度只取决于你最慢的样式表。
有很多选项可以更好地处理这个问题，包括一些HTTP/2 解锁的有趣内容。
查看Šime Vidas 的总结。所有这些都很吸引人，但渐进式渲染部分尤其酷。我怀疑许多 CSS-in-JS 库可以/应该帮助以这种方式做事情。
假设你这样链接了一个样式表
<link href="mobile.css" rel="stylesheet" media="screen and (max-width: 600px)">但当页面加载时，你正在使用一个屏幕宽度为 1753 像素的桌面浏览器。浏览器应该直接跳过加载这个样式表，对吧？它没有。Thomas Steiner 解释道
事实证明，CSS 规范编写者和浏览器实现者实际上非常聪明地处理了这个问题
问题是，用户总是可以决定调整窗口大小（影响宽度、高度、纵横比），打印文档等，即使乍一看似乎是静态的（如分辨率）也会在用户将窗口从视网膜笔记本电脑屏幕移动到更大的台式机显示器时发生变化，或者用户可以拔掉鼠标，等等。
浏览器确实会做的事情（呵呵，💩）是应用一个Lowest 下载优先级。
毫无疑问，“功能性 CSS” 确实吸引了不少人。如果你对这个词不太熟悉，我相信它和“原子 CSS” 是一个意思，John Polacek 在这里给出了定义。Harry Nicholls 将它比作一个只能产生一个结果的函数（虽然我更愿意称之为纯函数或纯组件），但与根据输入完全可预测的返回值不同，它是一种只执行一项操作的样式应用。
我对这件事持两种看法。有些人说用这种方式可以提高工作效率。很棒！他们喜欢应用样式的可预测性。很棒！我能理解为什么一个不会随着时间推移而增长的微型样式表具有吸引力。