今天完成的事情： 

任务十二几个div改成button，添加a标签，互相跳转。

开始任务13，今天的大部分时间用在了看关于模块，为什么要避免嵌套过深，样式分离，避免样式重置，css架构组成（两篇文章的解读时间过长），以及部分属性的查询。页面还没开始写。

以下为学习资料归纳和个人理解：

关于嵌套，看了下任务详解，避免不必要的深层嵌套选择器，搜索了一下深层嵌套导致的后果：

选择器嵌套虽然操作方便，但也有很多缺点:嵌套层次越深，编译的CSS选择器层次也就越深。这种嵌套的方式导致Css样式冗余，难以维护。尽量少用选择器嵌套Sass方式编写。

没有层级 和 深嵌套层级，都应极力避免！

1. 没有层级，类名重复不可避免，考验你起名的能力

2. 层级太深，客户端css解析效率就会降低

3. 层级深，css的展示优先级（权值）相对就会提高，比如ul li定义的样式会优先于li展示. 问题来了，你想覆盖那些层级很深的样式就不得不定义更深的层次样式。

所以根据具体情况执行，名字特殊的一看就不会跟别人重复的，那么你只用一级都可以。 对于适用于很多场景的css类，每个场景跟嵌套相关，那么就采用必要的嵌套层次。

最后唠叨一句：不要为了所谓的想让各元素级别清晰，套了很深很深的层级，浪费资源！
让层级尽可能简短一些，别让简单的事情变复杂。

____________________________________________________________________________________________

总结：

在学习了如何使用sass之后，一直根据html的层级来写sass，觉得很方便，条理清晰，但导致嵌套的层级非常深，权值分配也高，后续想改媒体查询样式也需要加个 ！important 或者把层级整个搬过去，这是不方便的地方之一。后续写sass的话应该尽量避免过于深层的嵌套，但是并没有一个具体规范，全靠经验，只能避免深层嵌套了。

____________________________________________________________________________________________

关于样式分离：

样式的独立拆分，使得各种效果可以自由组合，这是有别于一个class类覆盖多个CSS属性的做法的。样式的独立拆分，精简的CSS文件，每个样式的重用性可谓发挥到的最大，同时，页面的后期维护变得异常轻松，样式冲突的可能性也是非常低的。

CSS样式库又分为“通用库”，和“当前项目库”

总结这一节的核心观点，其实不难理解，就是“构成的基本元素越是独立，越是最简，其组合的可能性，元素的利用率越是高！”

CSS样式越是分离，其样式的利用率和覆盖率就越高，

万物守恒，CSS的精简会导致部分HTML代码的开销增大

样式越是拆分的彻底，CSS代码越是精简，CSS代码的重用率以及单个页面CSS样式的覆盖率都会相当惊人。

但是，物极必反，理论不能代表实践。如果我们把所有的CSS样式进行拆分。对于一些复杂的UI效果，例如圆角自适应的导航，则此处的HTML代码开销会非常之大，此时一味的样式再分离，会使得HTML代码变得很痛苦。

所以，我们需要权衡，何时分离，哪些要分离？样式精简与重用仅仅是通过分离吗。

可以肯定的是，所有样式都要分离显然是不行的，CSS也是需要架构的，而没有架构这一意识，分离反而会出问题。

____________________________________________________________________________________________

看了张鑫旭的样式分离文章，和评论里的讨论，总结：

基础的样式分离相当于建立一个库，把需要用到的样式一一拆分，拆分越细致，写代码的时候越简洁，在需要的时候添加。

虽然精简了css，但是给html带来了负担，而且若要修改某个数值，还需要css和html两头并改。

这个分离的度并不好把握，所以要有一个架构的意识。

样式不够细化，后期维护中往往会增加CSS；样式太细化，后期维护就要涉及到html改动；CSS修改的成本要远小于html的。

要合理的细化，且要视项目情况而定。

如果是把样式做更细的颗粒化，从而提高css重用，是错误的，若一个模块修改样式则会带来巨大的成本。

在制作一个复杂的模块的时候，将拆分的样式组合将会很复杂，所以在必要的时候，重写一个css样式也是可以的。

这就需要模块化。

CSS reset的重新审视 – 避免样式重置

____________________________________________________________________________________________

关于css架构

---来自张鑫旭文章

1，首先是css reset，尽量简短，避免*{margin：0，padding：0；}这种。

2，自己写一个通用样式库，日常方便调用。例如：display：flex之类的。

3，写一个项目样式库

这里的样式是根据当前实际的项目内容指定的。例如，文字链接颜色是什么，文字链接经过的样式是什么；一些常用的背景色样式，常用的边框样式等，以及一些高宽等。按照我的经验，网站CSS样式库又可以架构为以下几部分：
① 网站常见颜色，尤其是链接色

