<div class="shadow-box"></div>
<div class="slibling-box"></div>

 

如果slibling-box是相对定位或是绝对定位,这个shadow-box的css阴影是不会显示的。

原因是因为css精确定位的元素在浏览器的渲染中或默认的覆盖自由布局的元素,在这里slibling-box会覆盖shadow-box,所以无论怎样设置阴影都是不会显示的。

 

解决办法,去除相邻元素的精确定位属性,或是对设置阴影的元素应用精确定位+z-index。

  1. 域名是不是你的品牌并不重要,域名没有有DA,能不能帮你排到行业关键词更高的位置才重要,况且你还不是品牌。
  2. 第一次上线发布,至少要有300个页面。
  3. 每天都要有1-2次更新,要有新的内容添加到网站中。
  4. 性能要快,没有人喜欢慢的网站。
  5. 建好之后不管不问,不断按照实际情况更新,修改,调整,优化的网站,不如不建。所以很多网站开发公司按稿开发,这本没有错,只是千万别再称自己是电商公司了。
  6. 己所不欲勿施于人,自己觉得不对劲的地方,别指望客户看着舒服。你都觉得不怎么样的图片,还是赶紧删了吧。
  7. 分析你的客户需求的类型,在合适的位置添加适当的CTA。获取潜在客户信息也很重要,有了客户的信息和长久的持续沟通,过滤排除无效客户,建立信任,才有高质量的询盘。如果来一个询盘就是需求,那么这个行业肯定是蓝海行业,肯定是没有竞争的行业。
  8. 不要把CTA和强迫客户去做一件事混淆。CTA重要的是有说服力和吸引力,核心是客户所关心的利益和好处。强迫更多的是站在自己的角度。
  9. 关注数据,没人访问的页面要及时的从重要的位置去除,腾位置给其他页面。
  10. 你的导航好不好用,用户能不能快速找到自己的目标,会对跳出率有很大的影响。一个网站的导航应该不止一个,应该根据页面的梯级层次,不同的内容类型,添加不同功能的导航,导航的设计应遵循同一性的原则。
  11. 结合产品的特征和用户的特点设计页面,好看和炫,有时候会适得其反。
  12. 少在一个产品页面放与这个产品或一类产品无关的东西,因为用户会觉得你不专业。
  13. 文案很重要,一个网站给人的印象计10分,设计占三分,文案占七分。有好的文案,甚至不需要设计。怎么写好的文案,瞄准关切,写!!!CARE。怎么知道关切,这需要行业浸淫和产品专业,这是内功。要想学习文案写作,关注微信号-纯净纽澳小栈。如果你还不知道什么是文案,我感觉没法说下去了。
  14. 第一屏必须要显示产品,72%的用户不会下滑到第二屏,什么,你是苹果的用户,当我没说。
  15. 外链,外链,外链,重要的事情说三遍。
  16. 时刻告诉客户,你来对地方了,我这有你想要的,我能给你想要的,我能做的很好。

代码规范我们应该遵循古老的原则:“能做并不意味着应该做”。

全局命名空间污染

总是将代码包裹在一个立即的函数表达式里面,形成一个独立的模块。

不推荐

var x = 10,
    y = 100;
console.log(window.x + ' ' + window.y);

推荐

;(function(window){
    'use strict';
    var x = 10,
        y = 100;
    console.log(window.x + ' ' + window.y);
}(window));

立即执行函数

立即执行函数里面,如果有用到全局变量应该通过变量传递的方式,让立即执行函数的函数体在调用时,能以局部变量的形式调用,在一定程度上提升程序性能。
并且应该在立即执行函数的形参里加上undefined,在最后一个位置,这是因为ES3里undefined是可以读写的,如果在全局位置更改undefined的值,你的代码可能得不到逾期的结果。
另外推荐在立即执行函数开始跟结尾都添加上分号,避免在合并时因为别人的代码不规范而影响到我们自己的代码
不推荐

(function(){
    'use strict';
    var x = 10,
        y = 100,
        c,
        elem=$('body');
    console.log(window.x + ' ' + window.y);
    $(document).on('click',function(){

    });
    if(typeof c==='undefined'){
        //你的代码
    }
}());

推荐

;(function($,window,document,undefined){
    'use strict';
    var x = 10,
        y = 100,
        c,
        elem=$('body');
    console.log(window.x + ' ' + window.y);
    $(document).on('click',function(){

    });
    if(typeof c==='undefined'){
        //你的代码
    }
}(jQuery,window,document));

严格模式

ECMAScript 5 严格模式可在整个脚本或独个方法内被激活。它对应不同的 javascript 语境会做更加严格的错误检查。严格模式也确保了 javascript 代码更加的健壮,运行的也更加快速。

严格模式会阻止使用在未来很可能被引入的预留关键字。

你应该在你的脚本中启用严格模式,最好是在独立的 立即执行函数 中应用它。避免在你的脚本第一行使用它而导致你的所有脚本都启动了严格模式,这有可能会引发一些第三方类库的问题。
不推荐

'use strict';
(function(){

}());

推荐

(function(){
    'use strict';
}());

变量声明

对所有的变量声明,我们都应该指定var,如果没有指定var,在严格模式下会报错,并且同一个作用域内的变量应该尽量采用一个var去声明,多个变量用“,”隔开。
不推荐

function myFun(){
    x=5;
    y=10;
}

不完全推荐

function myFun(){
    var x=5;
    var y=10;
}

推荐

function myFun(){
    var x=5,
        y=10;
}

使用带类型判断的比较判断

总是使用 === 精确的比较操作符,避免在判断的过程中,由 JavaScript 的强制类型转换所造成的困扰。

如果你使用 === 操作符,那比较的双方必须是同一类型为前提的条件下才会有效。
不推荐

(function(w){
  'use strict';

  w.console.log('0' == 0); // true
  w.console.log('' == false); // true
  w.console.log('1' == true); // true
  w.console.log(null == undefined); // true

  var x = {
    valueOf: function() {
      return 'X';
    }
  };

  w.console.log(x == 'X');//true

}(window.console.log));

推荐

(function(w){
  'use strict';

  w.console.log('0' === 0); // false
  w.console.log('' === false); // false
  w.console.log('1' === true); // false
  w.console.log(null === undefined); // false

  var x = {
    valueOf: function() {
      return 'X';
    }
  };

  w.console.log(x === 'X');//false

}(window));

变量赋值时的逻辑操作

逻辑操作符 || 和 && 也可被用来返回布尔值。如果操作对象为非布尔对象,那每个表达式将会被自左向右地做真假判断。基于此操作,最终总有一个表达式被返回回来。这在变量赋值时,是可以用来简化你的代码的。
不推荐

if(!x) {
  if(!y) {
    x = 1;
  } else {
    x = y;
  }
}

推荐

x = x || y || 1;

分号

总是使用分号,因为隐式的代码嵌套会引发难以察觉的问题。当然我们更要从根本上来杜绝这些问题[1] 。以下几个示例展示了缺少分号的危害:

// 1.
MyClass.prototype.myMethod = function() {
  return 42;
}  //这里没有分号

(function() {

})();

 //2.
var x = {
  'i': 1,
  'j': 2
}  // 这里没有分号
//我知道这样的代码你可能永远不会写,但是还是举一个例子
[ffVersion, ieVersion][isIE]();

 // 3.
var THINGS_TO_EAT = [apples, oysters, sprayOnCheese]  // 这里没有分号

-1 == resultOfOperation() || die();

