让我们将 CSS 工具库定义为一个样式表,其中包含许多可用于执行少量一次性操作的类。 比如调整边距或填充的类。 设置颜色的类。 设置特定布局属性的类。 用于调整大小的类。 工具库可能以不同的方式处理这些问题,但似乎都共享这个理念。 这本质上将样式应用到 HTML 层次而不是 CSS 层次。 样式表成为您不常接触的开发依赖项。
仅使用工具库与少量使用工具库
您可以将像下面这样的工具库用作您在 CSS 中执行的其他任何操作的附加组件。 这些项目往往有不同的理念,也许并不总是鼓励这样做,但当然,您可以随心所欲。 您可以将其称为少量使用工具库,并且最终可能会得到如下 HTML 代码
<div class="module padding-2">
<h2 class="section-header color-primary">Tweener :(</h2>
</div>
请原谅我在这里发表一些个人观点,但对我来说,这似乎是那种在当下感觉不错,但以后会后悔的事情。 而不是让所有样式都由您自己的命名类完成,样式信息现在变得分散了。 一些样式信息通过工具库类直接应用于 HTML,而一些样式则通过您自己的命名约定和 CSS 应用。
另一种选择是完全使用工具库,这样您就把所有样式信息从 CSS 完全转移到了 HTML 中。 它不再是一个分散的系统了。
我无法告诉您是否会喜欢这种完全使用工具库的方法,但从长远来看,我想您会更乐意选择全用或不用,而不是折中的方法。
这是原子 CSS 定义之一
您可以在此处阅读相关内容。 您可以将使用工具库来完成所有样式设计称为“静态”原子 CSS 的一种形式。 这与“编程”版本不同,在编程版本中,您将处理如下标记
<div class="Bd Bgc(#0280ae):h C(#0280ae) C(#fff):h P(20px)">
Lorem ipsum
</div>
然后会生成相应的 CSS。
工具库
让我列出一些我遇到的工具库,摘录一些它们关于自身的一些描述,以及一个代码示例。
Shed.css

当我厌倦了编写 CSS 后,Shed.css 就诞生了。 世界上所有的 CSS 已经都写过了,没有必要在我们的每个项目中都重新编写一遍。
目标:通过创建一组选项来消除开发人员和设计师的干扰,而不是鼓励无谓的争论,这就是 Shed 的名称来源。
<button
class="
d:i-b
f-w:700
p-x:3
p-y:.7
b-r:.4
f:2
c:white
bg:blue
t-t:u
hover/bg:blue.9
"
>
Log In
</button>
Tachyons

使用尽可能少的 CSS 创建快速加载、高度可读和 100% 响应式的界面。
<div class="mw9 center pa4 pt5-ns ph7-l">
<time class="f6 mb2 dib ttu tracked"><small>27 July, 2015</small></time>
<h3 class="f2 f1-m f-headline-l measure-narrow lh-title mv0">
<span class="bg-black-90 lh-copy white pa1 tracked-tight">
Too many tools and frameworks
</span>
</h3>
<h4 class="f3 fw1 georgia i">The definitive guide to the JavaScript tooling landscape in 2015.</h4>
</div>
Basscss

Basscss 使用清晰、人性化的命名约定,易于理解和推理,同时通过更具可扩展性和可读性的代码来加快开发时间。
<div class="flex flex-wrap items-center mt4">
<h1 class="m0">Basscss <span class="h5">v8.0.2</span></h1>
<p class="h3 mt1 mb1">Low-Level CSS Toolkit <span class="h6 bold caps">2.13 KB</span></p>
<div class="flex flex-wrap items-center mb2">
</div>
</div>
Beard

一个适合有更重要事情要做的人的 CSS 框架
Beard 最受欢迎和最具争议的功能是其辅助类。 许多人认为像 Beard 为您生成的辅助类会导致代码膨胀,并且与使用内联样式一样糟糕。 我们发现,拥有丰富的辅助类可以使您的项目更容易构建、更容易理解,并且更健壮。
<div class="main-content md-ph6 pv3 md-pv6">
<h2 class="tcg50 ft10 fw3 mb2 md-mb3">Tools</h2>
<p class="tcg50 ft5 fw3 mb4 lh2">Beard isn't packed full of every feature you might need, but it does come with a small set of mixins to make life easier.</p>
<h3 class="tcg50 ft8 fw3 mb2 md-mb3">appearance()</h3>
</div>
turretcss

turretcss 专为设计而开发,是一个样式和浏览器行为规范化框架,用于快速开发响应式和可访问的网站。
<section class="background-primary padding-vertical-xl">
<div class="container">
<h1 class="display-title color-white">Elements</h1>
<p class="lead color-white max-width-s">A guide to the use of HTML elements and turretcss's default styling definitions including buttons, figure, media, nav, and tables.</p>
</div>
</section>
Expressive CSS

- 类用于视觉样式。 标签用于语义。
- 从良好的基础 HTML 元素样式开始。
- 使用工具库类实现 CSS 的 DRY 原则。
- 类名应该一目了然。
- 响应式布局样式应该易于(甚至有趣)实现。
<section class="grid-12 pad-3-vert s-pad-0">
<div class="grid-12 pad-3-bottom">
<h3 class="h1 pad-3-vert text-light text-blue">Principles</h3>
</div>
<div class="grid-12 pad-3-bottom">
<h4 class="pad-1-bottom text-blue border-bottom marg-3-bottom">Do classes need to be ‘semantic’?</h4>
<p class="grid-12 text-center">
<span class="bgr-green text-white grid-3 s-grid-12 pad-2-vert pad-1-sides">Easy to understand</span>
<span class="grid-1 s-grid-12 pad-2-vert s-pad-1-vert pad-1-sides text-green">+</span>
<span class="bgr-green text-white grid-3 m-grid-4 s-grid-12 pad-2-vert pad-1-sides">Easy to add/remove</span>
<span class="grid-1 s-grid-12 pad-2-vert s-pad-1-vert pad-1-sides text-green">=</span>
<span class="bgr-green text-white grid-2 m-grid-3 s-grid-12 pad-2-vert pad-1-sides">Expressive</span>
</p>
</div>
</section>
Tailwind CSS

用于快速 UI 开发的实用优先 CSS 框架
这个东西还没有出现,但他们已经在 Twitter 上拥有超过 700 名粉丝。 这种事情让我相信人们确实对这类东西有强烈的需求,我们不应该忽视它。 不过,我们可以先看看他们的推广网站
<div class="constrain-md md:constrain-lg mx-auto pt-24 pb-16 px-4">
<div class="text-center border-b mb-1 pb-20">
<div class="mb-8">
<div class="pill h-20 w-20 bg-light p-3 flex-center flex-inline shadow-2 mb-5">
</div>
</div>
</div>
</div>
工具库作为样式指南
Marvel

随着 Marvel 作为产品和公司不断发展,我们面临的一个挑战是如何改进 Marvel 品牌标识并在每个产品中一致地应用它。 我们创建了这份样式指南,将其作为中心位置,在这里我们存放 UI 组件、品牌指南、品牌资产、代码片段、开发人员指南等的实时清单。
<div class="marginTopBottom-l textAlign-center breakPointM-marginTop-m breakPointM-textAlign-left breakPointS-marginTopBottom-xl">
<h2 class="fontSize-xxxl">Aspect Ratio</h2>
</div>
Solid

Solid 是 BuzzFeed 的 CSS 样式指南。 受 Basscss 等框架的影响,Solid 使用不可变的原子 CSS 类来快速原型设计和开发功能,提供一致的样式选项以及创建新布局和设计的灵活性,而无需编写额外的 CSS。
<div class="xs-col-12 sm-col-9 lg-col-10 sm-offset-3 lg-offset-2">
<div class="xs-col-11 xs-py3 xs-px1 xs-mx-auto xs-my2 md-my4 card">
<h1 class="xs-col-11 sm-col-10 xs-mx-auto xs-border-bottom xs-pb3 xs-mb4 sm-my4">WTF is Solid?</h1>
<div class="xs-col-11 sm-col-10 xs-mx-auto">
<section class="xs-mb6">
<h2 class="bold xs-mb2">What is Solid?</h2>
</section>
<section class="xs-mb6">
<h2 class="bold xs-mb2">Installation</h2>
<p class="xs-mb2">npm install --save bf-solid</p>
</section>
<section class="xs-mb6 xs-hide sm-block">
<h2 class="bold xs-mb2">Download</h2>
<p>
<a href="#" download="" class="button button--secondary xs-mr1 xs-mb1">Source Files</a>
</p>
</section>
</div>
</div>
</div>
这与 CSS-in-JS 的理念相关,但又有所区别
JavaScript 的潮流已强劲地转向组件。将 HTML 和 JavaScript 结合起来对很多人来说感觉很好,因此看到样式开始随之而来也就不足为奇了。而且这并非完全出于偶然。它有一些合理的论据,包括 CSS 的全局特性导致冲突和意外副作用等问题。如果您能以一种永远不会发生这种情况的方式来设置样式(这并不意味着您需要完全放弃 CSS),我承认我能理解它的吸引力。
这种在 JavaScript 层面为组件设置样式的想法似乎确实很大程度上消除了对实用程序库的需求。可能很大程度上是一种二选一的情况。
实用程序库列表不错。我构建了自己的实用程序/布局 CSS 库。概念类似,专注于简化布局。 https://blueprintcss.io
另一个值得关注的是 iotaCSS。
喜欢你文章的最后一部分。我认为原子 CSS 方法和 CSS-In-JS 之间正在趋于融合。那个统一的样式语言。今天版本的 CSS Zen Garden 是一个跨项目传递的 JSON 主题文件,用于控制字体、颜色和比例(自带网格进行搭建)。
从结构上看,我看到了使用其中一些实用程序的主要好处,但某些功能看起来非常倒退。如果您发现自己想要为几乎每个单独的 CSS 属性都使用类,那就直接使用内联样式吧(一点讽刺)。所以,只需编写良好的 CSS 和 HTML,大多数这些库将不再需要。
我完全同意 Bryan 的观点。保持简单,这样才能易于管理。
关于你的观点,这些库大多数都有基础样式表吗?我假设有,但我问这个问题是因为无知。
我知道这是一个玩笑,但值得一提的是,使用样式类,您可以获得浏览器缓存样式表的好处,并且您无需担心内联样式难以覆盖的问题。对于响应式网页设计,您可以将类用作移动优先的“基础”,然后将其与样式表结合使用,使用媒体查询处理更大的尺寸。这有助于减少样式表(或 Sass 部分)的大小,使其更易于阅读。
这个列表和所有示例都让我感到恶心!
拥有一个可以在 HTML 中调用的带有类的外部样式表是为了分离关注点。
在过去,我们直接在 HTML 中应用样式,这很糟糕,因为样式与 HTML 相关联,更改样式意味着更改 HTML 文件,随时都有可能破坏某些东西,并且您必须在 HTML 中一遍又一遍地重复自己。
如果您在 HTML 中放置类,则应避免这种紧密耦合,但如果您的类只做一件事情(mt0、padding-left-30 等),则就像您直接在 HTML 中编写样式一样,因为如果您想更改样式,例如将左侧填充设为 20 像素,您将不得不更改在 HTML 中调用的类,并且在需要更改的每个地方都必须更改!
如果您有一个名为“my-title”的类,则无需更改 HTML,只需更改类内部的样式,并且只需更改一次。
观点不错。期待对此的驳斥!
我认为,如果您正在创建和编辑一个只是纯 HTML 的网站,而不是预处理 HTML 或使用模块输出 HTML,那么我认为实用程序会成为一场噩梦,因为您必须为任何元素一遍又一遍地添加或删除类,例如可能需要该样式的长列表。
现在,如果您使用的是输出 HTML 的 HTML 预处理器或模块化系统,例如 Pug 或 Haml,并且您有正在循环或重复的项目,那么您只需编辑一行代码,这使得实用程序类非常易于维护,并且对开发人员非常有用。
我想总的来说,这取决于项目,就像大多数技术一样 :)
根据我的经验,Chris 的说法完全正确。我不会向那些无法访问模板库的人推荐这种方法。这些类型的技术只是将复杂性和逻辑转移到模板层。
话虽如此,但我很多年都没有在没有访问模板的项目上工作过,所以对我来说,这是正确的途径。
我已经使用这种方法大约 3 年了,它使生活变得简单得多。HTML 标记不那么含糊,我知道我的标记是如何显示的。使用一组规则(.p1、.p2、.p3、.p4 - 填充),您可以在整个设计中获得一致性。它更容易在运行时设置样式,响应式样式也更简单。构建小型测试也很快。
我同意其他人的观点,这些库在与模板引擎一起使用时效果最佳。能够根据文件名命名组件可以恢复一些特异性,而这种方法可能会丢失一些特异性。
如果您与团队合作,我建议使用 basscss,因为这些类非常易读且易于上手。
我发现项目规模越大,我打开 CSS 文件的次数就越少,这是一个非常好的迹象。我不担心删除任何遗留代码,因为它们只是单个类的实用程序。
不过,我的主要抱怨是它确实使您的 HTML 标记看起来有点难看。
从未见过更愚蠢的方法……哈哈……
为什么它“愚蠢”?
我也编写了自己的实用程序库,使用 SCSS 混合宏。基本上,每个实用程序类都必须具有响应式变体(例如,px-10 表示 x 轴方向的 10 像素填充)将变为 px-10、px-s-10、px-m-10、px-l-10 等,具体取决于您有多少断点。最终会产生大量的 CSS(其中大部分从未使用过)并且标记非常难看。
每当想到这些实用程序库时,我都会想到响应式更改。
我有我的辅助类,但我尽量避免使用它们。大多数情况下,我用它们进行原型设计,然后稍后切换到合适的类。
正如你所说,最终,这些库仍然包含大量未使用的 CSS。感谢你分享你的实践和想法。
@Vicente 我们在 shed.css 中有响应式类
等等。
我完全理解人们对原子 CSS 方法的抵触情绪,因为它违反了许多人认为最佳实践的内容。但是,随着我们转向构建模块化系统,实用程序类方法开始变得越来越有意义。我认为 Adam Wathan 在这篇帖子中说得最好:https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
是的,Adam Wathan 的那篇文章是唯一一篇让我认真思考基于实用程序类的 CSS 的文章。
他承认 HTML 充满了像上面示例中那样糟糕的类的这个问题,并建议了一些可以缓解此问题的方法,让您既可以获得语义类的优势,又可以获得一致的实用程序类。
本质上,他建议您将实用程序类用作更大语义模块类的构建块。但是,最简单的方法是使用 LESS,并且由于我们现在都使用 SASS,因此确实需要为每个实用程序类编写一个混合宏(LESS 允许您包含任何类,就像它是混合宏一样)。
Adam 是否也更有可能构建一个模块化、基于组件的开发周期?在那里,您将更改一两个模块中的几个类,而不是整个页面?
+1 给 Adam Watham 的文章/视频。被放到一个大型代码库中,我可以看到实用程序类是一件多么棒的事情。也就是说,像…
something:anything
这样的类名相当粗俗!个人而言,我完全同意 Adam Wathan 在文章中提出的所有观点。他清晰地解释了自己从使用“内容特定”CSS 类命名约定到最终采用“语义和功能性 CSS”组合的过程,即:从使用功能性(实用程序)类开始项目,并在需要时在此基础上构建可重用的语义组件。Matan Ingram 在上面的评论中对此话题给出了一些深刻的见解。
他的文章描述了一个每个经验丰富的 Web 前端开发人员都会经历的过程。在过去十年中,我们的开发者社区已经接受了许多前端 Web 开发的变化。我认为,持反对意见的人至少应该尝试一下这些方法。
我期待着他基于实用程序优先的 CSS 框架 https://tailwind.org.cn/ 以及这种“语义和功能性 CSS”方法的更多应用。
@Greg 它是“糟糕的”?还是仅仅不寻常?
我发现它与编写 JSX 不寻常的方式相同,也与编写
.bem__classes--for-components
的方式相同。抱歉,这将是非常主观的……太糟糕了!
恕我直言,它使 HTML 难以阅读,并且难以维护大型应用程序和大型开发团队。
@basher,我同意……在某种程度上。
如果是 JS 重前端应用程序,我想我会更倾向于看到非常小的样式表和实用程序的正确使用。我“目前”的想法是,对此有一个常识性的方法,您可以在一个地方定义颜色、字体等,为常见的事情(如边距)包含一个实用程序类(作为一个简单的示例)。然后根据需要使用 BEM 样式表来处理独特的情况,
这样,仅通过查看 HTML,您就不必在数百个 CSS 文件中搜索,或创建范围不十分严格的样式来修改特定情况下按钮的使用。我越来越认可原子/实用程序类,并且我热切地期待着 Adam (@adamwathan) 即将推出的 CSS 实用程序库!
我认为这就是 Vue.js 变得如此受欢迎的原因。它将所有内容(包括 CSS)保存在一个文件中,允许您编写常规 CSS 并保持模块化。
我已经关注基于实用程序的库几个星期了,我发现它在一个我们完全控制的单个项目上可能很有用,但那些允许用户通过 CMS 添加自己内容的项目让我觉得在这种特定情况下我们失去了对实用程序的控制。
不过,我想您也许可以通过为每个或
从 TinyMCE 编辑器等输出的内容标签设置默认类,这可能有效。
我真的很想在我的下一个项目中尝试其中一个,问题是,有这么多,我该如何选择?哈哈
感谢分享列表中的 shed.css!它在 TED.com 上运行良好。
对于那些不太热衷的人:我完全理解您最初的抵触情绪——在我实际尝试之前,我也处于同样的境地。它将使您能够更快、更一致地工作。
对于那些正在寻找类似的 css-in-js 解决方案的人,请查看 https://github.com/VinSpee/react-shed
我使用了两种方法的最佳组合——我有严格的 React 组件特定样式,但也有一组文件,其中包含一些用于经常复制的属性集的类。但与其将实用程序类放在标记中,我使用 SASS @extend 直接在主样式中使用它们。这样,所有内容都保存在一个地方,我可以查看组件样式的完整来源。
其中一些让我想起了简单的内联 CSS。如果您需要更改多个元素,这将是一件痛苦的事情。在我看来,这像是倒退。
我最喜欢的 CSS 实用程序集是 SUIT CSS。我喜欢每个包都很精简,可以单独安装,并且可以通过自定义属性进行自定义。我也喜欢它详细且自解释的类名。
我真的很喜欢 SUIT CSS——它实际上让我走上了这条道路。我发现自己尽可能地使用 SUIT 类,并且在不得不偏离它们时会感到失望。我编写了许多 SUIT 组件,并将其发布并在我的项目中重复使用。最终,我几乎将所有内容都使用了实用程序类,并决定采用完整的实用程序类路线。
然后我发现一遍又一遍地编写冗长的实用程序类名很麻烦,但我发现
tachyons
有点过于简洁且难以解析。在 TED 的一次前端聚会上,我们决定提出一个满足我们需求的语法——可靠、可预测且简短。
shed.css 就是结果。我们力求尽可能缩短 css 属性。如果发生冲突,则“更常使用(这完全是轶事)”的属性将获得更短的别名。这意味着
我们发现生产力的提高超过了在习惯它们时学习成本的损失。
如果允许我选择,我绝不会选择它!
许多这些原子 CSS 实用程序库都非常分散,以至于类名变成了 CSS 的一种新的速记语法,因此您必须再次学习 CSS,方法是学习各种属性-值对的所有速记。而且,长长的、几乎无法解读的类名列表既不美观也不利于开发人员——除非您是实用程序库本身的开发人员。添加响应式设计,您至少要将类的数量增加三倍。
前面提到的文章 提出一个有趣的想法:实用程序优先的 CSS,您从实用程序类开始,并在需要时创建 OOCSS 抽象。
一些 CSS-in-JS 解决方案(如 Styletron)在后台使用原子类名,但巧妙地抽象化,因此开发人员根本不需要使用类名。
Chris,我几乎探索了您在这里提到的每个库。我最喜欢的可能是 Tachyons(主要是由于其社区和早期采用),但我想请问:您是否探索过 Elm?如果您没有阅读很多关于它的内容,这里有一个很好的 资源。谢谢!
在使用或考虑使用 CSS 实用程序库时,您正在处理哪种类型的项目?正如一些人提到的,这在模块化、基于组件的开发方法中似乎更有用。
您认为这如何在糟糕的电子商务平台(Hybris、Demandware 等)中为更大的开发团队工作?
我目前的方法是使用 BEM 为单个元素和组件设置样式(即使我编写 css-in-js,我仍然使用 BEM 的命名约定)。
如果是 css-in-js,我会将所有样式放在组件的 .js 文件中,如果没有 .js 技巧,我只需创建一个与组件对应的单个“类似 css”文件,例如“user-card.sss”。
这样,如果我需要更改组件中的任何内容,总有一个我需要去的地方。
另一方面,我根据需要定义实用程序类以用于元素之间的布局和间距。
我在两年前就意识到了对功能/实用程序库的需求,并且我开始开发自己的库,并在项目之后项目中逐渐完善它。
这里提供的一些示例很极端,例如:
<h2 class="tcg50 ft10 fw3 mb2 md-mb3">Tools</h2>
。类不必晦涩难懂。编写 marge-bottom-xl 而不是 mb-xl 不会对大小造成太大影响,但会对可读性产生很大影响。我计划很快开源我的实用程序。总的来说,我们确实需要实用程序类。解决 CSS 问题的关键是编写更少的/抽象化更多的 CSS。
根据我的经验,实用程序类总是带来比预期更多的麻烦。
在响应式网站中,实用程序类往往会被覆盖得比应有的次数多。它带来了许多关于工作流程的问题,我同意它有足够的内容可以讨论,但是,在现实生活中,这些实用程序类通常会带来更多限制而不是其他任何东西。并且像这里很多人一样,我宁愿很好地组织我的 CSS,而不是用非语义类来轰炸我的 HTML,这会使维护在我看来变得更加困难。
Adam 的文章很有趣,但我发现他在谈论自己所做的转变时表达得有点轻描淡写。 “与内容无关的组件”本身没有错,而这在他看来是非常主观的。顺便说一句,他通过用实用程序类建立一个完整的 CSS 库难道不是在做同样的事情吗?例如:
.mar-r-sm {margin-right: 1rem;}
。我完全不相信他的论点,即使它写得很好,并且一些观点很容易引发讨论。也许有人已经提到了这一点,但是使用实用程序类的做法扩展性并不好,或者从长远来看难以维护。换句话说,如果我看到一个 HTML 元素有二十个 CSS 类,我会感到非常恐惧。
对我来说最有效的策略是
1) 使用预处理器
2) 将我的实用程序类编写为 mixin
3) 利用这些 mixin,我可以创建一目了然的类。使用 SMACSS、BEM 或其他一些命名约定。
这里有人使用过类似的策略吗?我很想知道!
实际上,如果你的团队很大,这样做非常明智。
我们最近重做了巨大的网站。我们希望减少对一次性CSS文件和页面内CSS的需求,所以我们让基础CSS变得简洁易懂,并且易于阅读,方便记忆。
像
<h2 class="uppercase pad-top condensed">
这样的代码,让你拥有很大的灵活性,而无需学习一门全新的语言。而且你几乎能准确地知道这个标题会是什么样子。对于这个网站,我几乎没有做任何额外的CSS,并且团队的效率比以前到处都是随意样式时高得多。
不过,当需要加入新的团队成员时,他们现在需要学习所选系统中使用的所有实用程序类名称。
当然,很容易理解“uppercase pad-top condensed”的作用。但一个人怎么知道可以这样用呢?在CSS中已经知道如何改变h2的外观了——如果正确地作用域化和模块化,任何更改都不应该产生不良影响。
我并不反对实用程序类,但我真的不明白,这种类型的实用程序类除了增加新开发人员的培训/入职要求之外还能做什么。他们已经了解常规CSS以及如何使用它。
解决方法是不是应该改进CSS组件的模块化/作用域,以防止“随意样式”,而不是添加一大堆需要记忆的新类呢?
@Pete 你没有考虑到事情的另一面——在“普通”CSS情况下引入一个新的开发人员,需要他们学习
你选择的CSS命名方案
CSS文件结构
在CSS中创建新组件的规则
你的模板系统
你所有的CSS抽象
你所有模板化的“组件”抽象
以我的经验,对于一个新的开发人员来说,弄清楚
c:black f:2 t-t:u p:1
的作用比深入代码试图确定.banner > .banner__title.headline--primary
的作用要容易得多。@Vince说的对。
@Pete:一个新的团队成员要么必须学习实用程序类,要么浏览庞大的CSS代码库,并尝试弄清楚nav-menu-wrapper与nav-menu和nav-menu-container相比有什么作用。如果你尝试一下,你会发现前者简单得多。
重点在于——而且我认为很多怀疑都是因为这一点——有一种通用的方法为元素添加边距,确保一旦开发人员了解了该实用程序类(或类混合)的存在,就可以避免前端开发人员在CSS超过一定阈值时倾向于做的大量代码重复。仅仅因为从人的角度来看,不可能遍历项目并动态分析/抽象类。
我作为工作的一部分审查了很多代码,我总是看到重复出现的模式、不必要的CSS属性以及可以抽象化的东西。
功能性CSS和实用程序库一劳永逸地解决了这个问题。
7-8年前HTML的语义化是CSS的圣杯,现在已经被丰富/结构化数据(JSON-LD、微格式等)一劳永逸地解决了https://developers.google.com/search/docs/guides/intro-structured-data。
是否讨论过这些较长类名的缩小问题?由于我们缩小了CSS和JS,如果预处理器扫描HTML,找到这些长串的类名,在生产HTML文件中创建一个缩小的名称,以及将创建的缩小类(带样式)添加到缩小的CSS中,会怎么样?我猜我们也可以从缩小的CSS中删除未使用的样式,因为我们正在扫描HTML以查找类名。
感谢你的文章,读起来不错。
其中一些框架/库看起来相当不错,我需要尝试几个,看看它们配合得有多好。
实用程序类的实用性总是会让开发人员产生分歧,因为一些人讨厌它给标记带来的混乱,而另一些人则喜欢它带来的代码重用的模块化特性。
拥有布局信息(如宽度)以及边距/填充/定位是一件好事(只要它在断点之间有效)。
能够指定元素的宽度以及它在不同尺寸下的基本布局非常重要。
谢谢
感谢Chris分享这些内容,尤其感谢大家的评论,我的思绪一直在思考,因为我总是在项目中使用不同的方法,一直在寻找一个、唯一一个、独特且最终最实用的样式方法。这篇阅读让我想到一个相关的问题:这里有人知道可以从CSS文件或文件中删除未使用的CSS类的工具吗?我的意思是,给定一组html文件,它检查CSS文件并删除你在任何一个文件中都不使用的类?
是的,让我们稍微等待一下,看看web组件是否得到广泛支持(或者现在开始使用它们,并忍受一些怪癖),编写常规CSS并停止这种胡闹。或者在此期间使用BEM与Stylus/SASS。
一些无稽之谈来自不了解如何为CSS使用正确的命名约定/结构的人。这可能是因为他们的后端背景,或者只是盲目地接受“最佳实践”,而没有在一个大型项目中进行测试。
根据我的经验,BEM适合大多数目的。我的意思是,如果你正确地计划你的项目并首先开发所有组件,那么CSS的大小/覆盖/等都不是问题。大多数团队都是从逐页开发开始,而没有分析所有设计文件、计划结构并首先开发组件。
每个组件都应该有自己的文件,并且独立于结构。这是大多数编码人员出错的难点。
最初几周,可见的进展会很少。之后,开发就会快速发展。最初几周对希望看到“某些东西”的产品经理和客户来说压力很大。
仅仅为了抽象化而使用这些类
c:black f:2 t-t:u p:1
简直是疯狂。我必须学习CSS内部的另一种“语言”才能理解它们的意思。你为什么要这样做?将这个项目交给另一个团队,他们将不得不重新学习一遍。这毫无意义。
编写良好的CSS/HTML并构建合理的结构。
@Zeno:我怀疑你是否接触过拥有实际产品负责人和设计师的真实大型项目,那样你就会知道,期望能够完全预先完成的设计,并在此基础上进行你提到的分析是不现实的。很遗憾,但这是事实。使用功能性CSS,你可以变得真正敏捷、灵活和高效。
@George 你的意思是,如果你把普通CSS用对了,它也能像功能性CSS一样真正敏捷和灵活吗?
令人悲伤的事实是,人们抱怨CSS的缺点,并试图让它按照他们期望的方式工作,而不是利用它的优势。如果你避免级联和特异性,你几乎摧毁了CSS的大部分益处。我不知道你如何构建你的项目,但我希望我的组件使用级联,并且可能根据它们在DOM中的位置看起来有所不同。
@Zeno,我理解你对这种方法的感受,但请了解其背后的原因并非“我讨厌CSS,我不理解它,我将采取捷径”。
以Tachyons为例。Adam Morse是它背后的开发者,他是一位设计师。他对CSS非常精通。他做了很多思考和研究。关于CSS架构,关于设计系统。
他与你想象的相反,他不是尽可能远离CSS的人。
这是Adam撰写的一篇关于CSS可扩展性的精彩文章。这篇文章实际上让我理解了它,并让我准备好尝试这种方法。
值得一读,即使你从未打算使用实用程序类!
http://mrmrs.github.io/writing/2016/03/24/scalable-css/
它并非“仅仅为了抽象化”,将它如此看待是不公平的描述。实际上,这种效果消除了CSS层面的抽象。它处理具体的表现特征,而不是业务或特定于领域的思想。
你不再需要在CSS和标记中处理抽象,而只需要在标记中处理。你的CSS变成了一组约束,而不是间接的附加层。
就命名而言,这些缩写与CSS属性非常相似。我们选择缩写而不是完整写法,因为从长远来看,生产力和速度的提高超过了短期学习曲线的代价。
我在另一个帖子中回应了类似的担忧,但它值得重复。
在“普通”CSS情况下引入一个新的开发人员,需要他们学习
你选择的CSS命名方案
CSS文件结构
在CSS中创建新组件的规则
你的模板系统
你所有的CSS“布局”抽象
你所有模板化的“组件”抽象
以我的经验,对于一个新的开发人员来说,弄清楚c:black f:2 t-t:u p:1的作用比深入代码试图确定.headline–primary的作用要容易得多。
真的吗?我可以使用带有headline-primary类的元素进行检查,并查看它的值。你将如何检查使用你的快捷类名的元素?你永远不会知道最初的意图是什么,没有继承,所有内容都直接来自这些“功能性”(我更愿意称之为内联CSS)类。
那为什么不直接再写内联样式呢?我永远不会使用这样的实用程序库。
虽然看起来类似于内联样式,但实用程序类在实现上**非常不同**。
内联样式的缺点包括
不支持悬停状态、媒体查询、伪元素
极其具体,也就是说你无法覆盖它们
实用程序类并非如此。这里有一个关于Tachyons GitHub 问题上差异的精彩讨论:https://github.com/tachyons-css/tachyons/issues/12#issuecomment-59828967
Chris,总结得非常好!
如果有人对使用Tachyons重构和维护代码库的真实体验(我自己的)感兴趣,我在此处写了一篇关于它的详细文章:https://hackernoon.com/full-re-write-with-tachyons-and-functional-css-a-case-study-part-1-635ccb5fb00b
你会注意到,我最初对这个概念的感觉——就像我们大多数人一样——是厌恶。我发现这篇帖子的大多数评论都与我们在实际尝试在一个项目中使用实用程序类并看到好处之前所想的完全一致,这很有趣。
记录在案的是,我一个月前加入了一家新公司。在过去的4周里,我一直在熟悉CSS代码库,并且我还没有完全自信地了解如何使用/扩展它。
CSS 由非常聪明的开发人员组织得非常好。这不是重点。重点在于学习新的词汇、新的系统所带来的巨大认知负担。这令人难以招架。
我发现自己将新的CSS范围限定到一个特定的类,这样在学习系统时就不会“破坏”其他页面。我在我的第一个任务中立即产生了技术债务。:/
对于像Tachyons这样的东西,我坚信可以在3-4天内让任何人上手。
如果你有兴趣,我最近做了一个关于Tachyons的直播讨论。这是链接https://youtu.be/6sOoCWowwHo,这里还有一份总结讨论内容的文档,供那些想要快速回顾的人参考:https://hackmd.io/s/Byc3176wW
很高兴看到这种前端样式方法在最近几个月里发展速度越来越快。作为一名开发人员,我最初在CSS中使用语义类名。在我转向函数式CSS和实用程序类后,我就再也没有回头。它将开发时间缩短了不止一倍。
事实上,我编写了自己的高度可配置的Sass框架,用于生成函数式CSS类
https://github.com/watchtowerdigital/scarab-carapace
这是在我意识到自己每个项目都在一遍遍地编写相同的实用程序类之后构建的。现在,我几乎不写任何CSS了。只需在scarab-carapace中配置我的断点、排版、尺寸、颜色等,它就会以编程方式构建一个函数式CSS样式表。
此外,scarab-carapace 还与另一个工具scarab-styleguide(https://github.com/watchtowerdigital/scarab-styleguide) 结合,根据样式表配置自动生成前端样式指南(例如:http://scarab-styleguide.surge.sh)。