CSS 代码静态质量检查

2015/08/01 · CSS ·
品质检查

原稿出处: 百度EFE – ielgnaw   

关于代码静态品质检查,在大佛的上一篇文章 《JavaScript
代码静态品质检查》中已经说得很清楚了,纵然首要讲的是
JavaScript 方面,但代码静态品质检查的真面目是不改变的,前些天大家来介绍一下
CSS 方面包车型地铁静态质量检查。

CSS 中也会有一部分 Lint
工具,举个例子 CSSLint,PrettyCSS,recess,CKStyle,stylelint,当然还应该有百度
EFE 出品的 CSS
代码风格检查工具 CSSHint。本文将从效能、品质、适用范围、准则完毕、本性化几个地点对那多少个Lint 工具举行比较。

CSS: 试试,然后做的更加好

2015/08/28 · CSS ·
CSS

本文由 伯乐在线 –
赖信涛
翻译,JustinWu
校稿。未经许可,禁止转发!
葡萄牙共和国(República Portuguesa)语出处:css-tricks.com。应接插手翻译组。

您有未有顾忌过本人写的 CSS
都错了?有未有想过会失去一些让一切变得越来越好更简便的新点子?是否想在 CSS
方面更有自信呢?

这在那方面你和 Anna 肯定身临其境:

自己的 CSS充满了小编思疑。今后 class
使用什么的名字系统更适合呢?现在怎么样又是最佳的?什么是差的?

——Anna Debenham (@anna_debenham) November 13,
2014

若果您也写了许多CSS,但是一直未有过这样的多疑,那么就比较令人思念了。要么便是您一等聪明,要么,呵呵,你懂的

自家方今写 CSS
的措施是:固然尝试,做的更加好。小编不是想要宣扬特殊的方法论可能严厉的准则。那更疑似一些宽松的法则,保险职业在可控的限制内,积极地品尝,然后做的更加好有的。

告诫:那是自个儿个人的措施。作者专门的学业的门类大约唯有本身本人担当 CSS。从近来css-tricks
上的投票来看,当中百分之四十也一律适用于您。作者想见,和您一同坐班的人越来越多,笔者的建议的作用就越小。
//译注:原来的作品 csstricks 网址边栏有一个投票。

以下正是事无巨细的规律:

决不懒惰。你怎么时候偷懒了,自个儿心里都理解。举例对有些难点你喜悦草草的高速修正,并非干净领会那些标题。可能是哪位文件看起来方便就应声将
CSS
放进去并不是考虑它到底该放在哪儿。又可能是当有个别场景明显供给新的方式时您却反其道而行之。

利用你高兴的方法。精通呢?在模块中自己爱不忍释光明正天下使用子选取器。.module > h2这种样式平时出现在作者的
CSS
中。严酷的方法论料定不协理这种做法,不过本身可无论是。在它出错在此之前,笔者会一贯这么使用,可是到近年来甘休都以对的。若是它出错了,我再改。原因比较作者前边所涉嫌的。

用你欣赏的措施展开命名。一经让自家遵照某些法则来定名,小编脑子里断定会一团糟。笔者应该会花上一两日的日子来经受这些准则,並且重新开展保管。大家的系列完全部是基于自家自身的喜悦进行命名的。总体上的话,我以为到更轻松,更加快速。

利用本身以为高效的工具。本身不会推荐什么工具,因为好的工具是并重的。如若本人以为某些工具很有用,笔者就能去用。只要它能节省时间,做出越来越好地成效,更好地组织,消除品质难点,自动做出最棒选项,不管它是怎么样,小编用了。

有一条准则是自家长久以来坚信的:在整个项目中维系采取器的低特异性。结合
Harry
的特异性图表能够很好地领略那句话。特异性是会逐步上升的,由此要预防一发端就发生Gott异性,不然它会急忙成为一个主题素材。可以虚构多用:.class{}

