搜集一些该搜集的,然后汇总一下。
1.OOCSS 概念篇:
1)什么是面向对象
确定“对象”,并给这个对象创建CSS样式规则。
2)面向对象的CSS理论
OOCSS最关键的一点就是:提高他的灵活性和可重用性。这个也是OOCSS最重要的一点。
3)使用面向对象的CSS的理由
a.将我们的CSS样式更具有重用性
b.另外也使用我们的样式变得更小
c.第三个好处就是我们可以容易的改变一个网站的设计
4)如何使用面向对象的CSS
a.创建一个组件库(Create a component library)
b.独立的容器和内容,并且避免样式来依赖位置
把容器和内容独立出来,这样的好处是,内从插入到任何容器中都可以。
OOCSS主张是通过在基础组件中添加更多的类,从而扩展基础组件的CSS规则,这也就是我们前面所说的OOCSS的扩展性。
c.独立的结构和样式规则(Separate structure and skin)
创建基础的结构(HTML)和创建基础的类名。
d.使用类名来扩展基础对象(Extend base objects using class names)
通过对基础对象扩展类名,从而达到基础对象的可重用性。
e.坚持以语义来定义类的名称
始终坚持以逻辑和语义来给元素定义类名才是王道。
5)面向对象的CSS的优点和缺点
OOCSS的缺点
OOCSS的优点
代码下载:https://github.com/stubbornella/oocss.git
1)模板(Template)
2)媒体对象(Media Objects)
3)网格系统(Grid System)
4)模块(Module)
5)间距(spacing)
1)OOCSS面向对象的css原则
a.结构与样式的分离
b.容器与内容的分离
c.现实生活中的一个例子
2)媒体对象
媒体对象是体现oocss能力的很好的例子,因为它里面容许包含任何尺寸的媒体元素的内容。尽管许多在他内部运用样式的内容甚至是媒体元素大小本身可能改变,但是媒体对象本身具有的通用基本样式有助于避免不必要的重复。
参考文章:CSS制作Facebook的媒体对象
思路:在平时制作中,把相同的一块提出来,拆分成一个独立的模块。在拆分模块时应保证数量尽可能的少的原则下,做到尽可能的简单,以提高他的重用性。
3)OOCSS的好处
a.更快的网站
Oocss带来的好处是很明显的。如果在你的css中有较少的重复样式,那么将使得文件体积更小,从而更快的下载这些资源。
的确,标记将更加混乱,从而创建更大的HTML文件。但是许多情况下标记结构损失很多,却换来了样式表现性能大大提升的效果。
另一个需要记住的概念是在oocss的wiki里面提到他的附属品。这指的是每次在你的css中复用一些样式,本质上就会创建一个有着0行样式的元素。对于大型,高流量的项目,这些附属品有可能是影响性能表现的关键因素。
b.可维护的样式表
随着oocss取代不断增长的特殊样式表,你将有一个易于维护的模块,在里面层叠发挥了重要的作用。
当在现有网站上添加新页面,你将不会不考虑前面的代码,直接在样式表最后添加新的样式。相反你将会复用现有的样式,并在现有样式的基础上扩展你需要的样式。
随着这种类型的长远设想,有可能创建一整个页面只有很少的css代码。任何css模块可以作为所有新页面的基础,这样新css页面就会很小。在某种情况下甚至可以创建一个全新样式的页面却没有一行css代码。
这些可维护性的好处也增强了你的样式表的健壮性。因为样式表已经模块化了,页面是基于oocss搭建的,所以即使一个新开发人员开始使用样式表也不太会破坏它。
4)需要注意的问题
a.你仍可以使用id
b.处理较小的项目
对于较小的网站和应用程序,你也许认定oocss在这种情况下是大材小用了。所以这篇文章中倡导的oocss并不适用于所有的项目,他将取决于这个项目本身。
尽管如此,我认为这是个好主意,至少在你所有的项目中开始考虑oocss的运用。一旦你掌握了他的诀窍,我肯定你会很容易发现,他致力于越大的项目收到oocss带来的好处就越明显。
5)一些实用指导
4.CSS架构
1)优秀的CSS全局架构
我认为好的css架构目标不应该有别于所有好的软件开发目标。我想要我的css是可预见的、可重用的、可维护的和可扩展的。
a.CSS的可预见
可预见性的css意味着你的规则行为正如你所想,当你添加或更新一条规则,他不应该影响你网站上不想要受影响的部分。对于一个小型网站很少的修改,并不是很重要。但是对于一个有着几十或几百个页面的大型网站,可预见性的css就是一种必要。
b.CSS的可复用性
Css规范应该是足够抽象的和耦合的,这样你可以根据现有代码部分很快创建出新的组件,而不需要重新编写你已经处理过的样式和问题。
c.CSS的可维护性
当你的网站需要添加、更新或重新安排一些新的组件和特性,这样做不应该重构现有的css。给页面添加x组件不应该破坏已经存在的组件Y。
d.CSS的可扩展性
随着你的网站的规模和复杂程度的增长,它往往需要更多的开发人员来维护。可扩展的css意味着可以轻松的由有一个人或一个大型的技术团队管理你的网站。他也意味着你的网站的css架构容易掌握不需要很陡的学习曲线,仅仅因为你是如今唯一接触css的开发人员,但是并不意味着永远是这种情况。
2)常见的坏习惯
a.基于父类修改组件
起初这看起来可能是很优秀的代码,但是让我们仔细看,这些都是为实现目标而写。
首先,这个例子中的小结构没有可预见性。创建了好几个这样的结构的开发者希望他是特定的外观,然而当把他用在侧栏或是主页,他将看起来不同,尽管结构是完全一样。
他的复用性扩展性也不是很好。当把他用在主页或是被要求用在其他页面会发生什么?不得不添加新的规则。
最后,他不是很容易维护,因为一旦这个结构重新设计了,那么他必须修改css中的好几个地方,不符合前面提出的CSS架构的要求,需要一个接一个的来修改。
想象一下,如果这种代码被用在其他语言。你本来用一个类定义,然后在代码的其他部分引入这个类定义,为了其他的用途改变他,这直接违背了软件开发过程中打开/关闭的原则。
在本文的后面,我们将看看如何不依赖父选择器修改组件。
b.过于复杂的选择器
c.过于通用的类名
这个想法是.title, .contents, 和 .action类名的子元素定义安全的样式,不用担心会影响其他那些具有相同类名的元素样式。这是真的,但是这并不能防止其他同类名的样式会影响这个组件的样式。
在一个大型项目很可能有个像.title的类名被用到另一个环境中或甚至他本身,如果这种情况发生的话,这个widget’s title会突然看起来跟预期的不一样。
过于通用的类名会导致非常不可预知的css。
d.定制过多的规则
问题是,你让这个选择器做了太多的事情。你在同一个规则中既定义的外观,又定义了布局和定位。外观是可以复用的,但是布局和定位是不能复用的。因为你把他们都混在一起使用,所以整个规则就都不能复用了。
然而这个起初看起来可能无害,但是他往往导致懂行的css开发人员复制和粘帖。如果一个新团队成员想要做一个看起来类似的组件,如一个.infobox。他们可能通过尝试开始用那个类名。但是因为一个新的infobox以一种不想要的方式定位,而不起作用。那么他们可能会做什么?以我的经验,多数新的开发人员不会破坏复用部分的规则。相反他们只是简单复制需要的代码行,然后把他粘帖到一个新的选择器里,这就造成了不必要的重复代码。
e.分析原因
(看原文)
f.解决方案
(看原文)
3)最佳实践
a.有意的
(使用特定类名来代替多级选择器)
b.分担你的忧愁
(外观与布局或定位分离)
c.空间类名称
(命名空间-常用类名)
d.扩展组件与修改类
(将基于父类修改,变为命名空间-特定需求)
e.把你的CSS组织成逻辑结构
基础样式,布局样式,模块样式以及状态样式
f.只用类名作为样式而且只做样式
(功能类名,加js-、test-前缀,不给样式)
g.命名有逻辑结构的类名
(根据不同的逻辑,使用不同的连字符,-、--、_、__等,关联样式用-、子级样式用_等)
4)工具
a.预处理程序Sass
b.CSS Lint
c.HTML校验
5)总结
Css并不只是视觉设计。不要仅仅因为你在写css就扔掉编程中的最佳实践。像面向对象,dry概念,开闭原则,关注点分离等等,仍然适用于css。
底线是任何可以组织你的代码的东西,确保你判断你的方法是否有效帮助你开发容易,长期更易维护。