你多久没有读完一本技术书了?
你是否列了长长的待读书单,却迟迟没有行动?
你是否每逢购物节,就血拼了一堆回来?
又或者你觉得一个人读书太过枯燥?
如果你是,那从现在跟歪马一起,歪马陪你一起云读书。
歪马会选一本技术类书籍,每 2~5 天学习并总结一个章节供大家一起围观,欢迎大家监督共进,后期大家可以推荐选材,内容局限于前端周边 ????。
引自图书原文
人类天生好奇,喜欢摆弄东西。那天在办公室收到了新的遥控四轴飞行棋 Parrot AR Drone,我们都没有看说明书,就开始动手组装起来。我们喜欢自己琢磨,喜欢按照自己认为的事物运作方式来思考和解决问题。零件只要能拼上就行,除非拼不上了,或者事实跟我们的想法相背离,才不得已去翻翻安装指南。
通过动手练习来学习一项新的技术是很好的方式,但是如果对整体的概念没有一个清晰的了解就很容易犯错或者给自己挖坑。
很多人对于 CSS 的学习就是这样,通过很多生动有趣的例子学习了 CSS 的知识,却没有系统地去了解过。这一点笔者在招聘面试的过程中就深有感触,很多同学都表示掌握 CSS,但是在对一些基本概念进行发问的时候,往往答得并不理想,甚至可以说有点差。给出的理由多是会用但是没有系统地学习过,或者之前看过忘记了,又或者很久没有用了。
诚然,在框架盛行的今天,我们不用学 CSS 也能够写出还算“过的去”的页面。但是作为前端开发,这不是我们不学 CSS 的理由,我们不仅要学,还要系统一些地学。只有系统地学习 CSS,你才会规避一些奇奇怪怪的问题,才会在逐渐的深入中明白 CSS 的魅力所在。
《精通 CSS - 高级 Web 标准解决方案(第 3 版)》一书就会很系统地给大家介绍了 CSS 并且会有很多实用的实践,会带领大家领略 CSS 的美丽,帮助大家更有效地使用 CSS。
精通CSS - 高级Web标准解决方案(第3版) 封面图好了,废话不多说,进入正文,开启《精通 CSS》云陪读之旅。
笔者会按照原书的内容结构阅读并总结,也会适当地加入自己的见解与大家一起分享。
代码可维护性的重要性就不赘述了,相信大家都知道代码是要可读、可维护的,毕竟俗话说的好:“你的代码是给人读的,而不是给机器读的。”
CSS 是随着代码量增加而最难保持可维护性的语言之一。即使网站规模不大,样式表也会很快变得不可控制。
不过 CSS 也在不断地弥补这一问题,逐渐引入了变量、方法等。不过在兼容性方面可能还存在一些问题。
比较推荐的是使用CSS 预处理器,如 PostCSS、LESS、SCSS。这些预处理器基本都支持变量、运算、函数、自动前缀等功能。能够使我们更好地维护 CSS 代码。
此外,还推荐大家选择并使用一种 CSS 方法论,如(BEM[1],OOCSS[2],SUIT[3],SMACSS[4],ITCSS[5],Enduring CSS[6]等)。使用统一的方法论能够帮助大家形成统一的风格,维护很好的代码结构,如果你还没有使用,就赶快用起来吧。
身为前端,我们应该都听过这个。前端三宝,HTML 负责结构,CSS 负责样式与表现,JavaScript 负责逻辑控制。其实这是经过一定的发展和沉淀之后所形成的较好的实现。
在 1990 年,Tim Berners-Lee 发明 HTML 时,主要是为了规范科研文档的格式。这时 HTML 是一个简单的标记语言,为文档赋予了基本的结构和意义,包括如标题、列表、定义等标签。
由于人类是视觉发达的生物,随着发展,出现了更多对于展示效果的支持,如粗体、斜体等。这逐渐造成了元素的滥用,原本用于展示数据的表格(table)却用来布局,块引用(blockquote)被用来缩进文本等。
CSS 就是在 HTML 被滥用之后诞生的,它把 HTML 中表现性的标记提取出来,自成体系,从而达到了结构与表现分离。
这之后 CSS 和 HTML 分别迅速发展
CSS:
CSS1 在 1996 年成为 W3C 推荐标准,当时只包含字体、颜色、外边距等基本属性。
CSS2 在 1998 年成为推荐标准,增加了浮动和定位等高级特性,以及子选择符、相邻选择符和通用选择符等新选择符。
CSS2.1 在 2002 年发布,在 2011 年才成为推荐标准,主要修正了一些 CSS2 的错误,删掉了兼容性不好的特性。(战线很久,主要是因为 CSS3 制定周期太长,进度缓慢)
后来 CSS3 采用了完全不同的模式,由于 CSS 日渐庞大,所以分成了一系列级别独立的模块。如果某模块是对之前版本内 CSS 概念的升级,则从 3 级(Level 3)开始命名,如果是新的技术,则从 1 级(Level 1)开始命名。不同的模块进展单独控制。
HTML:
HTML 经历过 4.01 版本,之后衍生出了 XHTML1.0,但由于其过于严格,无法落地,最终被抛弃了,直至最后形成了现在为大家所熟知的 HTML5
个中发展较为复杂,大家有兴趣可以看原文,或者网上搜一下,这里就不搬啦。
另外,大家需要知道一下,HTML 的标准由WHATWG(Web Hypertext Application Technology Working Group,Web 超文本应用技术工作组)制定。
在 CSS 不断发展的过程当中,逐渐引入了越来越多的功能强大的特性。我们往往深受其吸引,想要用之而后快。但是在尝鲜新特性时,我们要牢记一个概念:渐进增强与向后兼容。
所谓渐进增强,就是“首先为最小公分母准备可用的内容,然后再为支持新特性的浏览器添加更多交互优化”。
HTML 和 CSS 语言天生具备渐进增强与向后兼容的特性。
在 HTML,当新定义的input
类型,如email/number
,如果浏览器不支持,会使用默认的text
类型进行展示。
在 CSS 中,针对不能识别的特性,CSS 会直接忽略,而不会报错,所以只要在使用新特性同时,提供后备属性(新属性在后,后备属性在前),则不会有任何不良效果。
有了渐进增强,我们在使用新特性的同时又不会影响旧版本的浏览器。何乐而不为呢?
可以通过以下几种方式来实现渐进增强。
不同厂商会引入针对自己浏览器适用的实验性特性。这些特性通常在规范中并没有或者尚不成熟,但是通过这一方式,我们可以安心的试用这些元素。
通常,不同的浏览器会给这类特性在前面加一个特殊的前缀。如-webkit-
开头的适用于基于 WebKit 的浏览器,如 Safari/Chrome/Opera;-moz-
适用于 Mozilla 的浏览器,如 Firefox;-ms-
适用于微软的 IE。
值得高兴的是,你不知道这些前缀也没关系,因为如果你用了前面提到的预编译语言,会有通用的插件可以协助我们完成前缀的自动添加,如 autoprefix。
如果希望根据浏览器对于某 CSS 特性的支持情况来提供不同的样式,则可以选择@supports
块。这个特殊的代码块称为条件规则,它会检测括号中的声明,且仅在浏览器支持该声明的情况下,才会应用该声明。
如下:
@support (display: grid) {
/* 在支持网格布局的浏览器中应用的规则 */
}
忧伤的是,条件规则最大的问题就是它本身也是非常新的特性,支持度并不高。
除了 CSS 的条件规则,我们还可以通过 JavaScript 来检测 CSS 特性的支持情况,如使用Modernizr这个库。
HTML5 之后引入了语义化标签的概念,在这之前,为了提高代码的可读性和可维护性。我们可以通过为标签添加 class 属性来提高标签的含义。有了语义化标签后,class 属性可以单纯地作为样式的接入点,更好地描述标签的分类即可。
ID 主要用于在文档中标识标签,通常不用于添加样式。
不同的元素有着特定的含义,语义化标签是指在正确的地方使用正确的元素,从而创建有意义的文档。
有语义的标签可以确保更多的人能够使用,不管是最新的 Chrome,还是 Lynx 这样只能处理文本的浏览器,甚至是屏幕阅读器或盲文点触设备。另外,有语义的标签页更容易被机器识别,如搜索引擎爬虫,可以提高页面搜索的准确性和排名。
笼统的来说,除了div/span
这两个无明确语义的元素以及b/i
这类被保留下来的表现性标记,其他的元素都可以称为语义化标签。
只要元素有明确的语义就叫做语义化标签,如常见的p
是段落的意思,ul/ol
表示无序列表和有序列表。
关于各标签元素的具体用法,大家可以参考http://html5doctor.com/[7]进行详细学习。
HTML5 元素索引,来源:http://html5doctor.com语义化标签在多数浏览器中使用是没问题的。但 IE8 及之前的版本不会给自己不认识的元素应用格式。这时我们需要借助 JavaScript“腻子”或者说“垫片”来解决,可以使用:https://github.com/afarkas/html5shiv[8]。
最后,虽然推荐使用有语义的标签,但是在确实没有语义的情况下,还是要使用div/span
,一个用于块级元素,一个用于行级元素。如一个元素只用作多个元素的包装元素时,可以用div
。
还记得那个经常被问到的问题吗?
strong
和em
的区别是什么?它们都表示强调,但是
em
表示内容的强调,会改变句子的含义。类似于语言中的重读,如“你和我到办公室走一趟”和“你和我到办公室走一趟”。strong
表示重点强调,表示强烈的重要性、严重性或内容的紧迫性。这个强调不会改变句子的含义。
除了 HTML 标签本身具有的语义外,web 开发者还通过其他方式拓展了 HTMl 的语义。
其中之一就是现在备受重视的无障碍访问。我们可以利用无障碍富因特网应用(ARIA,accessible rich Internet application),为不同的标签添加role
角色属性。如banner/form/main/search/navigation
等,可以供辅助访问设备使用。
其次应用比较广泛的是微格式,它主要是基于 iCalendar 和 vCard 等已有数据格式。就是会使用一些广泛应用的数据格式,来表示某些有语义的内容。类似于组件的概念。
最后,还有一种扩展是微数据,它与微格式不同,它可以用来标识任意类型的数据,只会定义一些语法来表示数据结构,可以通过这些语法组成不同的结构。类似于一类定义格式的语法,而微格式则是具体的结构化数据。
如果你对自己的 HTML 代码是否语义化不够自信,或者对自己的 CSS 代码是否有误不能确认,那么你可以使用相对应的验证器来进行验证。
对于 HTML 验证,W3C 提供了HTML 验证器[9],此外我们还可以通过浏览器的开发者扩展来进行验证,也可以在自动构建环节加入相关验证。
对于 CSS 验证,W3C 也提供了CSS 验证器[10]。
值得注意的是,尽信书不如无书,我们可以借助验证器来发现一些问题,但不要因为验证失败就气馁。因为很多好的网站也会验证失败,可能是引用了一些第三方的内容,或者是使用了实验性的 CSS 特性,也可能验证器的更新没有跟上等等。
第一章阅读总结完毕,本来只给第一章留了很短的时间,但是其实第一章并不简单,因为其很有概括性,想要不照搬原文(那样的话太长)的同时,还能够讲清楚,还是需要花点功夫的。
最后,虽然是陪读,但是收获还是满满的。你呢?
文末附上陪读计划,欢迎监督共勉~!
《精通CSS》陪读计划图[1]
BEM: https://en.bem.info/methodology/quick-start/
[2]OOCSS: http://oocss.org/
[3]SUIT: https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md
[4]SMACSS: https://smacss.com/
[5]ITCSS: https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/
[6]Enduring CSS: http://ecss.io/
[7]http://html5doctor.com/: http://html5doctor.com/
[8]https://github.com/afarkas/html5shiv: https://github.com/afarkas/html5shiv
[9]HTML 验证器: http://validator.w3.org
[10]CSS 验证器: http://jigsaw.w3.org/css-validator