有指标性地再次访谈页面的依次部分。指标不仅仅是反省各种部分的 CSS
优良,还要准备做的更加好,适用于大多人。作者意识每趟作者再也采访三个地点,都以做最后润色的五个火候,那让本人对旧代码更有自信。

1 赞 2 收藏
评论

行内格式化上下文中的各样中度总计

2015/10/11 · CSS ·
高度

初稿出处: HaoyCn   

前言碎碎语:标题难点在后天干扰了小编比较久相当久,深夜把标题提到了各互联网也临时并未有过来。因为前日要早起飞异地参预一场校招面试,小编照旧很恐慌的,但奈何难点不消除寝食难安……所以依旧卯起劲重新思索那么些题材,算是临时有了七个团结比较承认以及清晰的答案,与诸位读者分享。如你有例外视角主张意见提议,恳请斧正!

标准切磋在此之前,大家重点贰个景观(在 Chrome
下的显现,别的浏览器下的表现和计量或许有细微差异):

图片 1

上海体育场地对应的 HTML 是(之后的研究均依照此):

<!DOCTYPE html> <html> <head> <meta
charset=”utf-8″/> <title>Line Height</title>
<style> body { margin: 0; font: 32px/1 ‘Microsoft YaHei’; } div {
width: 400px; margin: 30px auto; outline: 1px solid black; background:
#008E59; } img { height: 80px; margin-top: 10px; } </style>
</head> <body> <div> <span>Some
Text</span> <img src=”picture.jpg” alt=””/> </div>
</body> </html>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>Line Height</title>
<style>
body {
    margin: 0;
    font: 32px/1 ‘Microsoft YaHei’;
}
div {
    width: 400px;
    margin: 30px auto;
    outline: 1px solid black;
    background: #008E59;
}
img {
    height: 80px;
    margin-top: 10px;
}
</style>
</head>
<body>
    <div>
        <span>Some Text</span>
        <img src="picture.jpg" alt=""/>
    </div>
</body>
</html>

小编们来计量下 DIV 和 SPAN 的万丈

JavaScript

document.getElementsByTagName(‘div’)[0].offsetHeight //93
document.getElementsByTagName(‘span’)[0].offsetHeight //42

1
2
3
4
document.getElementsByTagName(‘div’)[0].offsetHeight
//93
document.getElementsByTagName(‘span’)[0].offsetHeight
//42

对此此图,我产生如下难题:

  • line-height  为 32px,为啥 SPAN
    的冲天为 42px?
  • DIV 的莫斯中国科学技术大学学 93px,比 IMG 中度加外边距 90px 以及 SPAN 中度 42px
    都要大,怎么着计算的?
  • 图形和文件下的空域(固然未有公文一样存在)是什么产生的?

万一大家把 IMG 删除,HTML 部分改为:

<body> <div> <span>Some Text</span> </div>
</body>

1
2
3
4
5
<body>
    <div>
        <span>Some Text</span>
    </div>
</body>

这时候来计量:

JavaScript

document.getElementsByTagName(‘div’)[0].offsetHeight //32
document.getElementsByTagName(‘span’)[0].offsetHeight //42

1
2
3
4
document.getElementsByTagName(‘div’)[0].offsetHeight
//32
document.getElementsByTagName(‘span’)[0].offsetHeight
//42

新主题材料又来了:

  • DIV 的子成分中度为 42px,为什么没有“撑起” DIV 的莫斯中国科学技术大学学?

以上难点正是本文要商量的了。覆盖了三个知识点:

  1. 行内盒(或行内不可替换到分)的莫斯中国科学技术大学学
  2. 行内可替换来分的冲天
  3. 行盒的万丈
  4. 行距与行高
  5. 树立行内格式化上下文的块盒的 auto 高度

进而在钻探此前,小编已假诺您领略那些概念:行内盒、行内不可替换来分、行内可替换来分、行盒、行内格式化上下文。假使您还有个别不知道,大家能够急忙补习下:

可替换元素、不可替换来分

粗略地讲,可替换到分是指须依照其标签和性质来决定具体显示内容的成分,如本文中会研究的
IMG 成分,其实际展现内容由  src 等性情决定;
不可替换到分则是内容一向表现的成分。如本文仲追究的 DIV 和 SPAN 等。

块盒

此概念是块格式化上下文的剧情,要分解起来就更目迷五色啦,笔者粗陋地给你多少个陈述:块盒一般是 
display: block 的不足替换来分。

行内级成分、行内级盒、行内盒、行内格式化上下文

display: inline|inline-table|inline-block  产生行内级成分。行内级成分生成行内级盒,而这个盒会出席行内格式化上下文。

display 值是  inline 的不得替换来分会生成三个行内盒。

不是行内盒的行内级盒被喻为原子行内级盒。

图片 2

行盒

在行内格式化上下文中,盒从富含块的最上端一个接一个地水平摆放。包涵了一整套里全体盒的矩形区域被称呼行盒。贰个段子正是三个行盒的垂直聚积。

为此,我们能够拿走下图(大致描摹):

图片 3

到现在初阶总括!

CSSLint

CSSLint 和它底层所使用的深入分析器 parserlib 都是 Nicholas
C.
Zakas 的作品(当然,ESLint 也是他的著述)。它适用于浏览器以及
CLI 情况,在浏览器端和 CLI
景况中分头是两套代码,这么做的来头是它的底层库 parserlib 在浏览器和
CLI 际遇分别是两套。

功能上,CSSLint 提供了对 CSS
的深入分析、检查等功效。在准则完毕地方,不大概透过 JSON
配置来管理,暗中同意的平整全体在src/rules/ 目录中,要增多自定义准则,必得透过全局的 CSSLint.addRule 方法来兑现。

实现上,CSSLint 主借使运用事件监听,在尾部 parse CSS
进程中触发事件,举例startstylesheetendstylesheetcharsetimportnamespacestartmediaendmediastartpageendpagestartrul 和endrule 等,事件回调中会重临当前
AST 的音讯,开拓者依据那一个消息来张开平整检查评定。

属性上,借使不增添自定义的平整,质量照旧不错的,可是一旦增多自定义准则,质量就能够打些折扣。这是底层分析器 parserlib 的原因,parserlib 成效比较单纯,并且回去的
AST
上新闻不是很丰盛,也不支持插件机制,因而要兑现部分自定义的平整,基本只好靠正则相配来贯彻。

CSSLint 开荒时间比较早,同有时间也因为大神的影响力,因方今后布满配套特别足够,接济种种编辑器比方:TextmateSublime TextAtomVimEmacs 等等。

有关小编:赖信涛

图片 4

个人网址

个人主页 ·
小编的稿子 ·
18 ·
 

图片 5

1 行内可替换到分和文书档案流内行内块可替换来分中度计算

W3C 有可想而知规范,如下:

即便  height 和  width  总括值均为 auto 且该因素有固有高度,那么该固有高度为 height 使用值。

要不,假如  height 计算值为  auto ,且该因素有三个原来比例,则 
height 的使用值为:

width 使用值 / 固有比例

要不,假如  height 总计值为  auto ,且该因素有固有中度,那么该固有高度为 
height 使用值。

不然,假诺  height 计算值为  auto ,但上述气象均不吻合,那么 
height  的施用值必得设定为八个最大矩形的可观,该矩形比例为2:1,中度不超过150px,且上涨的幅度不超过设备宽度。

因而,在大家的实例中,IMG 盒的惊人为 80+10 = 90px。

PrettyCSS

PrettyCSS 是二个相比不错的 Lint 工具,但它并不到底三个彻彻底底的
Linter,更应该把它叫做一个 Parser,这也是它精美的案由。在 Parser
里面完结的 Linter 以及 Pretty,那样能够最大程度的承接保险 Linter
的正确度。它适用于浏览器端、作为 Node.js 模块以及 CLI 工具。

贯彻上来说,在 Parser 中集成 Linter 即在 Parse 阶段就把 Linter
的法规给检查实验了,因而质量较好。当然劣点也正如显明,正是不能自定义准则。

如果 PrettyCSS 今后亦可提供插件机制,允许自定义法则,会更有吸重力。

2 行内盒的可观总括

“中度”一词在这里颇有歧义,小编以为,总共能够有二种概念供给深入分析:

  • 行内盒的内容区域中度
  • 行内盒的盒中度
  • 计量行盒中度时的行内盒的盒中度

你或者对第二和第三演说抱有问号,但大家先搁置质疑,把精晓精通的事物先化解。

当大家用 JavaScript 去得到三个行内盒的 offsetHeight 值时,如大家地点所做的:

JavaScript

document.getElementsByTagName(‘span’)[0].offsetHeight

1
document.getElementsByTagName(‘span’)[0].offsetHeight

作者将其中度称作“行内盒的盒中度”,类比于我们所纯熟的块盒盒中度。其总计值是:

内容区域中度 + 上下面框 + 上下内边距 = 行内盒的盒高度

边框和内边距的拉长率默感到0,否则为我们同心合力钦定,但“内容区域高度”是怎么计算的吗?

W3C 这么说:

height 不适用。内容区域的冲天应基于字体,但本标准未有一些名怎么着。客户代理大概,比如说,使用行高盒 EM-Box 或字体的最大上端部 Ascender 和下端部 Descender。(后一种会保险有一点点在行高盒之上或之下的字符仍旧落在剧情区域内,但会产生区别字体有大小不一的盒子;前面二个则保证小编能够操纵相对于 line-height 的背景设计,但也招致字符绘制在其剧情区域之外。)

言下之意:

  1. height 属性无效
  2. 行内盒内容区域低度在业Nene部未有概念,浏览器能够协调折磨

既然规范未有分明规定总结,大家让浏览器实地度量一下。小编浏览器测量试验如下:

  • Chrome 42
  • IE11 42
  • Firefox 43

若果大家改换字体,假设应用如下 CSS

CSS

body { font-family: Simsun; }

1
body { font-family: Simsun; }
  • Chrome 33
  • IE11 37
  • Firefox 35

而一旦大家修改 line-height ,以上结果均不受影响。

笔者也曾思疑,那么些 offsetHeight 就是内容区域中度吗?答案:是。笔者的求证措施是依据W3C 如下规定:

即使不可替换来分的异乡距、边框以及内边距不归入行盒的企图,它们依然渲染在行内盒的方圆。那表示一旦 
line-height  钦命的可观小于被含有盒的剧情中度,内边距和边框的背景和颜色可能“流进”毗邻的行盒。顾客代理应当按文档顺序渲染那一个盒。那会促成前边的盒的边框绘制在前面盒的边框和文本上。

您可以用于下代码实测,会发觉北京蓝行内盒的背景溢出到了中黄行内盒所在的行盒。

<div> <span style=”background:red”>Some Text</span>
<br/> <span style=”background:rgba(0,0,0,.5)”>Some
Text</span> </div>

1
2
3
4
5
<div>
    <span style="background:red">Some Text</span>
    <br/>
    <span style="background:rgba(0,0,0,.5)">Some Text</span>
</div>

能够内容区域中度,即行内盒未有内边距和边框时的  offsetHeight 。

据此计算论是:

行内盒的剧情区域高度总括未有统一的行业内部,不一致的字体大概不相同的浏览器都或者导致差别的结果,且其惊人与 
line-height 非亲非故。

经过大家鞭长莫及适用地收获三个跨浏览器的行内盒的内容区域中度。同样大家也无力回天适用得到贰个跨浏览器的行内盒高度(因为其总括式里面就包罗了不定变量内容区域中度)。

但难点来了,分化浏览器都利用区别的行内盒内容区域中度,又何以能合併总括行盒以及块容器的冲天呢?这几个标题便导致了我在地方所提到的“总计行盒中度时的行内盒的盒中度”概念。

大家步向下多个话题,行盒中度总计。

发表评论

电子邮件地址不会被公开。 必填项已用*标注