错误结果

  1. JavaScript 错误 —— 首先返回 42 的那个 function 被第二个function 当中参数传入调用,接着数字 42 也被“调用”而导致出错。
  2. 八成你会得到 ‘no such property in undefined’ 的错误提示,因为在真实环境中的调用是这个样子:xffVersion, ieVersion().
  3. die 总是被调用。因为数组减 1 的结果是 NaN,它不等于任何东西(无论 resultOfOperation 是否返回 NaN)。所以最终的结果是 die() 执行完所获得值将赋给 THINGS_TO_EAT.

语句块内的函数声明

切勿在语句块内声明函数,在 ECMAScript 5 的严格模式下,这是不合法的。函数声明应该在作用域的顶层。但在语句块内可将函数申明转化为函数表达式赋值给变量。
不推荐

if (x) {
  function foo() {}
}

推荐

if (x) {
  var foo = function() {};
}

不要使用eval函数

eval() 不但混淆语境还很危险,总会有比这更好、更清晰、更安全的另一种方案来写你的代码,因此尽量不要使用 eval 函数。

数组和对象字面量

1.用数组和对象字面量来代替数组和对象构造器。数组构造器很容易让人在它的参数上犯错。

不推荐

//数组长度3
var a1 = new Array(x1, x2, x3);
//数组长度2
var a2 = new Array(x1, x2);

//如果x1是一个自然数,那么它的长度将为x1
//如果x1不是一个自然数,那么它的长度将为1
var a3 = new Array(x1);

var a4 = new Array();

正因如此,如果将代码传参从两个变为一个,那数组很有可能发生意料不到的长度变化。为避免此类怪异状况,请总是采用可读的数组字面量。
推荐

var a = [x1, x2, x3];
var a2 = [x1, x2];
var a3 = [x1];
var a4 = [];

2.对象构造器不会有类似的问题,但是为了可读性和统一性,我们应该使用对象字面量。

不推荐

var o = new Object();

var o2 = new Object();
o2.a = 0;
o2.b = 1;
o2.c = 2;
o2['strange key'] = 3;

推荐

var o = {};
var o2 = {
  a: 0,
  b: 1,
  c: 2,
  'strange key': 3
};

三元条件判断(if 的快捷方法)

用三元操作符分配或返回语句。在比较简单的情况下使用,避免在复杂的情况下使用。没人愿意用 10 行三元操作符把自己的脑子绕晕。
不推荐

if(x === 10) {
  return 'valid';
} else {
  return 'invalid';
}

推荐

return x === 10 ? 'valid' : 'invalid';

for循环

使用for循环过程中,数组的长度,使用一个变量来接收,这样有利于代码执行效率得到提高,而不是每走一次循环,都得重新计算数组长度
不推荐

for(var i=0;i<arr.length,i++){

}

推荐

for(var i=0,len=arr.length;i<len,i++){

}

重复的dom操作

重复的dom操作,使用一个变量来进行接收很有必要,而不是频繁的去操作dom树,这对性能与代码的整洁及易维护性带来不好的影响
不推荐

$('.myDiv').find('.span1').text('1');
$('.myDiv').find('.span2').text('2');
$('.myDiv').find('.span3').text('3');
$('.myDiv').find('.span4').text('4');

推荐

var mydiv=$('.myDiv');
mydiv.find('.span1').text('1');
mydiv.find('.span2').text('2');
mydiv.find('.span3').text('3');
mydiv.find('.span4').text('4');

在jquery .end()可使用的情况下应该优先使用.end()
推荐

$('.myDiv').find('.span1').text('1')
           .end().find('.span2').text('2');
           .end().find('.span3').text('3');
           .end().find('.span4').text('4');

注释规范

在描写注释时,推荐格式化且统一的注释风格,在写注释时尽量描述写代码时的思路,而不是代码做了什么。
不推荐

//获取订单
function getOrderByID(id){
    var order;
    //...
    return order;
}

方法的注释应该统一用块级注释
推荐

/**
 * 根据订单id获取订单详细数据
 * @param  {[number]} id [订单ID]
 * @return {[order]}    [订单详细信息]
 */
function getOrderByID(id){
    var order;
    //...
    return order;
}

什么是设计模式?

曾有人调侃,设计模式是工程师用于跟别人显摆的,显得高大上;也曾有人这么说,不是设计模式没用,是你还没有到能懂它,会用它的时候。

先来看一下比较官方的解释:“设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可 靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。”

今天我们来聊聊CSS的设计模式。

设计模式,这个词汇我们常见,几乎所有的编程语言都会有几套,但深入研究的人不多,原因如下:

1、似乎没有太大必要性去强调它,有问题了改一下或者按团队规范来就行;

2、不去使用一些既有的模式也无伤大雅;

3、不少人所接触的业务量级还没有达到需要规划和组织的程度,光写布局,写特效,照顾兼容,就够喝一壶的了,没有意识去思考一些方法论的问题。

当然,这三者都是我经历过的,相信你也是~

我们都会长大,都会慢慢的做更多、更大、更复杂的项目,这个时候,就需要自上而下,全流程的去思考一些问题。后台不说,只讲前端,比如:风格的 制定、色调、模块、布局方式、交互方式、逻辑等等,如果再加上团队合作,若再没有一个规划的话,要不了多久,那些看起来没问题的代码,就会暴露出各种问 题,模块命名、类的命名、文件的组织、共用模块的提取、代码的复用、可读性、扩展性、维护性。它们看起来只是一些简单的小动作,却需要你看得更远,避免将 来出问题需要付出更大的代价,甚至被迫整个项目重构,可谓,功在当代,利在千秋~

既然要对CSS进行设计,那么肯定是它本身存在一些问题或者缺陷,其中,一个最明显的就是,它的任何一个规则,都是全局性的声明,会对引入它的页面当中所有相关元素起作用,不管那是不是你想要的。而独立及可组合的模块是一个可维护系统的关键所在。下面,我们就从多个层面来探讨一下,到底该怎样写CSS,才是更科学的。

  从需求出发

  分

我们刚开始学习写字的时候,是不会去考虑,写出来的某句话好不好,文章结构合适不合适,因为我们是意识不到的。写代码也一样,刚开始,我们只是 去定义规则,能用对了属性,语法正确,把页面实现出来了,就好。慢慢地,就会发现,页面也是有结构的,我们按照页面的结构去组织代码,会不会更好?比如, 分成头部、导航、侧边栏、banner区、主内容区、底部等。

然而这样貌似还是不够,因为还有一些东西,复用度是很高的,又不好把它归为任何一个固有模块,比如:面包屑、分页、弹窗等,它们不适合被放到某一个固有模块的代码中,就可以单独的分出一段专属的css和js,或许,这就是组件化的由来~

  拆

在分了之后,我们的代码看起来已经比之前好很多了,组织清晰,维护性大幅提高,但是,好像还是不够,我们会发现另外一些东西,很细小,但复用度 也很高,它们同样不适合被放到模块中去,比如,边框、背景、图标、字体、边距、布局方式等等。如果我们在每个需要它们的地方,都定义一次,它们会被重复很 多次,显然,这背离好的实践,会造成代码冗余和维护困难。所以,我们需要“拆”。拆过之后会怎样?我们想在哪里用可以直接加,需要改的时候统一改。

  排

经过了“分”、“拆”,我们的代码结构已经十分清晰,各个内容模块,功能模块,UI模块都乖巧的等待召唤,那么还差什么?是的,还差有序的组织,分类清晰之后,还需要排列有序,从不同纬度去考量,我们总能精益求精。举个栗子,我们可能会看到像这样:

