当 Chris 撰写他的 Boilerform 想法时，我其实已经开始思考一个新项目了。我刚刚决定结束我的 前端样板 项目，并想要一些新的东西来思考。Chris 的想法立即引起了我的共鸣，所以我像一只兴奋的小狗一样热情地参与了评论。这种兴奋让我着手构建 Boilerform 的初始版本，你可以在 这里查看。
我最初兴奋的原因是我对表单有一种“罪恶的快乐”。在不同的工作中，我曾以非常高的强度处理过表单，并从中学习了很多关于表单的知识。这包括构建动态表单生成器到为 Harley-Davidson® 网站平台提供高级垃圾邮件防护。每个不同的项目都让我看到了流程的前端和后端。这些项目中的每一个也都在逐渐磨损我对于快速、懒惰地实现表单的容忍度，因为我看到了这种做法在规模化后的灾难性后果。
但是，嘿，我们不是坏人。表单确实很糟糕。尽管现在好了一些：每个浏览器对表单的处理方式略有不同。例如，查看来自各种浏览器和操作系统的这些选择菜单。没有一个看起来是一样的。
由于这些不一致性，很容易理解为什么开发人员会放弃深入挖掘，或者只是快速使用 Bootstrap 并完成它。此外，根据我的经验，小型表单（例如联系表单）的设计通常会被留到项目后期，这时大部分积极的势头已经过去了。我甚至犯过在网站发布前一天才构建联系表单的错误。😬
显然，有机会让使用表单的过程（至少在前端）变得更好，我无法抗拒改进它的诱惑！
规划
我坐下来思考在使用表单时有哪些痛点，以及作为表单用户哪些东西让我感到恼火。我决定，作为一名开发人员，我讨厌为表单设置样式。作为用户，糟糕的表单字段会让我感到恼火。
后者的一个例子是电子邮件字段。现在，如果你尝试在 iOS 设备上填写电子邮件字段，你会遇到浏览器将第一个字母大写这个恼人的特性，因为它将其视为句子。要停止这种行为，只需在你的字段中添加autocapitalize="none"即可。我知道这不是一个普遍的知识，因为我很少看到它被使用，但它是一个快速且能对用户产生积极影响的解决方案。
我希望将这些小技巧直接融入 Boilerform，以帮助开发人员让用户的体验更轻松。创建前端样板或框架不仅仅是关于样式和美观。它还关乎与他人分享你积累的经验，以整体改善行业环境。
规范
我需要考虑在初始发布时，我希望 Boilerform 作为最小可行产品实现哪些功能。我提出了以下规则
- 它必须与大多数前端兼容
- 它必须有良好的文档
- 它必须轻量级
- 任何人都应该能够将 CDN 链接放到他们的
<head>中，并使其正常工作 - 任何人也应该能够扩展源代码以用于自己的项目
- 它不应该过于武断
为了实现这些目标，我需要做出一些技术决策。我决定选择一个低门槛的设置。具体如下：
- Sass 驱动的 CSS
- BEM
- 纯 HTML
- 一个基本的编译设置
我还将注意力集中在示例上。CodePen 是自然之选，因为它们可以很好地嵌入。用户还可以复制它们并自己尝试。
最后一个决定是推出一个 模式库，将组件分解成小块。这在几个方面帮助了我。主要体现在组织方面——但它也帮助我以一种零散的方式构建 Boilerform，因为我是在晚上利用空闲时间进行开发的。
我有了计划和技术栈，于是开始动手。
保持简单
像这样的项目很容易失控，因此，为 Boilerform 制定一些关于它是什么以及它不是什么的要点非常有用。
Boilerform 将是什么
- 它将始终是一个样板，帮助你为项目开个好头
- 它将提供关于 HTML、CSS 和 JavaScript 的高级帮助，以简化开发人员和用户的体验
- 它将力求超级轻量级，因此不会成为沉重的负担
- 它将提供可配置选项，使其灵活且易于融入大多数 Web 项目
Boilerform 将不会是什么
- 它不会是表单的灵丹妙药——它仍然需要一些工作
- 它不会像 Bootstrap 或 Foundation 那样是一个完整的框架，因为它始终是一个起点
- 它的 CSS 和 JavaScript 不会过于武断
- 它永远不会针对某个特定的框架或 Web 技术
细节
我知道你们都喜欢深入了解事物的工作原理，所以让我带你们快速浏览一下！
CSS 命名空间
我首先解决的是命名空间问题。我处理过很多不同的网站和设置，它们在 CSS 方面都存在一个共同点：冲突。考虑到这一点，我编写了一个 @mixin，将所有 CSS 包裹在一个.boilerform命名空间中。
// Source Sass
.c-button {
@include namespace() {
background: gray;
}
}
// This compiles to this with Sass:
.boilerform .c-button { background: gray; }这个 mixin 目前很简单，但它给了我们扩展的灵活性。如果我们想以后选择是否使用命名空间，我们只需要更新这个 mixin。我喜欢这种模块化。
现在，它为我们提供了安全性。没有任何东西从 Boilerform 中泄漏出来，希望任何泄漏进来都会被命名空间重置和规则处理。
带前缀的 BEM
我喜欢 BEM。几年来，它一直是我 CSS 和标记的核心。我喜欢 BEM 的一点是它可以帮助你构建小型、封装的组件。这对于像 Boilerform 这样的项目来说非常完美。
由于命名空间的存在，我可能可以安全地定位裸元素，但 BEM 不仅仅是为所有东西添加类。它赋予我和其他人自由，让我们可以编写任何我们想要的标记结构。对于其他人来说，也很容易理解代码，并了解 HTML 和 CSS 中哪些内容是相关的。
我为这个设置添加的另一件事是组件前缀。我们没有使用.input-field组件，而是使用了.c-input-field组件。我希望这样的小细节可以帮助新贡献者立即识别出什么是组件。
为糟糕的输入添加酷炫的样式
如上所述，选择菜单的样式很难设置。单选按钮和复选框也是如此。
我一直使用的一个技巧是将样式抽象到其他更友好的 HTML 元素。例如，对于<select>元素，我将它们包装在一个.c-select-field组件中，并使用兄弟元素添加一致的下拉箭头。
对于复选框和单选按钮，我会视觉上隐藏主输入，并使用相邻的<label>元素来显示状态变化。使用这种方法可以大大简化对这些控件的操作。重要的是，我们也保留了可访问性和原生事件。
简化表单：基础属性
我在上面关于电子邮件字段和大小写的示例中提到了这一点，但这并不是唯一添加的有用属性。
- 搜索字段具有
autocorrect="off"属性，以防止浏览器尝试更正拼写。我强烈建议您将此属性添加到用户输入其姓名的输入字段中。 - 数字字段设置了
min、max和step属性，以帮助进行验证。对于键盘用户来说，这也是一个很棒的功能。 - 所有字段都具有空的
name和id属性，希望能够加快连接过程。
我当然希望能够扩展这些功能，因为像这样的微调对于用户体验非常棒。
未来展望：期待您的参与
Boilerform 目前处于良好的状态，但它具有巨大的潜力。我对于其持续开发的一些想法包括：
- 引入多个 JavaScript 库集成，例如 React、Vue 和 Angular。
- 在模式库中创建一些基本表单布局。
- 创建用于样式化恼人元素（如占位符）的 Sass 混合。
- 改进可配置性。
- 添加新的元素，例如范围输入。
- 创建多语言文档。
如您所见，这是一个很大的工作量，因此如果我们能够让一些贡献者加入项目，为我们的社区创造真正有用的东西，那就太棒了。吸引具有不同专业领域和背景的贡献者将帮助我们使其尽可能多地对人们有用，从最终用户到后端开发人员。
让我们一起创造一些伟大的东西。🙂
查看项目网站或GitHub 存储库。
太棒了！Andy 干得漂亮！
谢谢！
我喜欢这个想法，但难以实现复选框。它需要在其中包含一个复选标记，不是吗？
Boilerform 的妙处在于，如果您想添加复选标记，这将非常容易。我们所做的只是规范化使用表单的过程 :)
“后者的一个例子是电子邮件字段。现在，如果您尝试在 iOS 设备上填写电子邮件字段，您会遇到浏览器将第一个字母大写这一恼人的特性，因为它将其视为句子。要停止此行为，您只需将
autocapitalize=”none”添加到您的字段中，这将停止此行为。”实际上，这里更好的解决方案是使用
<input type="email">，除了禁用自动大写之外，它还禁用自动更正并在 iOS 上显示特定于电子邮件的键盘。是的，
email属性在这里是隐含的。我相信自动大写修复也是最近才出现的。在我看来，最好为广泛的修复添加一个快速属性 :)基本上我认为这是一个好主意：所有表单都获得良好的功能、可访问性和错误管理。
但是，还有https://lawsofux.com/jakobs-law——用户希望表单在各个网站上看起来一致，而不是在不同浏览器中一致，尤其是在他们最喜欢的浏览器中。正如 Ben Dunkle 已经评论的那样，复选框不应该有复选标记吗？我也这么认为——当然它应该是橙色的，就像我 Ubuntu 操作系统中的所有复选框一样 ☺
统一某些表单元素也意味着让大多数用户感到疏远。
如上所述
但是，嘿，我们喜欢一些贡献，所以为什么不提交一个 PR 来添加一个继承的彩色复选标记呢？这将受到高度赞赏！ :)
谢谢，这绝对是需要的，尤其是在不想包含完整 Bootstrap 框架的小型项目中。
考虑为响应式导航栏创建类似的东西。
您已经确定了 MVP 的需求，但我认为您遗漏了一个关键的需求——它必须是可访问的。在它成为可访问之前，任何必须针对 WCAG 2.0 AA（当您查看国际上现行法律和法律裁决时，大多数组织都必须这样做）的组织都无法以其当前形式使用它，这意味着它不能成为一个良好的普及预测指标。您所拥有的对于可访问性来说并不差，但将其陈述并将其作为目标也是一个信号，让那些在考虑库/框架/平台之前就将可访问性作为因素的组织了解。
感谢您的反馈，Adrian。
可访问性确实非常重要，考虑到这一点，如果您发现了任何具体问题，在项目中提出问题和/或提交 PR 将受到高度赞赏。
因为 Boilerform 主要是一个重置，并且对原生功能进行了少量扩展，所以不应该有任何明显错误。但同样，如果您看到不同的情况，我们将非常感谢您的反馈。
社区已经做了一些很棒的工作来改善这方面的问题。
文档中可能缺少的一件事是一些最佳实践建议，因为在我看来，这就是我们真正能够帮助开发人员创建可访问表单的地方。
如果您确实发现自己正在记录问题，我在存储库中为可访问性创建了一个特定的标签。