多文件
很多web开发貌似都和将任务分割为可管理的块或「组件」相关。对于每一个分离的JavaScript功能块、或HTML局部，我可以做一个专门文件，并把相关文件组织到文件夹里，以javascript、html或controller、templates命名。你怎么做都行。这样，你就能轻松查看文件系统，只关注包含有你当时想要编辑的代码文件即可。
这种方式不适用于CSS。JavaScript函数可以放在它们被调用位置的前后，HTML模块可以在任何地方插入，只要你觉得它们适合当前文档流。另一方面，CSS是按照时间顺序发生的。它和你声明样式的顺序，有着很大关系。由于该语言的继承和specificity注1，你应该从一般样式（比如对body设置font-family）开始，并过度到更多具体的定义。
CSS是一个有序的、以例外为基础的语言，没有简单的方法来连贯地表示一个文件列表（通常按照字母顺序组织）。它给了你一个印象，每个CSS文件都是自治的，事实上却不是。
|
1
2
3
|
-
buttons
.css
-
reset.css
|
因此你有两种选择：当你试图把一个方钉子打入圆孔时，你可以对「specificity不应该成为CSS的一部分」持拒绝、抱怨的态度，或者，你用一个有着良好注释的文件，它明确地表示了继承过来层叠的弧度。specificity不应该成为一个问题，因为大多数特定的选择器应该是你最后才编写的。
总结：你不应该把CSS文件分割为独立文件，就像不应该把一块玻璃丢在水泥地板上一样。
嵌套（借助Sass）
我对Sass感到比较纠结。它的一些思想真的让我激动，比如使用循环和条件语句提高编写效率的能力。而另外一些特性就不那么好了，比如无限嵌套的声明。
我认为，很多人选择Sass，帮助他们管理和维护CSS，更方便阅读和编写。Sass做为一个依赖和抽象层所带来的负面影响，就是让事情更加系统化地复杂，据说还有一些Sass提供的接口，比如带参数的混入（mixin）。将其用在项目中，代码的可阅读性和简短程度，就成了一种福音。
嵌套吗？那只会让问题更糟。想象一下组织最糟糕的CSS文件。虽然混乱，但至少是一个维度的混乱：如果你愿意，那么只有一个文件混乱。让编写蹩脚CSS的人（可以是任何人，很多时候也包含我）使用嵌套，相当于授权他们扩大到第二维度的混乱。太棒了！现在，混乱彻底蔓延开来。
鉴于在其它语言里，尽可能地避免嵌套结构是一种职业荣誉感的体现，那么，将这种能力用在不需要嵌套的语言里，貌似有些可笑。HugoGiraudel就Sass写了数百篇指导文章。下面是他就嵌套不得不说的话：
|
1
|
Fucking.Stop.Nesting.
|
总结：你要追寻的Sass特性不应该是嵌套。
像素单位
回溯到IE6的时代，我们被告诫用em单位设置字体大小。较新的浏览器带有缩放功能，可以更容易地按比例增加页面尺寸，但是在IE6，你只能增加字体大小。由于用像素设置的文本拒绝被放大，我们会排斥很多低版本用户。
IE6不再是一个问题了，但是大多数操作系统和浏览器的用户仍然设置独立于缩放功能的字体大小。这应该是他们的喜好，我们应该包容。
说归说，我甚至没有打算实现这一目的。我只想向你自私的一面发出恳求：在响应式设计里使用像素来管理大小，绝对是愚蠢至极的行为。分开元素之间的尺寸，其相对性的缺乏意味着你要不得不为每个独立的断点，单独考虑每种设置。事实上，使用像素时，你甚至不得不管理字体大小和单独的、隔开元素的margin。你本不想这样做的。
举个例子：
|
01
02
03
04
05
06
07
08
09
10
11
|
如果使用相对单位，我该怎么做呢？我不愿意的。事实上，我无需在我的媒体查询里针对任何单独元素设置字体大小和margin。我只想让浏览器或用户根据根元素（）来决定字体大小，并用em或rem来设置我的所有其它规格。
|
1
2
3
4
5
6
7
|
h
1
,
h
2
{
margin
-
top
:
1.5
rem;
}
h
1
{
font
-
size
:
2.5
em;
}
h
2
{
font
-
size
:
2
em;
}
/
*
allyourotherelementstyles
*
/
|
然后，当我想在min-width断点下放大比例时，我只需要根据其它元素的比例，调整根的字体大小。我使用百分比，因为这涉及到用户喜好，如果设置为：
|
1
2
3
4
5
6
7
8
9
|
你的响应式设计的90%策略都在这里了。而且，你还能在所有同级的流元素之间设置通用的margin，比如使用LobotomizedOwls注2的选择器：
|
1
2
3
4
5
|
body
*
+
*
{
margin
-
top
:
1.5
rem;
}
|
总之：拥抱相对性，收获成果。
设备断点
几个月前，也就是在被爆出苹果公司在中国血汗工厂不久，我看到一名评论员发的tweet。他们的tweet包含了一种风格：「对于响应式web设计，所有的视口在iOS9上都是可用的」。
什么？什么？
然后我想起和SaraSoueidan的一次谈话，她把内容断点描述成了响应式设计的「惊天秘密」。我突然想到：有很多人盯着被选定的专门设备，把它们特定的屏幕尺寸做为「响应式web设计」的目标——每当一家技术公司发布一款内置浏览器的设备时，都要「改变这个规划」，那么，成千上万的web设计师可能要骂「ohfuckme」了。想象一下！
|
1
|
“OHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKME”
|
我没有假定你是在此误解下工作的，但适用于一种情况，你有一个朋友，他需要了解真相：适应于具体设备的具体尺寸的断点，不属于响应式设计。这种行为是站不住脚的，它行不通。如果你没有针对某种设备做过调整的设计，具有完整的呈现，那一定是好运气在作怪。这真不算是一个策略。
你应该确保设计是流动的，仅仅在内容遭遇呈现问题的地方插入断点（或「tweakpoint」）。在这些点之间，设计应该无缝地展开或折叠，满足任何出现在这些范围内的设备尺寸的要求。
我对评论员和意见领袖说，我认为他们要说的话和真正的响应式设计没有关系。他答道，「理论上我是认可的，但是移动体验成功的关键在于理解现实世界」。也就是说——没有说明白！我很想知道真正的现实世界是什么样子……有一天我必须参观一下。
总结：苹果不是唯一一家制作带有内置浏览器设备的厂商。真的不是。
1928
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