@import "mod_reset.css";
@import "ico_sprite.css";
@import "mod_btns.css";
@import "header.css";
@import "mod_tab.css";
@import "footer.css";

我们将不同的部分按照一定的顺序去摆放,能让我们的代码看起来更加有序,易于维护,同时,有利于进行继承或层叠覆盖。不要小看这一步,看似可有可无,实际要求比较高的统筹规划能力,可以减少冗余代码和快速定位问题位置等。

除此之外,我们依然可以有其他的方法来帮助我们进行区分代码范围,比如:

1、在文件头部建立一个简要的目录

2、使用区块注释

在注释中,应该尽量详细的写清楚该段代码的目的,状态切换,调整原因,交互逻辑等等,这样不仅利于自己的维护,更加利于别人接手维护你的代码。

  从结论出发

除了需求当中一些通用部分,另外一些也是需要注意,但不会被正式定义的东西,它们来源于我们的实践经验,比如:

  层级嵌套不要太深

稍微了解一些浏览器渲染原理的都知道,它在解析CSS规则的时候,是从右向左,一层层的去遍历寻找,如果层级太多,必然增加了渲染时间,影响渲染速度。另外,如果选择器层级过多,也就间接反应了,你的HTML结构可能写得不够简洁。

那么具体多少层合适?一般建议是不超过4层,但话又说回来,超过4层会怎样吗?不会有多明显的影响,除非你写到很恐怖的数量,或者项目极其庞杂,可能能看出来影响,其实从我们日常需求来看,4层以内足可以解决绝大多数问题,故而,是合理的。

  避免使用元素选择器

出于两点考虑:

  第一点,和上一段提到的相关,在HTML中,有很多常用的高频元素,比如,div、p、span、a、ul等。如果,你在多层选择器的最内层使用了元素选择器,那么,在开始寻找时,浏览器就会遍历HTML中的所有该元素,显然,这是没有必要的。

  第二点,我们的需求和代码结构都是存在着潜在变化的,今天写好了一个页面,明天可能就要再加进去一个按钮, 再加进去一句话,再加进去一个图标。我们写好的一个结构,也随时可能被复用到别的结构中去。所以,如果,你使用了元素选择器去定死某个东西,不论是新加进 来的东西,还是被复用的东西加到别的结构里去,都极有可能产生样式的冲突,这个时候,你又不得不写多余的样式进行覆盖修正,或者重新定义类。

所以,出于以上考虑,在具体的代码模块中,尽量不要使用元素选择器,使用元素选择器的前提是,你完全的确定,不会导致出现问题。注意,我用的限 定范围是“具体的代码模块”,那么用于定义通用规则的样式,是可以的,也是推荐使用的,比如,reset。也可以是别的地方,这就需要我们自行考量。

  避免使用群组选择器

群组选择器会有什么问题?直接上图吧。

图中这种情况不多见,此处只是举个例子,这里写了三组选择器,用来定义不同地方的同一种样式,其明显的缺陷是,如果有第四个地方需要使用到,你 不得不再往里加一组选择器,如果有10个不同的地方,你就写10个?这对于维护来说,是很痛苦的,聪明的我们,怎能被如此繁复又不必要的劳动所困扰,故 而,墙裂不推荐此种做法,完全可以提取出来一个公用类,定义统一样式,然后,哪里需要放哪里,复用和维护都会更加方便。

当然,你可能会说,我在写第一个的时候,不会知道后面还有那么多,有没有必要提取是不知道的,是的,所以,需要你根据经验去判断,也需要在项目推进过程中,适时的对代码进行整理和重构。

  文件引入的数量和顺序

对于刚接触网页的朋友来说,这两点也是容易忽视的,因为它们看起来没什么大影响,多几次请求,样式是否已经加载,都没那么容易把人逼疯。但是出 于对用户体验的极致追求,我们还是希望文件请求次数尽量少,内容的显示有个优先顺序,文件加载有个先后顺序。这样,在实在难以缩减文件大小的时候,让用户 先看到更重要的,正常展示的内容。

以上只是几点举例,更多实战结论,大家可以多读相关的博文或者书籍,都会有前辈们的经验之谈。

  从矛盾出发

  通用和语义

Naming convention is beneficial for immediately understanding which category a particular style belongs to and its role within the overall scope of the page. On large projects, it is more likely to have styles broken up across multiple files. In these cases, naming convention also makes it easier to find which file a style belongs to.

命名规则有助于立即理解一个特定样式属于哪一类,它在页面的整体范围内的作用。在大型项目中,它更可能有在多个文件中被打破的样式。在这种情况下,命名约定也可以更容易地找到一个样式属于哪个文件的文件。

很多时候,我们需要一个东西被定义为通用的,以便复用,比如:模块标题、按钮、提示文字、图标等,最开始的时候,我们习惯去看视觉稿的内容,是 “新闻”,我们就定义“news”,是“关于”,我们就定义“about”,是红色的按钮,我们就定义“red-btn”等,这样会导致一个问题,如果有 另外一个跟新闻列表差不多的样式和结构,但不是新闻,怎么办?继续使用“news”显然不合适,这就告诉我们,不能把目光局限于内容,需要内容和结构分 离。

不能用“news”了,那用什么呢?abc?123?这样总不会冲突了吧,万事大吉~其实,这是走了另一个极端,这样虽然在很大程度上避免了和 别的模块冲突,但其本身的可读性就被大大降低了,别人,甚至你自己过一段时间都会忘记它是什么,对于团队合作是很不利的。至于需要用什么样的命名方式,需 要你根据项目的整体来进行规划,适合根据什么特点来区分与之不同的结构,又能让人比较容易的在名称和结构之间建立联系,比如所属类别、功能、页面等。

  团队和个人

一个团队当中,大家的经历不同,编码水平和习惯也不同,这样就会造成,一个人一个写法,你用中划线,我用下划线;我用英文全拼,你用简写,等 等。这些虽然没有什么对错之分,但对于团队成员之间的协作造成了不小的障碍,别人必须花时间去适应和读懂你是怎样组织和定义的,这就无形之中提高了成本。

所以,就有了“团队规范”存在的必要,规范除了一些写法上的规定,让我们的代码更加统一、清晰、可读性更强、辨识度更高。还可以提取一些最佳实践和复用模块等,对于团队里每个人来说,都是有好处的。

当然,对于人来说,最难的,莫过于调整既有的习惯,这就会有进入一个团队之后“转型”的阵痛,其实这种痛也是成长的痛,你会学习到更好的编码方式,更好的实践方法,会从项目或者团队的整体去考量一件事的价值和意义。

  CSS和预处理器

前面我有文章详细的谈过CSS预处理器,我曾经对它也是排斥的,因为学习成本,因为觉得应用起来没有必要。可是一旦你决定去学习使用它,就会觉 得不是那样,预处理器在向你介绍它自己的时候,就有特意强调过,它的语法是和CSS完全兼容的,也就是说,你在LESS或者SASS文件中,直接写CSS 代码是没有问题的。除此之外,它能给我们提供很多便利,比如定义统一的变量;使用嵌套而不用一直重复着写一些选择器;可以提取公共的代码块然后很方便的复 用等等。

故而,当我们已经把CSS组织和书写得很好了之后,预处理器,就是再次为我们插上一双翅膀,能更灵活和高效的编码。

  从现有模式出发

再来简单看看一些广为流传的模式。(ps:先后顺序与排名、好坏无关)

  一、OOCSS——Object Oriented CSS

接触过计算机的应该都知道,OOP——Object Oriented Programming,如果你是第一次接触OOCSS,你会很困惑,难道是“面向对象的CSS”吗?它不是一本真正的编程语言啊,如何面向对象?