② 网站常见背景色（我习惯用bg+颜色前2字母表示，例如.bgf7表示background:#f7f7f7）
③ 网站常见边框色这里类似于CSS 通用库中的margin属性，需拆分，例如.bbdd表示border-bottom:1px solid #ddd;每人的命名习惯不一样，但是尽量简单为好，甚至您可以像Google一样，直接两个字母（大小写混搭）表示。另外，一定要告知设计师，边框取色不宜多，不能凭感觉，要有所牺牲，也就是如果之前使用了#cecece的边框色，后面的#d0d0d0颜色与之相近，请可以使用#cecece代替，用户是看不出来其中差异的。

④ 网站遗留的单margin属性，例如，某一div留白较大，有个单独的margin-top:35px的属性，OK，这个属性请放在网站CSS样式库中，以.mt35{margin-top:35px;}保留，以供之后类似布局或需要的地方使用。
⑤ 网站遗留的单padding属性，例如，双栏自适应布局时，无论是浮动自适应，还是绝对定位自适应，都需要使用padding-left值，此时的padding-left多单样式，可抽取出来，以网站样式库的形式存在。记住，是单属性，且不可从通用元素中抽取单独的padding值，否则是给自己挖火坑。
⑥ 网站已有的width属性，在流体布局思想下，宽度是有限的，是珍贵的，需好好利用。
⑦ 网站常用的一些height属性，指一些高度值，例如height:18px，height:20px，height:24px，height:50px，height:100px，height:200px等。

记住一个原则：网站通用的元素（按钮，导航，选项卡的）的样式千万不能分离作为网站的CSS样式库。

4，网站通用小图标样式集（雪碧图合集以及命名）----个人见解若有需要则注释一下图标是啥方便确认。

在小图标样式命名的时候，我的建议是不要关联图片的内容，比如说一个相册的下图标，不应该使用iAlbum这样的命名。原因有三：

1. 思考图片的命名杀死n多脑细胞
2. 命名较长，占用字节数，也就是CSS文件大小
3. 也是最重要的，后期的维护。设想下，如果日后相册的图标不再被使用了，原来相册图标的位置可以被其他小图标（如RSS小图标）替换吗？理论上可以，实际上，我们除了必要的html替换，还需要重新修改图标样式的命名，即iAlbum→iRss的命名，而往往取而代之的做法是直接在后面添加新的图标。

我目前的做法是使用一个不常用的标签作为网站的小图标专用标签，例如s标签，或是u标签，我习惯将小图标单独为一个小图标Sprite，每个图标放在20*20像素的格子中。在这种情况下，我都是使用矩阵命名法。命名只关联位置，例如，我使用u标签作为整个网站的小图标专用标签，则按照图标的位置（假设一行20个图标），我会依次命名为：u00,u01,u02…u019,u10,u11,…u119…。这种命名的好处是不用关心到底哪个位置是那个图标，不用担心命名冲突，在小图标位置以及内容更换的情况下也无需重命名。

5，网站通用样式

这里的“网站通用样式”可以说与“网站通用样式库”最为对立的两部分。网站通用样式专指“独立元素”的通用样式，所谓“独立元素”指的是网站通用的导航，菜单，按钮，选项卡，文本框装饰，图片装饰，圆角处理等等。这些“独立元素”的样式千万不能对其进行分离并归入“网站通用样式库”中，否则，日后会给你留下无尽的痛苦的！

6，网站公共结构样式

所谓“网站的结构样式”主要指的是最外框div的样式，一般限制网站的宽度(960~990不等)，还有就是网站的分栏布局样式，这里的样式仅仅针对主体结构，例如left_part，或是right_part；还包括网站的头部的一些公用结构，底部的样式结构等。

我是强烈建议公共结构仅仅定宽定高，设置浮动属性，切不可在结构样式上添加margin或是padding属性，这会使网站的公共结构的重用性大大降低

个人总结：

css架构根据每个人的个性，项目需求，习惯不尽相同，可以作为一个架构的参考，总的来说，先分析项目需求，例如颜色，边框，背景颜色，字体大等等，根据这一系列需求分别建立通用库，项目库，模块库，雪碧图库等等，进行各类模块或样式的分组，把需要用到的样式一一编入库中，再对每一个页面独特的需求进行细分，这样就相对条理分明，让自己对于项目需求有一个清晰的了解。

____________________________________________________________________________________________

关于css架构

-------来自学习资料： 一个健壮且可扩展的 CSS 架构所需的8个简单规则 

何为健壮？

样式分离，使组件之间互不影响，且提高样式重用性，理念和张鑫旭的差不多。

总结：

1，总是类名优先

不要去使用 ID 选择器，因为每当你认为某样东西只会有一个实例的时候，在无限的时间范围内，你都将被证明是错的。

同样也不应该直接使用元素选择器（如 p）。通常对一个属于组件的元素使用元素选择器是可以的。

所以在极少特例的情况下，你的样式应该总是类名优先。

2. 组件代码放在一起

总的来说就是相同的模块代码文件css，js文件之类放一起。

3. 使用一致的类命名空间

命名方式，以及命名空间的起名。要统一，不要变来变去。参考bem。

4. 维护命名空间和文件名之间的严格映射

例如class=head-link，浏览器调试点击到这个类名，html文件里直接搜索head就可以跳转到那一部分。

5. 避免组件外的样式泄露（不会影响其他组件）

