Nicolas Gallagher (@necolas) 是 Twitter 的前端开发人员,曾参与过 HTML5 Boilerplate 和 Normalize.css 等大型项目。 Nicolas 谈到了质疑前端 Web 开发中的一些旧有假设。
这些是我从他在旧金山 W3Conf 上的演讲中记录的笔记,作为 这个直播博客系列的一部分。
"最佳实践"并非"绝对真理"。
Nicolas 在成为 Web 开发人员之前,曾在人类学领域学习了更长的时间。
**赫拉克利特(公元前 535 年)**:哲学家。 对人类的蔑视。 苦难是常态。 那个时代的悲伤基努。 死于用牛粪涂抹自己并躺在阳光下。 主要观点:一切都是幻觉。 "你不能两次踏入同一条河流,因为有新鲜的水流向你。"
**德谟克利特(公元前 460 年)**:同样对人类怀有蔑视。 "笑口常开"的哲学家。 世界上第一个巨魔。 质量和能量守恒。 原子。
这些理念被搁置了数千年,直到科学再次发现它们。 柏拉图和亚里士多德拒绝了这些理念,但你不能责怪他们。 这些理念在时机成熟时又回来了。
Web 开发也是一个不断变化的语境世界。 Nicolas 继续怀疑那些即使在六个月前也成立的假设。
为 CSS1 添加 HTML 类属性是为了"增强对元素控制的粒度"。
CSS Zen Garden(2003) 只有一个 HTML 页面,但有许多不同的设计,其中只有 CSS 发生了变化。
来自真实人物和真实规范的真实陈述
"不要使用无意义的类名"。
"你的 HTML 就像钻石一样永恒。"
"鼓励作者使用描述内容本质的类属性值,而不是描述内容预期呈现方式的值。"
这些让 Nicolas 感到疯狂。 他曾经用零个类设计过自己的博客。 创建(所谓的"完美语义")但进行更改变得不切实际。 难以阅读。 难以理解。 难以进行样式更改。
这是更真实的
"类名是为我们而设,不是为机器而设。" — @necolas #w3conf
— Carwin Young (@carwin) 2013 年 2 月 22 日
不过,确实存在“难看”的 HTML 类名的概念。 这种类名目前很流行:hyphenated-lowercase-4-life
。 例如
.button { }
.button-group {}
.button-primary {}
.button-group-item {}
这种东西并不能传达太多信息。 与这些"难看"的类名形成对比
.Button {}
.ButtonGroup {}
.Button--primary {}
.ButtonGroup-item {}
这种命名约定传达的信息要多得多。 双破折号是修饰符。 单破折号是组件子项。 这些并不难看。 它们可能目前并不流行,但也许将来会流行起来。 这种特定模式来自俄罗斯搜索引擎 Yandex。
#W3Conf 因此在 C 的匈牙利命名法之后,@necolas 建议使用俄罗斯命名法(来自 Yandex)用于 CSS 类
— Kevin Marks (@kevinmarks) 2013 年 2 月 22 日
注意:关于类名使用哪些字符可能存在一些历史原因
#w3conf 事实上,我们避免在类(和 ID)名称中使用下划线的历史原因是:developer.mozilla.org/en-US/docs/Und…
— Eric A. Meyer (@meyerweb) 2013 年 2 月 22 日
另一个旧的最佳实践是:"不要使用额外的元素"。 Nicolas 深入研究了伪元素的世界,以避免使用额外的元素。 回想起来,这使得理解发生了什么变得更加困难。 并不是说"垃圾"标记很不错,但像 Web Components 这样的东西更有意义。
CSS 是错误的工具,它无法对内容/设计施加结构。 HTML 用于此目的。 Web Components 使我们能够使用正确的工具,而无需担心"垃圾"标记。
那么,使用 Nicolas 使用的下划线/破折号类 BEM 命名约定是否明智呢?
我认为答案和以往一样......"视情况而定"
@dimitrie 这取决于你,下划线可能会导致问题,这可能是 Yandex 使用单破折号和双破折号来区分元素和修饰符的原因。
你是否选择采用 BEM 作为命名系统,取决于你/你的团队。
我认为这里的重点是,将命名系统作为样式指南的一部分是个好主意。 这可能需要一些时间来适应,但一旦你将其融入你的文档中,你将节省大量时间来思考如何命名你的类。
我刚开始计划在新项目中使用 BEM 命名约定——我知道一开始会很痛苦,但最终会有很大的收获。 SASS 一开始也很痛苦,但我现在真的离不开它了。
除非你的支持浏览器**低于** IE 6、Netscape 7、Navigator 5 或 Opera 6;否则使用下划线是完全安全的。 你是否要使用它们取决于你。
(阅读:"历史")
正如你所说,“绝对真理”并不存在,但始终适合遵循(继续)一些常用的程序。
好话题,请继续...
听起来像一个很棒的演讲。 我认为我们需要重新审视"最佳实践"。
我浏览了 Eric Meyer 关于下划线的链接。 如果你阅读它,你会发现,在 **Netscape Navigator 4.x** 和 **Opera 3.x 到 5.x** 中,在 ID/类名中使用下划线不起作用。
如果是在 1998 年,我可以理解在 ID/类名中不使用下划线,但现在是 2013 年了。
我更喜欢在命名类时使用连字符。
尽管我之前曾经使用过下划线来表示模块组件,或者 Yandex 所称的元素。 如果我的笔记中有一个标题,我可能会使用这样的类。
我也能想到另一种命名约定,例如
Web 应用程序的日益普及正在改变 Web 开发世界中的许多最佳实践。 OOCSS 是从 Web 应用程序中发展而来的,从 OOCSS 开始,我们开始质疑之前使用的最佳实践。 现在,我们对较少的语义(Web 应用程序不会被搜索引擎读取)、更多的类、更模糊的属性(data-)和更多标记感到满意。
我认为很明显,Web 开发有两个分支——一个是网站,另一个是 Web 应用程序。 它们使用相同的工具,但需求完全不同。 因此,围绕两者展开的最佳实践需要针对各自的情况进行调整。
许多人,包括我自己,实际上想知道,文档格式(HTML 的本质)是否是创建 Web 应用程序的最佳工具。 这是我们拥有的工具,但它是否是正确的工具? 这是一个需要挑战的另一个假设——即网页最终必须构建在 HTML、CSS 和 JavaScript 之上。 浏览器中是否有空间容纳其他形式的本地执行代码?
我不认为有必要放弃 HTML 文档作为基本容器。 它并不局限于 HTML、CSS 和 JavaScript。 我还使用 PHP、MySQL,并且随着学习,我还会使用 nodeJS、IndexDB、Python、Ruby 和其他工具。
对于基于 Web 的内容,无论是应用程序还是静态文档,拥有一个通用的文档容器,这使得 Web 对浏览器供应商和用户来说更具可操作性。 它并不限制与网站进行交互的各种方式。
我认为,仅仅因为你从笔记本电脑切换到智能手机,就必须使用由少数几家大型公司封存的应用程序,这种做法必须改变。 我还认为,新型和即将出现的 SOC 将使小型便携式设备在处理能力方面赶上来。
无论网站还是 Web 应用程序,OOCSS 都适合两者,并且在两者中都能很好地发挥作用。 正如 Necolas 所说:类名是为开发人员而设,不是为机器而设。 OOCSS 仅仅是一种让类名对我们更有效的方式。
有时我认为面向对象的 CSS 是一个糟糕的名称,因为它代表的不是它所代表的。 它暗示了一种全新的语言,或者至少是一种全新的 CSS 运用方法;但它既不是前者,也不是后者,它对我们认为的最佳实践提出了挑战,而实际上是有效的。
Web 应用程序和网站并没有真正出现分歧。 当然,Web 应用程序的概念是在过去几年中出现的,但它并不是什么新鲜事物,而且它与两者之间并没有完全断裂。 网站和应用程序都在一起变化,而且变化方式相同。
其理念是,Web 已经发展成熟,但我们的最佳实践却基本上没有改变。
Nicole Sullivan 的目标不是重新发明轮子,她发现我们的最佳实践并没有产生最佳结果,而且她发现了一种没有记录但效果很好的模式。
最后,HTML/CSS/JS 现在正在超越浏览器,它们是极其强大的工具,在短期内不会被取代(而且可能永远不应该被取代)。
@JamesKyle 谢谢 :D 这是最清晰的答案
人们似乎完全不理解 BEM 方法论,它不是关于下划线、破折号或驼峰式命名法。它是 **块-元素-修饰符**,它关于为您的类名赋予结构,以便整个项目或组织都能理解。
我使用的系统是
使用 CSS 预处理器的示例
生成的 CSS 输出将是
其标记将是
您可以将下划线和破折号替换成您想要的任何东西,重要的是构建一个系统,帮助您以一种有助于减少工作量的方式组织您的样式。我优化了我的系统,以便我无需始终编写很长的类名(它们会很快累积起来)。
我对类命名的看法是使用部分语义,部分通用术语。例如
#nav-facebook{float:right;margin:0;padding:5px 20px 5px 0;}
#logo-container{position:relative;top: 18px;max-width: 550px;}
#logo{width: 100%;z-index: 0;}
#logo-position-fix {max-width:1080px;margin:auto;}
.headerbg{background:url(images/soul-sanctuary-header-bg.jpg) center center #000;height:100%;}
拥有一个可以遵循的系统,以及一个如果与其他程序员一起工作可以供其他人阅读的系统很好,但我认为,如果您花费太多时间考虑应该如何命名一个类或 ID,您将永远无法完成任何事情。如果您的系统易于理解且高效。那就是最主要的事情。
这就是重点,想出一个适合您的系统并使用它,这样您就不必每次编写选择器时都考虑它们。
如果您没有一个系统(尤其是在团队合作时),您编写的每个选择器都会使您的代码库恶化,直到它变得难以管理。
如今我开始发现奇怪的是,使用类在处理 CSS 方面越来越没有用。如今最糟糕的限制因素是 IE8(以及一些移动浏览器),它不支持许多新的 CSS3 选择器,尤其是 :nth-of-type、:target 或 :checked,这些选择器非常有用。
通常我发现使用类是为了让 JavaScript 开发人员可以使用与变量名相同的 CSS 类名。但是,当从纯 HTML & CSS 的角度工作时,我更愿意只在父元素上使用类,然后直接处理实际元素。最近的一个例子是……
HTML
CSS
所有当前的主要桌面浏览器都能很好地处理这种语法,而且我发现它也相当易读。很多交互只需要 HTML 和 CSS 就可以完成,不需要 JavaScript 来完成那些简单的过渡。例如,本网站的搜索框可以用纯 HTML 和 CSS 轻松实现。
当然,我理解将它应用于大型项目是另一回事。
我的眼睛!!!
说真的,我希望您实际上没有使用这样的选择器。即使每个浏览器都支持它们,它们仍然不是一个好主意。
此外,类没有改变,那么它们怎么可能变得没有用呢?
您说“不是一个好主意”,但您没有给出任何理由。
哈哈,首先,正如我之前所说,您缺乏浏览器支持。其次,在什么项目中您使用这样的选择器比类更多?第三,如果有这样的项目,您的样式一定很庞大。第四,如果您认为您使用这些选择器所做的事情就是您实际在做的事情,那么您应该使用 JavaScript 而不是 CSS(样式与功能)。第五,该代码完全依赖于标记(一个微小的更改都会导致它全部中断)。第六,那 CSS 很丑。第七,仅仅因为某件事可以做到,并不意味着它应该做到。第八,这还不够理由吗?第九,有无数种方法可以比那更干净、更简洁地编写代码。第十,读一本书。第十一,我在这里结束了。
虽然您可以像您所展示的那样使用 CSS3 创建复杂的选择器,但我并不建议这样做。我不这样做的一些原因是
IE8 中的浏览器支持不存在
您的样式不是非常模块化的。由于它们与 DOM 的这些特定部分绑定在一起,因此它们不能在很多地方使用。
您的 CSS/HTML 紧密耦合,使其脆弱。如果将一个新的 HTML 元素添加到您的 DOM 中,它可能会破坏所有样式。
这是一个特异性噩梦。如果您想使其中一个项目与其他项目不同,您将不得不创建一个更长的选择器,使用一个 ID 或使用可怕的
!important
我几乎完全用类进行样式设置,当我想在我的 JavaScript 中使用 ID/类时,我使用“js-”前缀,例如
js-rotator
。我从未在我的 JS 中使用 CSS 样式类,因为这意味着我可以更改我的标记/CSS,而不会影响 JS。