设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客
LUPA开源社区 首页 业界资讯 技术文摘 查看内容

AM介绍——CSS的属性模块

2014-9-10 10:08| 发布者: joejoe0332| 查看: 3019| 评论: 0|原作者: 开源中国匿名会员, daxiang|来自: 开源中国社区

摘要: 几个月前,我读了一篇文章article by Harry Roberts ,在文章里Harry Roberts 介绍了关于CSS一个有趣的概念。 他认为在css属性中使用,可以帮助开发人员快速理解这些属性的功能。 他给出了下面的示例,证明使用可以 ...

  几个月前,我读了一篇文章article by Harry Roberts ,在文章里Harry Roberts 介绍了关于CSS一个有趣的概念。 他认为在css属性中使用[],可以帮助开发人员快速理解这些属性的功能。 他给出了下面的示例,证明使用[]可以使类更容易校验-更容易快速理解。

1
<div class="[ foo  foo--bar ]  [ baz  baz--foo ]">


  我必须承认,我对这种手法感觉非常不舒服。 类的名称如果含有[或者],没有css会与之匹配,因为它与css的一个属性重复,这看起来只是为人设计的而不是为浏览器。 事实上,到现在我还是反对这种手法,不过这使我更深入的理解标记和语义的概念,谢谢Harry

当我深入研究标记和语义时,一些朋友给了我类似的建议,如使用 / (Ben Everard),或者 | (Stephen Nolan),但是不舒服的感觉使我拒绝了他们的建议。 我想:

已经有很类了,为什么还要使用更多的类来使这些代码变得可读?


  这是疯狂的行为。 写出易读懂、易校验的html代码是一个值得追求的目标,但是上面这些设计手法违背了html中一些基础的设计思想。


更多 vs 更少 - 简单比较

  神奇的是,虽然在标签里面放那么多类让我非常不爽,可是人们爱哈利,因为他太特么能说了。提倡的某些东西,比如说 OOCSS 和单一责任原则,从我自己创建的一系列日益复杂的网站来看,我可以说这确实值得对样式行为进行解耦,不过直到最近我才找到一种让我觉得满意的方式来实现它。


  我原先有做过一个 BEM 的版本,它强调了独立高于重用 ‐ 每个新的块默认是没有样式继承的,允许组件独立开发并且可以避免打乱页面其它样式的风险。不过代价就是碎片化(fragmentation) ‐ 忽然你会发现你有了 10 种不同的样式链接,12 种不同的蓝色,18 种差别细小的按钮样式等。妮可・沙利文,OOCSS 的作者,去年在墨尔本做了一个超赞的演示,讲到了这个问题是有多普遍,以及怎么解决它。


  对我来说,我觉得可以接受的解决方案是,深入 CSS 的预处理机能,从而取得 BEM 的独立性以及 OOCSS 的一致性。比如说,下面这样的:

1
<a class='btn large rounded'>
1
2
3
.btn { /* button styles */ }
.large /* global large-type modifier */ }
.rounded { /* global rounded-border modifier */ }


  应该改成这样:

1
<a class='btn btn--large btn--rounded'>
1
2
3
.btn { /* button styles */ }
.btn--large {  @extend %large-type;}
.btn--rounded {  @extend %rounded-borders;}


  我成功终结了充满了占位符的文件,比如满眼都是那些_typography.scss 和 _brand.scss,这不但让我有能力控制碎片化,同时还能默认保持了样式的对每个新组件的独立性。所有的东西都挺好的,起码有那么一段时间是这样。


修饰符: M 是怎样破坏 BEM 的

  只要你做关于 CSS 类的命名 & 维护方面的任何研究,你一定会要看到尼古拉斯・加拉格尔的杰作"关于 HTML 的语义和前端架构"。其中一部分特别吸引我,他称之为修饰符的 '单类模式' vs '多类模式'。简单的说,你的 HTML 会有两个版本,看起来像这样:

1
2
<a class='btn--large'<!-- Single class -->
<a class='btn btn--large'<!-- Multi class -->


  这通过两个备选的 CSS 模式实现:

1
2
3
4
5
6
7
/* Single class */
.btn, .btn--large /* base button styles */ }
.btn--large /* large button styles */ }
 
/* Multi class */
.btn { /* base button styles */ }
.btn--large /* large button styles */ }


  这两个模式的差别在于 btn--large 是否只要它自己就足够了,还是说它需要依赖类 btn 。单类模式说”可以”,它看起来更简单而且可以避免有人忘记把 btn 包含进来的情况。而且它也不啰嗦,配合 SASS 的 @extend 方法,它对 CSS 来说不像一个负担,只不过它有一个致命伤。


上下文重写

  我们假设你的所有按钮都有背景色,除了你顶部导航栏那些没有。在多类模式下,所有的按钮,大的小的,圆的方的,等等之类,都会包含类 btn,所以你可以这样写:

1
header > nav > .btn { backgroundnone; }


  而在单类模式中,我们不知道哪种按钮会被重写,所以你只好这样:

1
header > nav {  .btn, .btn--large, .btn--rounded { backgroundnone; }}


  很显然,这不理想 - 追加一个按钮变体也就意味着要检查所有地方的按钮样式重写以及添加一个新类。这是个大忌,所以许多人的讨论都回归到了多类模式上(尼古拉斯・加拉格尔, 本・史密西特)。我还看到一些别的方案,比如说汤米・马歇尔还有・文思,他们用属性前缀选择器 ^=,可以检查你的属性是否以特殊字符串开头,比如:

1
<a class='btn--large'>
1
2
3
[class^='btn'] { /* base button styles */ }
.btn--large /* large button styles */ }
header > nav > [class^='btn'] { /* Overrides for all buttons */ }


  这实现了单类模式下的简单的上下文重写,不过它还是太弱了,不是一个可以托付的选择。最致命的是,如果另一个类在 btn--large 出现,而且前缀选择器还没匹配到它,那么之后的所有的都完蛋了。而且,它还没有显式的方法来指定多个变种,比如说 btn--large--rounded。


  我很欣赏这种创造性的方式,不过还是死路一条。好吧,到这里我特么操蛋了,吐,直到忽然某天我灵光一闪。


为毛要用类?

  不要在意我那么直接这种小问题,不过给我个理由先,为什么类是我们放样式信息的唯一位置?HTML生存守则如是说:

3.2.5.7 类属性

属性,如果要指定,就必须有一个用来标记该元素属于不同类的值,该值用一组空格分隔符来表示。

而开发者在类属性中怎样使用该标记是没有任何限制的,但是鼓励开发者使用描述该内容的属性性质的表达,而不是描述该内容所期待呈现何种结果的表达。


  所以对吧,我们用类来描述"内容的属性性质"是很有道理的,但是好像我们对类需求过度了吧。一个属性就包括了所有的东西,从巨大的 BEM-风格 命名,比如说 primary-nav__sub-nav--current 到像 u-textTruncate 或者 left 或者 clearfix,到 JavaScript 用的比如说 js-whatevs,然后我们花了巨多时间来解决命名冲突的问题,然后还希望他们有很好的可读性。


  通过约定 & 习惯这是可控的,而且还有像文章前面说到的哈利的那种技术也挺有用的,不过,有一个事实是,我们所有的操作都是基于一个全局命名空间(global namespace)的,不管有多少规约都无法改变的事实。这让我们下面出场的 AM 就有那么一点不同了。


  在我们正式开始讨论它之前,我们来复习一下 CSS 一个鲜为人知的特点。


欢迎 ~= 登场,神奇的选择器

  从 IE7 开始,浏览器开始支持一种超厉害的 CSS 规则,叫做空格分隔属性选择器(space-separated attribute selector), 具体描述在CSS技巧里面。它可以匹配任何属性值,通过空格分隔,就像它们是类一样。下面两行的 CSS 是等价的:

1
2
.dat-class { /* dem styles */ };
[class~='dat-class'] { /* dem styles */ };


  和 <div class='a b c'> 一样,它不在意 a,b 和 c 的顺序,也不在意是不是还有其它, ~= 选择器也不在意。不过 ~= 不限于类(class)属性,这就是这种全新技术的关键。



酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部