一个文档化的CSS代码库是什么样子的？

在前端社区中，与JavaScript文档相关的关注很多。CSS就不是这样了。当我加入一个只有很少或没有CSS文档的项目时，我常常感到迷失。尽管CSS相对容易编写，但维护起来却相当困难。特殊性、所有东西的全局范围以及缺乏指导很容易导致不一致、代码重复和过度复杂。我很早就好奇一个真正文档化的CSS代码库是什么样子的。在这里，我将与大家分享我的经验，以及我对文档齐全的样式表的期望。。我想他们都不必处理10000多行样式表！我常常纠结于什么HTML会产生什么特定的风格。如果对所做的开发决策没有一个坚实的背景，调试工作就会增加。每分钟的WTF也呈指数级增长。很多次，我花了好几个小时来弄清楚开发人员的意图，为什么她没有用另一种方式来做，为什么这个布局看起来如此复杂。在这些\"为什么\"的问题中隐藏着许多痛苦。所以，我们开始吧！让我们检查一下CSS代码库的4大标志。。查看包管理器的依赖项列表并不能提供很多上下文，例如为什么要添加这些东西，它们具体做什么，以及我们如何使用它们。让每个人都知道为什么要引入某个库或工具是很好的。例如，假设引入第三方库只是为了解决已经过时的CSS问题。如果我们有这样的背景，我们可以做出更明智的决定。在一个项目中有时会有相当多的第三方库。你有没有花过很多时间在网上搜索每一个，弄清楚它到底是什么？要知道或跟踪每个依赖项的确切作用是一个相当大的挑战。一个文档化的代码库将包括对每个依赖项的描述。也许你可以加入一个tweet长度（140个字符）的代码注释来解释它为什么存在。这将使代码库中的任何其他人都能在为什么会有某些东西的问题上领先一步。我喜欢将这些描述添加到我@import的地方。 h3>svg>2）CSS约定导致一致、可读和明确的源代码。它们使应用程序的结构和编码样式标准化，以便您和其他人能够轻松地阅读和理解代码。了解是否有任何特定于项目的命名约定或方法（如BEM、OOCSS、SMACSS或ACSS）是很重要的。我见过这样的案例，其中应用了某些方法论原则，但所遵循的实际规则是根据相关开发人员的偏好进行修改的。因此，我们必须严格遵循方法论原则，最好将其放在一个有良好文档记录的代码库中。这就引出了CSS风格指南的更大问题。命名约定只是完整样式策略的一部分。其他部分可能是： - 代码是如何划分的？ - 文件是如何构造的？ - 属性是如何排序的？ - 如何进行评论？ - 格式化是如何完成的（缩进、规则声明）？如何将JavaScript钩子绑定到类？ - …还有更多的规则或反模式，比如嵌套深度超过3层，避免ID选择器，使用！仅对实用程序类等很重要。所有这些构成了一个完整的CSS样式指南。拥有这样一个共享的词汇表，我会考虑在一致性方面的强大优势。3）CSS架构大多数可伸缩项目在排序风格方面都遵循某种架构。在一个有良好文档记录的代码库中，应该提到项目在结构化和分段样式时所遵循的基本原则。我最初是通过观看哈里•罗伯茨（Harry Roberts）关于管理CSS项目的演讲来探索CSS架构的。哈里：CSS架构现在似乎有些流行。毫无疑问，在过去的一年左右的时间里，你听到过无数次这样的说法，而且理由充分：ui（以及构建它们的团队）正变得比以往任何时候都更大、更复杂。CSS有许多方面使它变得麻烦。它是声明性的，这意味着没有逻辑或控制流来告诉其他开发人员项目的状态或结构。它在一个全局名称空间中运行，这意味着我们会遇到冲突、泄漏样式和意外的回归。它利用继承，使一切都有点相互依赖和脆弱。最后，不可避免的特殊性模型可能会在选择器为突出性而相互竞争时引起问题。因此，他引入了一个称为ITCSS的CSS架构概念。如果你在一个规模合理的项目上工作，很可能有人已经定义了类似的原则或想法来解决这些问题。因此，在一个有良好文档记录的代码库中，我希望看到它们被写在某个地方。如果您能回答以下问题，就可以知道架构的解释是否足够好：应该在哪里添加新的样式或样式表？4）CSS组件描述和示例一个常见的模式是将逻辑模块划分为CSS组件（或根据BEM的\"块\"）。其中有些可能是可重用的，有些可能不是，但重要的是它们是我们项目的构建块。因此，在一个文档化的代码库中，描述它们应该是最重要的任务。理想情况下，您应该对它们进行排列和分组，命名它们，并在它们之间建立规则，以生成所有组件的概述。一个描述良好的CSS组件不仅包含组件的功能信息，而且还包含其他有价值的英特尔示例HTML标记和它要使用的上下文。再往前走一步，就会提到模式库的问题。模式库是可重用组件的集合，可以一起用于创建网站。随着模块化、基于组件的体系结构成为一种趋势，它们可以带来巨大的价值。模式库的目标是显示可以用现有的模式（组件）构建什么。但是，让我们来看看在每个模式旁边还可以显示哪些附加信息。vitalyfriedman就如何将模式库提升到下一个级别给出了一个很好的总结。他指出，专注于组件还不够好：模式库的一个主要问题是，虽然它们提供了组件的概述，但它们通常会留下很多可供解释的空间。组件可以以多种方式组合，一致和不一致。很高兴能看到哪些按钮变体和图标可用，哪些表格和定价标签可用，但是如果您需要设计或构建一个同时包含所有这些组件的界面，或者库中还不存在的另一个界面，该怎么办？单靠模块列表无法传达任何上下文或模块应（或不应）如何使用的任何细节。基于Vitaly的帖子和Brad Frost对模式库中模式的剖析，我可以想象，尽管通常有唯一的名称，但我们的每个模式（组件）都可能有一些想法，代码示例和组件用途的描述。基本（Basic）：标记或类别：为组件分配的标记或类别。开发人员可以用\"正在使用\"、\"需要重构\"等标记他们的组件。响应预览：使用生产中使用的实际代码片段，对组件进行真实的、可调整大小的预览。或者，只是一个屏幕截图。版本控制和遗留问题，涉及或负责的团队成员：在更大的团队中，组件家族的所有权以及哪些团队成员一直在积极开发这些组件，这对维护和进一步开发非常有帮助。…下面是一些更高级的：性能影响：有时CSS也可能很重。性能指标或\"警告标志\"部分，不仅概述了性能影响，还概述了错误使用模式时的常见事故。辅助功能含义：辅助功能要求指标。某些组件可能需要更多的工作来维护可访问性，特别是当它们与其他组件交互时。相关模式：快速概述相关组件或给定组件所属的组件系列。可以解释何时使用组件，何时不使用，以及为什么。Fallback and print previews。，帮助团队建立共同的词汇表。它是高效CSS设计和开发的先决条件。而且，根据我的经验，这必然会带来更好的表现。我坚信，这些都是专业执行项目的标志。如果您有想法，请随时在下面的评论中添加它们，这样我们就可以更接近于更好的文档实践 - 标记或类别：为组件分配的标记或类别。开发人员可以用\"正在使用\"、\"需要重构\"等标记他们的组件。 - 响应预览：使用生产中使用的实际代码片段，对组件进行真实的、可调整大小的预览。或者，只是一个屏幕截图。 - 版本控制和遗留问题，涉及或负责的团队成员：在更大的团队中，组件家族的所有权以及哪些团队成员一直在积极开发这些组件，这对维护和进一步开发非常有帮助。 - …下面是一些更高级的：性能影响：有时CSS也可能很重。性能指标或\"警告标志\"部分，不仅概述了性能影响，还概述了错误使用模式时的常见事故。辅助功能含义：辅助功能要求指标。某些组件可能需要更多的工作来维护可访问性，特别是当它们与其他组件交互时。相关模式：快速概述相关组件或给定组件所属的组件系列。可以解释何时使用组件，何时不使用，以及为什么。Fallback and print previews。，帮助团队建立共同的词汇表。它是高效CSS设计和开发的先决条件。而且，根据我的经验，这必然会带来更好的表现。我坚信，这些都是专业执行项目的标志。如果您有想法，请随时在下面的评论中添加它们，这样我们就可以更接近于更好的文档实践 - 性能影响：有时CSS也可能很重。性能指标或\"警告标志\"部分，不仅概述了性能影响，还概述了错误使用模式时的常见事故。 - 辅助功能含义：辅助功能要求指标。某些组件可能需要更多的工作来维护可访问性，特别是当它们与其他组件交互时。 - 相关模式：快速概述相关组件或给定组件所属的组件系列。可以解释何时使用组件，何时不使用，以及为什么。 - Fallback and print previews。 - ，帮助团队建立共同的词汇表。它是高效CSS设计和开发的先决条件。而且，根据我的经验，这必然会带来更好的表现。我坚信，这些都是专业执行项目的标志。如果您有想法，请随时在下面的评论中添加它们，这样我们就可以更接近于更好的文档实践

一个文档化的CSS代码库是什么样子的？

admin_action_{$_REQUEST[‘action’]}

admin_footer-{$GLOBALS[‘hook_suffix’]}

customize_save_{$this->id_data[‘base’]}

customize_value_{$this->id_data[‘base’]}

get_comment_author_url

network_admin_edit_{$_GET[‘action’]}

network_sites_updated_message_{$_GET[‘updated’]}

pre_wp_is_site_initialized

WordPress 的SEO 教学：如何在网站中加入关键字（Meta Keywords）与Meta 描述（Meta Description）？

谷歌的SEO是什么