OOCSS,最早被提及,是在2009年,它的两大原则是:

separating structure from skin and container from content.

直译过来就是,结构和皮肤分离,容器和内容分离。

即不要把结构和皮肤以及内容进行强耦合,而是相互独立,所要达到的目标是更易复用和组合,可以选择使用,选择引用等。

详细了解链接:https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/

  二、SMACSS——Scalable and Modular Architecture for CSS

从实践上说,OOCSS给出了一种值得借鉴的思想,但在代码的组织方面,它并未给出具体的实施方法,从这一点上来说,SMACSS更进一步。

它的核心是:

1、Base(基础)

基础的样式,就是一些需要最先定义好,针对于某一类元素的通用固定样式。

2、Layout(布局)

布局样式,是跟页面整体结构相关,譬如,列表,主内容,侧边栏的位置、宽高、布局方式等。

3、Module(模块)

模块样式,就是我们在对页面进行拆的过程中,所抽取分类的模块,这类的样式分别写到一起。

4、State(状态)

页面中的某些元素会需要响应不同的状态,比如,可用、不可用、已用、过期、警告等等。将这类样式可以组织到一起。

5、Theme(主题)

主题是指版面整个的颜色、风格之类,一般网站不会有频繁的较大的改动,给我们印象比较深的是QQ空间,其他应用的不是很多,所以,这个一般不会用到,但有这样一个意识是好的,需要用到的时候,就知道该怎样规划。

有了以上5点分类策略,我们的代码组织起来,思路就会很清晰,会安排的很有序,另外的好处是,可以解决命名难和混乱,之所以有这个问题,主因便 是我们不知道以怎样的标准去定义元素的所属和特点,有了分类之后,我们不会很随意和混乱的去命名,有了依据,就能更轻松,也不易冲突。

详细了解链接:https://smacss.com/

  三、Meta CSS

原子类,也可以称之为“无语义”类,像这样:

它的特点是什么?样式和结构、内容无关,预先定义好这么一组规则,在需要的地方加上即可,我相信每个人第一次看到这种写法的时候,都会想:还能 这样写啊?!是的,总有一些人,一些新的思想和方法会涌现出来,它就是其中之一,当然,并不是在称赞其本身有多么好,而是说这种现象和过程是好的,它本身 经常被人吐槽,比如:“这样写和直接内联有区别吗?”、“如果要调整样式,就要去改HTML,维护更加麻烦,也有违样式和结构分离的初衷”等等,其实我个 人也是不赞成上面这种写法的,如果你要把这些抽离出来,那么还有什么抽不出来的呢?而且这些属性,在项目之间,页面之间,模块之间,并没有太大的通用性, 把这些抽出来,只不过是稍微懒省劲儿些,但为了照顾到更多情况,你必须写入冗余代码,是得不偿失的。

虽然它有缺点,我个人赞成另外的一些东西分出来,比如:浮动(float)、文本布局(text-align)、Flexbox布局等,这些是没有那么多可能性的值,而且使用频繁,复用方便,改动较少,除此之外,你还可以提取另外一些公共的小颗粒类,比如按钮的种类,文字颜色的种类等,这些和CSS本身无关,和项目相关,这就是借鉴其思想,而不是直接拿来用

  四、BEM

严格说来,BEM不是一套有骨有肉的模式,也不仅仅局限你在CSS的层面去规划,它是一种怎样去组织、编写代码的思想,而且,看似简单的它,对前端界的影响却是巨大的。

它的核心如下:

Block(块)、Element(元素)、Modifier(修饰符)

它帮助我们定义页面中每一部分的级别属性,从某种意义上说,也是一种“拆”。命名规则如下:

它的出现,曾给不少人带来启发,但是也有另一部分人仍然抱着挑剔的态度,譬如:

1、风格不统一,显得代码不够整洁美观

2、可能会导致类名过长

还是前面说的,你可以不去直接用它,但要清楚它的优点:能够使得我们仅通过类名就知道哪些代码是属于一个模块内,以及在模块中所起的作用。然后借鉴之。

当然,BEM集聚了很多人的心血,也得到了很多的赞誉,其中就包括OOCSS的作者。所以,它肯定不是这么简单。它还会告诉你,怎样配合着js来写,你的文件怎样组织更好,项目该怎么构建等。详细可以到官网去查阅。地址:https://en.bem.info/

  从实际出发,决定结果的人是你

到底怎样使用设计模式?

虽然已经有成熟的设计模式,但在实际当中,你可能觉得哪个跟自己的项目都不能完全吻合,或者你要去为了使用它们而调整,成本很高。其实,我们不需要去迎合模式,要让模式为我所用,你需要去了解它们背后的原理,要知道它们用什么方式解决了什么问题,然后借鉴之,用它的方式解决我们的问题,就好,这样就不需要作难要不要用,也不需要纠结选哪个,不是简单的说哪个好,哪个不好,总有我们能够用得上它的地方。海纳百川,集百家众长。

我个人一直以来所坚持的另一个观点就是,前端开发的三驾马车——html、css、js,不要,也不能孤立的去谈那样好或者这样好,我们极少会 有只用一次的代码或者模块,也不会只写一种语言,三驾马车都是在一起协作的,都是会有复用、扩展和团队合作多方面的因素在里面。故而,不能抱着这样的想 法:我现在就在做这个,它就是唯一的,就是固定的,没问题。其实很多问题都是潜在的,要带着发展眼光去看待。项目的文件之间,项目之间,团队成员之间,不论你的分工是哪块,都要考虑到前后的影响和可能给合作带来的不便。

怎样才是最佳实践?有“实践”,才有“最佳”,脱离实际情况谈最佳,就是空中楼阁。那么,最好的模式,不是哪个经典的模式,而是在项目进行中, 不断的磨合调整而出的。故而,不需要再惧怕看起来不明觉厉的设计模式,也不需要因为自己还不懂设计模式而郁闷,它就是人们总结出来的实战方法,你也可以有 自己的模式~

结合个人经历总结的前端入门方法,总结从零基础到具备前端基本技能的道路、学习方法、资料。由于能力有限,不能保证面面俱到,只是作为入门参考,面向初学者,让初学者少走弯路。

互 联网的快速发展和激烈竞争,用户体验成为一个重要的关注点,导致专业前端工程师成为热门职业,各大公司对前端工程师的需求量都很大,要求也越来越高,优秀 的前端工程师更是稀缺。个人感觉前端入门相对容易,但是也需要系统地认真学习,在打好基础后坚持学习,成为优秀前端工程师也只是时间问题。

学 习任何知识最重要的都是兴趣,如果经过一段时间的学习感觉不喜欢,那可能强迫自己学习是很痛苦的,效果也不会好,毕竟这很可能就是以后很多年生存的技能。 不过随着互联网行业的发展,前端必然是Web开发人员需要学习的知识,有时候是没有专业前端工程师一起合作的,所以即使不做专门的前端工程师,掌握基本的 前端技能为工作带来方便。

后期邀请了一些同学分享学习经历。如果有同学愿意分享,欢迎push

必备基础技能