一个健壮，且仍然非常简单的解决方案就是将整个样式文件包装成一个前缀。如果每个组件都只使用加上它们唯一的命名空间前缀的类名，那我们就可以确定它们的样式不会泄露到其他组件中去。这是非常高效的（看后面的注意事项），但是不得不反复输入命名空间也会变得越来越冗长乏味。

sass可以利用&符号直接引用父元素，方便直接引用父级元素类名。（提倡命名规则统一化，以模块区分）

媒体查询也能很好的写出来：

（sass里媒体查询居然还能这样写。。我之前都是另外写然后因为没有嵌套，导致权值不够使用！important强制修改。。）

这一部分的主要思想就是让你命名规范化统一化，不至于css样式影响其他组件。参考BEM命名规范。

6. 避免组件内的样式泄露

（理解为宁可引用命名超长的类选择器也不要直接使用元素选择器）

一，绝不在样式表中使用元素名称选择器。如果 Header 里的 <a> 元素都使用 <a class="myapp-Header-link"> 替代，那么我们就不需要处理这个问题了。

二，在你的命名空间之外只使用 > 操作符 来选择元素。

根据第二个方法来做调整，我们的样式代码就可以改写如下：

1
2
3
4
5

.myapp-Header {
> a {
color: blue;
}
}

这样就可以确保隔离同样作用于更深层次的组件树，因为生成的选择器变成了 .myapp-Header > a。

但是，这会导致你的嵌套层级非常的深，所以并不推荐这个做法，我们应该避免嵌套过多，这会使你想改变该样式非常的繁琐以及其他各种问题。

预防泄露样式进入组件

只需强制覆盖它：如果你为每个组件的每个元素去引入一个 CSS 重置样式，并且使用一个优先级总是高于其他第三方库的选择器，那么就非常棒了。

all: initial 是一个很少人知道的新 CSS 属性，它专门为了这个问题而设计。它可以阻止继承属性流入，并且只要它赢得了特性之争（并且只要你为每个想保护的属性重复使用它），还可以作为一个本地重置生效。它的实现有些错综复杂，而且还不是所有浏览器都支持，但是 all: initial 最后或许可以成为样隔离的有效方法。

7. 遵守组件边界

这一部分我的理解为准守定制好的模块区域，不要随意破坏布局，要注意组件之间的影响，父元素对于子元素的影响要注意，不要因为调整父元素的样式导致破坏了子元素的布局。

8. 松散地整合外部样式

为了避免重复工作，有时可能需要在组件间共享样式。为了避免全部工作，有时又可能想使用其他人创建的样式。这两种情况的实现都不应该创建出不必要的耦合到代码库中。拿一个具体的例子来说，考虑使用一些来自 Bootstrap 的样式，因为这对于使用恼人的框架来说是一个很好的例子。想想我们上面所讨论到的所有事情，关于为样式共享一个独立的全局命名空间，以及不好的冲突，Bootstrap 会：

• 导出一大堆选择器（版本 3.3.7 来说, 具体有 2481 个）到命名空间里，不管你实际上是否使用它们。（有趣的一面：IE9 在默认忽略剩余选择器之前只会处理 4095 个选择器。我曾经听说有人花了很多天来调试它们，鬼知道他们经历了什么。）
• 使用写死的类名如 .btn 和 .table。不敢想象某些不小心复用了这些样式的开发者或者项目。

这部分的意思应该是说，避免那些通用样式库和引入写好的框架里的样式类名冲突，导致样式重复或者不必要的使样式产生其他效果。

总结：

不要使用id和元素选择器，模块相关的文件整合在一起，命名空间以及命名规范，对于命名的映射应该简单好懂能指向该模块或组件。避免模块内的样式影响模块外的样式以及影响模块内的样式，类名长些都无所谓，在设置父级元素的样式时，注意避免影响到子元素模块的布局，准守好定制的模块边界，对于引用的外部框架，或者多人开发的公用库，要注意不要导致类名冲突，这八大规则没有到开发项目的经验稍微有些地方难懂，但是规范差不多是这意思。

明天计划的事情： 

基础的框架结构，以及规范已经了解了，接下来就是分析任务需求，拆分模块，写一个通用库，任务库，单个页面细致的css，了解侧边框如何实现，完成任务13，并且了解js的事件概念.

遇到的问题和收获：

之前写任务想达到响应式字体，使用的是vw，导致的问题是字体不可控，虽然也算自适应了。

现在使用rem通过媒体查询更改根元素html{font-size：}来达到自适应的效果。

使用sass引入另外一个css文件使用

@import:

（1）.被导入文件的名字以.css结尾。

（2）.被导入文件的名字是一个URL地址，例如:http://www.softwhy..com/css.css。

（3）.被导入文件的名字是CSS url()值。

引用已有样式使用@extend .name；

出现一个问题，我使用sass写代码的时候想把通用库的css文件引入sass文件中，好进行类的引用，但是导入css文件没出差错，使用@extend引用通用库里的类的时候却报错。

提示说是没找到这个类，但是我导入通用类库却没报错。搜不到答案。