前端技能汇总(https://github.com/JacksonTian/fks)这个项目详细记录 了前端工程师牵涉到的各方面知识。在具备基本技能之后可以在里面找到学习 的方向,完善技能和知识面。

frontend-dev-bookmarks(https://github.com/dypsilon/frontend-dev-bookmarks)是老外总结的前端开发资源。覆盖面非常广。包括各种知识点、工具、技术,非常全面。

以下是个人觉得入门阶段应该熟练掌握的基础技能:

HTML4,HTML5语法、标签、语义
CSS2.1,CSS3规范,与HTML结合实现各种布局、效果
Ecma-262定义的javascript的语言核心,原生客户端javascript,DOM操作,HTML5新增功能
一个成熟的客户端javascript库,推荐jquery
一门服务器端语言:如果有服务器端开发经验,使用已经会的语言即可,如果没有服务器端开发经验,熟悉Java可以选择Servlet,不熟悉的可以选PHP,能实现简单登陆注册功能就足够支持前端开发了,后续可能需要继续学习,最基本要求是实现简单的功能模拟,
HTTP

在掌握以上基础技能之后,工作中遇到需要的技术也能快速学习。

基本开发工具

恰当的工具能有效提高学习效率,将重点放在知识本身,在出现问题时能快速定位并 解决问题,以下是个人觉得必备的前端开发工具:

文本编辑器:推荐Sublime Text,支持各种插件、主题、设置,使用方便
浏览器:推荐Google Chrome,更新快,对前端各种标准提供了非常好的支持
调试工具:推荐Chrome自带的Chrome develop tools,可以轻松查看DOM结构、样式,通过控制台输出调试信息,调试javascript,查看网络等
辅助工具:PhotoShop编辑图片、取色,fireworks量尺寸,AlloyDesigner对比尺寸,以及前面的到的Chrome develop tools,
FQ工具:lantern, 壁虎漫步

学习方法和学习目标

方法:

入门阶段反复阅读经典书籍的中文版,书籍中的每一个例子都动手实现并在浏览器中查看效果
在具备一定基础之后可以上网搜各种教程、demo,了解各种功能的实际用法和常见功能的实现方法
阅读HTML,CSS,Javascript标准全面完善知识点
阅读前端牛人的博客、文章提升对知识的理解
善用搜索引擎

目标:

熟记前面知识点部分的重要概念,结合学习经历得到自己的理解
熟悉常见功能的实现方法,如常见CSS布局,Tab控件等。

入门之路

以下是入门阶段不错的书籍和资料

HTML先看《HTML & CSS: Design and Build Websites》1-9章,然后《HTML5: The Missing Manual》1-4章。
CSS先看《CSS: The Missing Manual》,然后《CSS权威指南》
javascript先看《javascript高级程序设计》,然后《javascript权威指南》
HTTP看HTTP权威指南
在整个学习过程中HTML CSS JavaScript会有很多地方需要互相结合,实际工作中也是这样,一个简单的功能模块都需要三者结合才能实现。
动手是学习的重要组成部分,书籍重点讲解知识点,例子可能不是很充足,这就需要利用搜索引擎寻找一些简单教程,照着教程实现功能。以下是一些比较好的教程网址
可以搜索各大公司前端校招笔试面试题作为练习题或者他人总结的前端面试题还有个人总结的面试题(带参考答案)
http://code.tutsplus.com有各种各样的教程
MDN也有很多教程,更重要的是里面有详细的文档,需要查找某个功能时在Google搜索:xxx site:https://developer.mozilla.org
http://www5rocks.com/zh/也有很多优质教程
http://www.sitepoint.com/
http://alistapart.com/
原生javascript是需要重点掌握的技能,在掌握原生javascript的基础上推荐熟练掌握jQuery,在实际工作中用处很大,这方面的书籍有《Learning jQuery》或者去jQuery官网
建一个https://github.com/账号,保存平时学习中的各种代码和项目。
有了一定基础之后可以搭建一个个人博客,记录学习过程中遇到的问题和解决方法,方便自己查阅也为其他人提供了帮助。也可以去http://www.cnblogs.com/或者http://www.csdn.net/这样的网站注册账号,方便实用
经常实用Google搜索英文资料应该经常找到来自http://stackoverflow.com/的高质量答案,与到问题可以直接在这里搜索,如果有精力,注册一个账号为别人解答问题也能极大提高个人能力。
经典书籍熟读之后,可以打开前面必备基础技能部分的链接。认真读对应标准,全面掌握知识

继续提高

有了前面的基础之后,前端基本算是入门了,这时候可能每个人心中都有了一些学习方向,如果还是没有。 可以参考前面必备技能部分提到的那两个项目,从里面选一些进行发展学习。以下是一些不错的方面:

Grunt:前端自动化工具,提高工作效率
less css:优秀的CSS预处理器
bootstrap:优秀的CSS框架,对没有设计师的团队很不错,与less结合使用效果完美
requirejs:AMD规范的模块加载器,前端模块化趋势的必备工具
Node.js:JavaScript也可以做后台,前端工程师地位更上一步
AngularJS:做Single Page Application的好工具
移动端web开发:智能手机的普及让移动端的流量正在逐步赶超PC端
Javascript内存管理:SPA长期运行需要注意内存泄露的问题
High Performance JavaScript(Build Faster Web Application Interfaces)
Best Practices for Speeding Up Your Web Site:重要技能

一些个人经历

LingyuCoder的学习经历

上面的大神都总结得差不多了,我这里就胡扯一些吧

工具

chrome dev tools:前端开发调试利器,着重注意几个功能:
console(废话)
elements:元素样式调整,很常用
sources:代码中添加断点,单步调试,以及单步调试过程中查看内存中的对象
watch expression:通过表达式查看当前内存中的值
call stack:查看调用栈,开启async,可以看异步调用栈(这个非常有用,尤其是ajax调试的时候)
scope variables:作用域链上的变量,非常有用
network:抓包查看每个请求,非常重要,前后端联调必备
timeline:分析渲染、js执行等等各个阶段,性能优化利器
emulation:模拟移动端环境,mobile页面开发必备
一些插件:
liveload: 修改页面后自动刷新,不用按F5
dimensions:直接在页面上测量的利器
livestyle:css样式修改后自动起效果,不需要刷新,elements修改后也能同步到代码中
image tool:测量,取色
UC二维码:移动端调试扫码必备
pagespeed,YSlow:页面性能分析和优化插件
马克飞象:优秀的在线markdown编辑器,快速写周报,做记录
sublime text2:编码方便,插件多,速度快,性能好
emmet:提升html编码速度必备
sublimelinter + 各种语言的lint和hint:代码纠错
一些snippets:自动补全,提升开发效率
Intellij IDEA和WebStorm:集成开发环境,集成了各种功能,开发比sublime要方便,但会比较吃性能
Mark Men:测量、取色、标注利器,拿到视觉稿之后第一个打开的软件
GFW Fucker:我用红杏,可以的话买个虚拟服务器当梯子
iHosts:非常优秀的hosts管理软件,轻松修改hosts,开发调试必备
Charles:Mac 平台最好用的抓包分析工具
Rythem:AlloyTeam出品的代理抓包软件,非常轻量,安装简单,移动端(真机)开发调试很好用
Wunderlist:一个非常不错的Todo List,任务、需求多的时候管理起来很方便

技能

前端的技能其实除了JavaScript(包括NodeJS)、HTML、CSS以外,还有很多。其实前端的技能树很大,这里只能列一些我开发中见到的说一说

语言基础

JavaScript:

作用域链、闭包、运行时上下文、this
原型链、继承
NodeJS基础和常用API

CSS:

选择器
浏览器兼容性及常见的hack处理
CSS布局的方式和原理(盒子模型、BFC、IFC等等)
CSS 3,如animation、gradient、等等

HTML:

语义化标签

进阶

JavaScript:

异步控制(Promise、ES6 generator、Async)
模块化的开发方式(AMD、CMD、KMD等等)
JavaScript解释器的一些相关知识
异步IO实现
垃圾回收
事件队列
常用框架使用及其原理
jQuery:基于选择器的框架,但个人认为不能叫框架,应该算工具库,因为不具备模块加载机制,其中源码很适合阅读钻研
AngularJS/Avalon等MVVM框架:着重理解MVVM模式本身的理念和双向绑定的实现,如何解耦
underscore:优秀的工具库,方便的理解常用工具代码片段的实现
polymer/React: 组件化开发,面向未来,理解组件化开发的原理

CSS和HTML:主要是CSS3的特性和HTML5的特性,以及浏览器处理的流程和绘制原理

DOM树、CSSOM树、渲染树的构建流程及页面渲染的过程
解析HTML、CSS、JavaScript时造成的阻塞
HTML5相关
SVG及矢量图原理
Canvas开发及动画原理(帧动画)
Video和Audio
flex box布局方式
icon fonts的使用

常用NodeJs的package:

koa
express
underscore
async
gulp
grunt
connect
request

一些理念:

响应式Web
优雅降级、渐进增强
dont make me think
网页可用性、可访问性、其中的意义
SEO搜索引擎优化,了解搜索引擎的原理
SPA的好处和问题

性能优化:

减少请求数量(sprite、combo)
善用缓存(application cache、http缓存、CDN、localstorage、sessionstorage,备忘录模式)
减少选择器消耗(从右到左),减少DOM操作(DOM和JavaScript解释器的分离)
CSS的回流与重绘

项目

版本管理:首推Git,用过Git都不会想用SVN了
Git:本地版本管理的机制
SVN:远程中心的版本管理机制
自动化构建:主要就是less、模板、coffee等的预处理以及对代码压缩和合并
Gulp:基于流构建,速度快、模块质量好
Grunt:独立任务构建,速度慢,配置蛋疼,灵活性高
预处理和模板引擎
less:语法简单,但功能有限
jade、ejs、velocity等模板引擎,各有各的长处
coffee:python工程师最爱,我没用过
环境搭建:主要是将线上代码映射到本地,并在本地启动一个demo服务器,至于模拟数据的mock,见仁见智了
本地代理:ihosts
自动化测试:在业务较为稳定的情况下,可以通过自动化测试来减少测试的事件,但需求较多的时候,维护测试用例的成本会很高,可能用自动化测试会起到反效果
jasmine
mocha
生态系统
npm
bower
spm
搭建一个属于自己的博客
git pages
hexo
jekyll

未来

Web Componets:面向未来的组件化开发方式
HTML模板
Shadow DOM
Custom Elements
HTML Import
移动端Native开发:这也是需要了解的,以后前端工程师会经常地和webview打交道,也要了解native开发

其他

有些东西不是考敲码就能弄好的,我参与实习的时候感受到了很多,这些是我遇到的也是我感觉自己做的不好的地方

对于业务的思考:我个人这方面非常欠缺,所以放在最前面,在敲码前要多思考业务
交流和沟通能力:这个非常重要,前端同时需要与项目经理、产品、交互、后台打交道,沟通不善会导致很多无用功,延缓项目
知识管理、时间管理:input和output的平衡,output是最好的input。如何做好分享,参与社区,做好交流,作好记录
对新技术的渴望,以及敢于尝试

入门书

入门可以通过啃书,但书本上的东西很多都已经过时了,在啃书的同时,也要持续关注技术的新动态。这里推几本我觉着不错的书:

《JavaScript高级编程》:可以作为入门书籍,但同时也是高级书籍,可以快速吸收基础,等到提升再回来重新看
《JavaScript权威指南》:不太适合入门,但是必备,不理解的地方就去查阅一下,很有帮助
《编写可维护的JavaScript》和:
《Node.js开发指南》:不错的Nodejs入门书籍
《深入浅出Node.js》:Nodejs进阶书籍,必备
《JavaScript异步编程》:理解JS异步的编程理念
《JavaScript模式》和《JavaScript设计模式》:JavaScript的代码模式和设计模式,将开发思维转变到JavaScript,非常好的书
《JavaScript框架设计》:在用轮子同时,应当知道轮子是怎么转起来的,讲解很详细,从源码级别讲解框架的各个部分的实现,配合一个现有框架阅读,可以学到很多东西
《Dont make me think》:网页设计的理念,了解用户行为,非常不错
《CSS禅意花园》:经久不衰的一部著作,同样传递了网页设计中的理念以及设计中需要注意的问题
《高性能JavaScript》和《高性能HTML5》:强调性能的书,其中不只是性能优化,还有很多原理层面的东西值得学习
《HTML5 Canvas核心技术》:我正在读的一本书,对于canvas的使用,动画的实现,以及动画框架的开发都非常有帮助
《HTTP权威指南》:HTTP协议相关必备,前端开发调试的时候也会经常涉及到其中的知识
《响应式Web设计》:技术本身不难,重要的是响应式网页的设计理念,以及移动先行的思想
《JavaScript语言精粹》:老道的书,也是普及JavaScript的开发思维的一本好书,非常适合入门

一些不错的网站

github:没啥好说的,多阅读别人的源码,多上传自己的源码,向世界各地的大牛学习
codepen:感受前端之美的必选之地,里面有很多酷炫的效果和优秀的插件
echojs:快速了解js新资讯的网站
stackoverflow和segmentfault:基本上各种问题都能在上面获得解答
google web fundamentals:每篇文章都适合仔细阅读
static files:开放的CDN,很好用
iconfont:阿里的矢量图标库,非常不错,支持CDN而且支持项目
html5 rocks: 一个不错的网站,很多浏览器的新特性以及前沿的技术,都能在这上面找到文章
css tricks:如何活用CSS,以及了解CSS新特性,这里可以满足你
JavaScript 秘密花园 JavaScript初学必看,非常不错
w3cplus:一个前端学习的网站,里面的文章质量都挺不错的
node school:一个不错的node学习网站
learn git branch:一个git学习网站,交互很棒
前端乱炖:一个前端文章分享的社区,有很多优秀文章
正则表达式:一个正则表达式入门教程,非常值得一看
阮一峰的博客和张鑫旭的博客:快速了解某些知识的捷径,但是如果需要深挖,还需要其他的资源
各路大牛的博客:这个太多了,就不贴了,知乎上有很全的
各种规范的官方网站,不懂得时候读规范

历程

以 前是做Java SSH的,半路出家做的前端,所以水平比较弱,遇到问题也比较多。基本上入门靠看书和W3C School上的教程,以及一些前端博客,如汤姆大叔的博客。以前也只是使用jQuery,原生js也没有太多的钻研,后来逐渐看了很多本动物书,比如老 道的语言精粹等等。从这些书中学到了很多语言层面的知识。但这显然是不够的,所以我经常会去社区上看看大家在谈论什么,然后去看看相关的资料,感兴趣就会 多找些资料看看,或者写一写demo。学CSS主要就是通过这种方式。后来开始更多的关注各路大牛的博客和一些比较深的书籍,以及关注一些新的知识和框 架,并且不断地练手提交代码到github,这样也学到了很多知识。在实习的过程中,切身参与到实际项目开发之中,能学到很多在学校学不到的理念和思维, 这点也有很大的帮助。不说了,我要去搬砖求offer了…

MrRaindrop的学习经历

应qiu神的邀请分享一下前端 学习经验,这里对前端知识体系架构就不做总结了,各位大神们的总结已经相当到位了,我就贡献几个个人认为还比较有用的链接大家研究研究就好,然后主要分享 一下我在前端学习过程中遇到的问题和总结的经验教训吧,如果能帮到想要入门的FE初学者(我就姑且假定为本文的读者受众类型了),让他们少走点弯路,每走 一步都知道自己下一步的方向,这是最好了。各位大神的总结和分享详见qiu神整理的FE-learning。

先说下,前端这个东西每个人都可以有适合自己的学习方法,这篇仅作参考,写的有点乱,各位凑合看。

缘起

我 是属于误打误撞进了前端,之前一直往做游戏的方向去来着,搞过游戏网站,玩过游戏引擎,比如unity,unreal这种商业引擎,捣鼓了几个游戏原型, 不过自打研一进了实验室,直接就被导师派去写了js,导师给了我半个月时间让我写个基于百度地图api的数据展示页面,虽然这个时间还是相当宽裕的,不过 之前没怎么写过js,也不会用地图api,于是我就一边啃着《Javascript权威指南》(犀牛书)一边参考实验室前人留下的“代码”,总算是把功能 都写出来了。那个页面算我的js入门作了,也是我前端学习路线的开始。

现在想来,虽然指派了去做前端,但是一直做下去并做好还是得靠兴趣维持,当然前端是一个趣味性十足的技术领域,而且社区每天都很“热闹”。

项目,下一个项目

我 个人认为前端的学习,初学阶段你可以完全脱离开书本,以项目驱动。虽然我个人是从犀牛书开始啃的,不过如果你没有充足的时间,或者觉得啃大部头乏而无味的 话,还是别像我这样。当然了如果决定啃书最好是把书里的例子都跟着敲一遍的。我上研之前没接触过js,4月份还没开学呢就被直接被导师甩了个百度地图 api的项目到脸上,接着就是各种ERP,地图数据展示,虽然换着花样来一点不重样,不过基本上都是前端的活,SSH和android开发也打过酱油,整 个实验室就我一个人写前端敢信?富客户端SPA时代的后端就是一个restful接口,代码量基本都在前端啊,写的我一个人怎一个爽字了得…期间跟着导师 感受了一把创业,每天从7点搞到晚上10点,也算是经历了一段快速成长期。

掌握一门技术先掌握它的大体框架,想一个能实现的点子,做一个 能跑就行的demo,再去完善它的细节,等到demo完成了,对这门技术有了一个感性的认识,再去啃书,收获会大很多。我从开始原生js写到 jquery,再到extjs,再到angularjs,从导师指定技术,到自己做技术选型,一个项目接着一个项目的练,就跟打怪升级似的。当然没有项目 就去自己创造项目,动手实现自己的想法是件有乐趣和成就感的事。

收集癖和知识管理

前端学习有个特点,很多东西都很零碎, 分散,需要你自己去整理、归纳和总结。在微博、知乎上follow了众多的大神,你不仅仅是为了听八卦,大神们的只言片语有时候留下的是无尽的余味,很有 可能一个不经意提到的一个词就成为你下一个学习的目标。收集这些信息,善用google,提问,思考。就像游戏里的收集要素,前端学习也是充满搜集要素的 一个“游戏”,只不过你需要一个知识管理工具来充当物品栏和仓库,我所知道的大牛们无一不是知识管理工具的重度使用者。以前用的oneNote,那时候还 没绑定到云存储,现在基本上用evernote,笔记已经累计到1200+篇。书签一直打算用delicious,因为它是基于tag管理的,但一直没用 起来。当然重点不在于这些工具,但是趁手的工具可以提高你的学习效率。最关键当然是随时保持旺盛的学习欲望,你的目标是了解有关前端的一切(当然不是所有 都要掌握,因为毕竟你的精力有限,而且现实的说这也不太可能)。

跟对神

这个可控性貌似不大…跟对老大这个就不多说了,一 定程度要看造化。不过话说回来,多跟身边的高手交流是王道,这个高手不一定要多高,但是一定要对技术有热情。研一的时候热情高涨,每天7点进实验室门,然 后发现有个家伙居然比我还早到。后来发现这家伙上午就走了,下午又来了,而且导师对此习以为常,原来这家伙晚上不睡觉通宵写代码,上午才跑回去睡。后来经 常和这位神讨论问题,每次感觉经验值蹭蹭蹭的往上涨。然后实验室还有一位神,被前面这位通宵神形容为“只能望其项背,一直在追赶,从来没赶上”,两位神的 特点都是什么都了解一点,所以什么都能跟你讨论得起来,我有段时间做了个读书计划,从c/c++到vc/mfc再到unix网络编程,最后一路看到 java核心技术和MSDN上的C#编程指南,和神们也能扯得很high了。

总之就是这两位神把我拉进了坑,或者说从一个坑跳进另一坑,虽然两位神都不是搞前端的,不过技术之间总有相通之处。

读书

读 书,多读书,读好书。在刘未鹏的博客里看到过一个公式,你第一个月的工资等于之前买过(读过)的技术书价格总和(这里说的技术书指那些经典的公认的好 书)。讨论这个公式的正确性似乎没什么意义,然而它的合理性是毋庸置疑的,那就是多读经典技术书。最极端的一个例子,google的徐宥在我的大学里面说 他扫荡了图书馆的整个TP312书架…对于前端的经典书籍,后面列了一个我收集的前端书列(如果有遗漏的前端经典好书,还请留言告诉我),有条件可以尝试 刷一遍这些书,我也是在找完整的时间去啃完它们。之前说的,前端知识点松散,收集零散的知识点,从博客里快速学习等,这些只是前端学习的一个方面,如果你 要想深入理解一个知识体系,了解它的来龙去脉,对它建立系统认识,读经典书还是必不可少的。

我从最开始啃完犀牛书,然后接着去看了其他一 些和前端干系不大的经典技术书,再后来通过实验室的项目和自己弄的一些小项目逐渐对前端领域比较上路以后,又看了《Javascript模式》、 《Javascript设计模式》、《编写可维护的Javascript》,后来了解到node并开始用node搞点小玩意儿,又看了本《NodeJS up and run》和《Mongodb权威指南》,不过感觉前者略坑。那会儿朴灵那本深入浅出(晒书么么哒)还没出,后来出了就去图书馆借来看完,这么看下来感觉还 不错,不过感觉看的还是偏少了,还需要继续刷(参照上面的书列)。

前端的定位

前端的定位关乎到你需要吸收什么样的知识和 技能,决定在技术世界里你对什么需要格外敏感。如果你认为前端仅仅停留在切页面,实现交互和视觉的要求,那你对前端的认识还停留在初级阶段。阿里终面的时 候我问了考官这么个问题:前端技术日新月异,范围越扩越宽,标准越来越丰富,似乎任何一个触角都能伸出很远。怎么给前端一个合适的定位?考官给我分析了半 天,然后总结成一句话,就是用户和网站的联结者,用户体验的创造者(原话不是这样,但大体是这个意思)。也就是说前端的终极目标其实就是创造用户体验,提 升用户体验,以用户体验为中心。不管你是从交互设计上下手,还是从性能优化出发,或者改进工作流提升工作流效率,最终都是为了创造和提升用户体验,最终都 要体现到用户体验这一点上来。我认为这个总结非常有道理(当然“用户体验”这个词太宽泛了,并且不仅仅是前端工程师的范畴,比如开发后台的时候对一个数据 处理过程进行优化,提升了整体性能,这也是对用户体验的一个提升)。

现在的前端工程师做到一定阶段不可避免会接触到很多比切页面、实现视 觉要求、实现交互等更深入的问题,比如前端自动化、图像编程、性能优化等等,再往后推一点就是PHP/JSP/ASP/nodeJs,过去后端模板一般属 于后端的范畴,现在随着前端架构的演进,可能会让你去写后端模板的代码,需要用到后端语言(PHP/Java/C#等),这就是所谓大前端(然而这与前端 的定位并不是相背离的,大前端处理的依然是与用户接触的部分,仍然是对用户体验的优化)。可能最常见或者被谈论最多的就是node,其实这几种技术选型都 可以,bat三家据说百度用PHP比较多,阿里用node比较多。

玉伯在他的博客里提过所谓全端是横向的,全栈是纵向的。全端即所有的终 端说白了都是前端,因为都关乎到用户体验,直接和用户接触。适应多终端的开发,要求你在web前端的基础上,可能还要去扩展android开发和ios开 发的知识,好在由于hybrid开发方式的流行,对使用native语言开发的技能会要求的不那么深入。

全栈可以说是最适合初创公司的一 种发展类型,广义上认为是从前端干到后端,从开发干到运维,这种就不说了,一般人应该不会想要去往这个方向发展,想要成为这种意义上的full- stack dev的,可能用不着来看我这篇文章了;而狭义上的全栈特指使用js语言从前端写到架设在nodeJs上的后端,前后端统一语言,统一编程模型,甚至公用 同一套代码。更多了解全栈开发可以看看玉伯这篇说说全栈工程师。

以上是我对前端以及衍生出来的技术路线的一些浅薄理解,学习一个领域掌握它的整体上的走向和趋势还是挺重要的。另外如果想要对前端学习方向、职业成长路径有一个整体的认识,推荐看看拔赤总结的这篇前端开发十日谈。

最后

贡献几个对前端学习、面试有帮助的链接:

前端面试问题合集(Front-end-Developer-Interview-Questions)(https://github.com/darcyclarke/Front-end-Developer-Interview-Questions)
前端技能汇总(JacksonTian)(https://github.com/JacksonTian/fks)
另一张前端技能汇总图(http://www.f2er.info/)
前端那点事儿(书列)(http://book.douban.com/doulist/13701898/)

byr论坛yiyizym的建议

与grunt相比,学习gulp会比较简单

做SPA的话,推荐backbone.js和 backbone.marionette.js

FQ不用折腾,花十块钱买一个月的 红杏。

把基础打扎实了再学这些都没问题。

html 没什么好说的,有空学学html5。

css 尽量看文档 ,因为很多中文资料都各执一辞,看多了反而会糊涂。

有个网站可以查找html/css标签、属性在各个浏览器中的支持情况,挺好用的。

javascript 就看 javascript高级程序设计 。不过这么厚的书看过就会忘。对javascript核心概念的讲解:对象/原型链/ 构造函数/执行上下文/作用域链/闭包/this,这里有篇不错的文章。

有闲情可以看看 ecmascript 6,计划明年6月就发布啦。阮一峰的网站有入门资料。

jquery 有很多 API,这个网站可以方便查到。有时间弄清楚jquery deferred 的用法。

多给 sublimetext 装插件,比如说检查代码错误的,新建目录文件的,整理代码的。

Bootstrap的CSS Class

 

Bootstrap需要.container内中放置定位或是布局的元素,网格系统的元素同样需要放置的.container类中。

.container

响应式固定宽度容器,所展示的宽度在每种设备上都不一样。在大尺寸的设备上,宽度会更大,margin和padding也会更大。

.container-fluid

全宽容器,根据设备的view-port尺寸来铺满设置。

 

12网格系统

响应式移动优先流动网格系统

  1. 网格系统使用行和列来控制内容的排版。
  2. Row需要放置在container类容器中
  3. 使用Row创建水平的列组(Group of columns)
  4. 预定于的.row.col-xs-4可以快速设置网格布局
  5. 列会通过padding创建网格间隙(gutters),首列和尾列的padding会被row的负margin所抵消
  6. The negative margin is why the examples below are outdented. It’s so that content within grid columns is lined up with non-grid content. (有待进一步理解)
  7. 网格元素所占的列有元素class所定义,比如一个row等宽三列布局下,.col-xs-4定义元素为column,适配设备为小型设备(xs -> extra small),列占用网格12列中的4列
  8. 如果一个row中元素加起来所占的column超过12,则每组超出的元素都为作为一个单元换行放置。
  9. 111

网格选项

手机(<768px) 平板(≥768px) 显示器(≥992px) 大显示器(≥1200px)
布局模式 总是水平 水平方式,超出断点下置
容器宽度 None (auto) 750px 970px 1170px
Class前缀 .col-xs- .col-sm- .col-md- .col-lg-
# of columns 12
12列单列宽度 Auto ~62px ~81px ~97px
列间隙宽度 30px (15px on each side of a column)
是否可以包含子元素Nestable Yes
列间隙抵消offset Yes
列顺序设置 Yes

 

// Add tooltip for product gallery
            var h2TitleObj = $('.node-type-structure-product h2'),
                productImageGalleryTop = $('.product-gallery').offset().top,
                productImageGalleryLeft = $('.product-gallery').offset().left;
            //console.log(typeof productImageGallery.offset().top);
            //console.log(typeof productImageGallery.offset().left);
            $.each(h2TitleObj, function (key, value) {
                if (this.innerHTML.trim() == "Images") {

                    //$(this).addClass('tooltip-active').attr('tooltip-attr','Click to see large image');
                    /*
                     $(this).tooltip({
                     show: { effect: "blind", duration: 800 },
                     content: "Click to see large image",
                     });
                     */
                    $(this).attr('tooltip-attr','Click to see large image').tooltip({
                            //show: { effect: "blind", duration: 800 },
                            content: "Click to see large image",
                            items: "[tooltip-attr]",
                            position:  {
                                //my: "left top",
                                //at: "right center",
                                collision: "none",
                                //of: ".product-gallery",
                                //within: ".product-gallery",},
                                using: function () {
                                    $(this).css({top: productImageGalleryTop+"px", left: productImageGalleryLeft+"px"});
                                },
                        },
                    });

                    $(this).tooltip("open");
                }
            });

 

为了满足SEO的要求,很多时候我们不得不将表格改造为更加Search Engine Friendly的unordered list或是ordered list,但是在网页的页面上,我们更希望列表是以表格的形式展现给用户的,这样方便用户的阅读,满足用户体验的要求。

CSS的display table相关的属性可以满足这样的设定。

Display table需要有着和表格html结构类似的markup,其实不严格按照table的markup结构也是可以渲染的。有人说,如果不按照table的markup,就不符合W3C的规范,关于这一点我不是很认同。我认为css只是改变了部分html的渲染方式,而这一点恰恰是W3C希望大家去尝试的,即不修改html结构的基础上改变html的渲染方式。

闲话少说,上代码

<ul class="table-row-wrap">
	<li class="table-row">
	<ul class="tables-cell-wrap">
		<li class="table-cells">Cell1</li>
		<li class="table-cells">Cell2</li>
		<li class="table-cells">Cell3</li>
	</ul>
	</li>
</ul>

其实上面没有完全按照table相似的html来构造,按照表格显示很简单

    .tables-cell-wrap{
      display: table;
      width: 100%;
    }
    .table-cells{
      display: table-cell;
      width: 33%;
      border-right: 1px solid #cccccc;
      text-align: center;
      vertical-align: middle;
      padding: 0.8em 1em;
    }

注意,如果将table-row-wrap设置display:table,再将tables-cell-wrap设置display:table-row,然后设置table-cells为display:table-cell, 这个时候,ul.tables-cell-wrap会出现不能铺满container的情况,这个现象可能和html本身的结构有关系。