项目启动时 css 应该注意哪些问题
文件名建议用小写字母加中横线的方式。为什么呢?因为这样可读性比较强,看起来比较清爽,像链接也是用这样的方式,例如
// 地址: github的地址
https://github.com/wangjeaf/ckstyle-node
那为什么变量名不用小写字母加小划线的方式,如:family_tree,而是推荐用驼峰式的familyTree?C语言就喜欢用这种方式命名变量,但是由于因为下划线比较难敲(shift + -),所以一般用驼峰式命名变量的居多。
引入CSS文件的link可以不用带type=“text/css”,如下代码:
<link rel="stylesheet" href="test.css">
因为link里面最重要的是rel这个属性,可以不要type,但是不能没有rel。
JS也是同样道理,可以不用type,如下代码:
<script src="test.js"></script>
没有兼容性问题。
属性的书写顺序对于浏览器来说没有区别,除了优先级覆盖之外。但是如果顺序保持一致的话,扫一眼可以很快地知道这个选择器有什么类型的属性影响了它,所以一般要把比较重要的属性放前面。比较建议的顺序是这样的:
你可能会觉得我平时差不多就是这么写的,那么说明你有一个比较好的素养。并且我觉得规则不是死,有时候可以灵活,就像你可能会用transform写居中,然后把left/top/transform挨在一起写了,我觉得这也是无可厚非的,因为这样可以让人一眼看出你要干嘛。
有些人可能喜欢用样式的特点命名,例如:
.red-font{
color: red;
}
.p1{
font-size: 18px;
}
.p2{
font-size: 16px;
}
然后你在它的html里面就会看到套了大量的p1/p2/bold-font/right-wrap之类的类名,这种是不可取的,假设你搞了个red-font,下次UI要改颜色,那你写的这个类名就没用了,或者是在响应式里面在右边的排版在小屏的时候就会跑到下面去,那你取个right就没用了。有些人先把UI整体瞄了一下,发现UI大概用了3种字号18px/16px/14px,于是写3个类p1/p2/p3,不同的字号就套不同的类。这乍一看,好像写得挺通用,但是当你看他的html时,你就疯掉了,这些p1/p2/p3的类加起写了有二三十个,密密麻麻的。我觉得如果要这样写的话还不如借助标题标签如下:
.house-info h2{
font-size: 18px;
}
.house-info h3{
font-size: 16px;
}
因为把它的字号加大了,很可能是一个标题,所以为什么不直接用标题标签,不能仅仅担心因为标题标签会有默认样式。
类的命名应当使用它所表示的逻辑意义,如signup-success-toast、request-demo、agent-portrait、 company-logo等等。
如果有些样式你觉得真的特别通用,那可以把它当作一个类,如clearfix,或者有些动画效果,有几个地方都要用到,我觉得这种较为复杂并且通用的可以单独作为一个类。但是还是趋向于使用意义命名。
有些人在写CSS的时候使用一些hack的方法注释,如下:
.agent-name{
float: left;
_margin: 10px;
//padding: 20px;
}
这种方法的原理是由于//或者_开头的CSS属性浏览器不认识,于是就被忽略,分号是属性终止符,从//到分号的内容都被浏览器忽略,但是这种注释是不提倡的,要么把.css文件改成.less或者.scss文件,这样就可以愉快地用//注释了。
还有一些专门针对特定浏览器的hack,如*开头的属性是对IE6的hack。不管怎么样都不要使用hack。
选择器一般不要写超过3个,有些人写sass或者less喜欢套很多层,如下:
.listings-list{
ul{
li{
.bed-bath{
p{
color: #505050;
}
}
}
}}
一个容器就套一层,一层一层地套下来,最底层套了七八层,这么长的选择器的性能比较差,因为Chrome里面是用递归从最后一个选择器一直匹配到第一个,选择器越多,匹配的时间就越长,所以时间会比较长,并且代码的可读性也比较差,为看到最里面的p标签的样式是哪个的我得一层层地往上看,看是哪里的p。代码里面缩进了7、8层看起来也比较累。
一般只要写两三个比较重要的选择器就好了,不用每个容器都写进去,重要的目标元素套上class或者id。
最后一个选择器的标签的应该少用,因为如果你写个.container div{}的话,那么页面上所有的div第一次都匹配中,因为它是从右往左匹配的,这样的写的好处是html不用套很多的类,但是扩展性不好,所以不要轻易这样用,如果要用需要仔细考虑,如果合适才使用,最起码不能滥用。
有时候会出现自己的样式受到其他人样式的影响,或者自己的样式不小心影响了别人,有可能是因为类的命名和别人一样,还有可能是选择器写的范围太广,例如有人在他自己的页面写了:
* {
box-sizing: border-box;
}
结果导致在他个页面的公用弹框样式挂了。一方面不要写*全局匹配选择器,不管从性能还是影响范围来说都太大了,例如在一个有3个子选择器的选择器:
.house-info .key-detail .location{}
在三个容器里面,*都是适用的,并且有些属性是会继承的,像font-size,会导致这三个容器都有font-size,然后一层层地覆盖。
还有一种情况是滥用了:first-child、:nth-of-type这种选择器,使用这种选择器的后果是扩展性不好,只要html改了,就会导致样式不管用了,或者影响到了其它无关元素。但是并不是说这种选择器就不能用,只要用得好还是挺方便的,例如说在所有的li里面要让最后一个li的margin-left小一点,那么可以这么写:
.listing-list li:last-child{
margin-left: 10px;
}
这可能比你直接套一个类强。但是不管怎么样,不能滥用,合适的时候才使用,而不是仅仅为了少写类名。
覆盖是一种常用的策略,也是一种不太优雅的方式,如下代码,为了让每个house中间的20px的间距,但是第一个house不要有间距:
.house{
margin-top: 20px;
}
.house:first-child{
margin-top: 0;
}
其实可以改成这样:
.house + .house{
margin-top: 20px;
}
只有前面有.house的.house才能命中这个选择器,由于第一个.house前面没有,所以无法命中,这样看起来代码就简洁多了。
还有这种情况,如下代码所示:
.request-demo input{
border: 1px solid #282828;
}
.request-demo input[type=submit]{
border: none;
}
其实可以借助一个:not选择器:
.request-demo input:not([type=sbumit]){
border: 1px solid #282828;
}
这样看起来代码也优雅了很多。
有一种覆盖是值得的,那就是响应式里面小屏的样式覆盖大屏,如下:
@media (min-width: 1025px){
.container{
width: 1080px;
margin: 0 auto;
}}
我一开始是就是这么写的,为了遵循减少覆盖原则,但是后来发现这种实践不好,代码容易乱,写成覆盖的好处在于可以在浏览器明显地看到,小屏的样式是覆盖了哪个大屏的样式,这个在大屏的时候又是怎么样的。
important用来覆盖属性,特别是在CSS里面用来覆盖style里的属性,但是important还是少用为妙。有时候你为了偷懒直接写个!important,以为这个的优先级是最高的了,往往螳螂捕蝉,黄雀在后,很可能过不了多久又要再写一个优先级更高的覆盖掉,这样就略显尴尬了。所以能少用还是少用。如果要覆盖还是先通过增加添加选择器权重的方式。
不管是JS/CSS,缩进都调成4个空格,如果你用的sublime,在软件的右下角有一个Tab Size,选择Tab Size 4,然后再把最上面的Indent Using Spaces勾上,这样,当你打一个tab键缩进的时候就会自动转换成4个空格。如果你使用vim,新增或者编辑~/.vimrc文件新增一行:
:set tabstop=4 也会自动把缩进改成4个空格,其它编辑器自行查找设置方法。因为\t在不同的编辑器上显示长度不一样,而改成空格可以在不同人的电脑上格式保持一致。
多个选择器共用一个样式集,每个选择器要各占一行,如下:
.landing-pop,
.samll-pop-outer,
.signup-success{
display: none;
}
每个属性名字冒号后面要带个空格,~、>、+选择器的前后也要带一个空格:
.listings > li{
float: left;
}
显示一张图片有两种方式,可以通过设置CSS的background-image,或者是使用img标签,究竟什么时候用哪种呢?
如果是头图等直接展示的图片还是要img标签,如果是做为背景图就使用background,因为使用img可以写个alt属性增强seo,而背景图那种本身不需要SEO。虽然background有一个一个background-position: center center很好,但是头图那种还是使用img吧,自己去居中吧,不然做不了SEO。
响应式开发最不好不要杂合使用rem,文字字号要么全部使用rem,要么不要用,也不要使用transform: scale去缩小,因为被缩小的字号看起来会有点奇怪,别人都是14px,而你变成了13.231px,小了一点。响应式的原则一般是保持中间或者两边间距不变,然后缩小主体内容的宽度。
有些人喜欢用inline-block,特别是刚开始学切图的人,因为block会换行,而inline-block不会换行还具有盒模型,因此inline-block用得很顺手,而float比较复杂,还要处理清除浮动之类的问题。如下布局:
应该写li,然后让li float,如果你让li display:inline-block也可以达到目的。但是inline-block用得多了可能会有一些奇怪的问题,你通常要在一个inline-block的元素里面套block的元素,inline-block是行内元素,而block是块级元素,这两者终究有点差别。这种应该用float/flex会更自然,如果你float用顺手了你会发现比inline-block好多了,并且更加专业。如果你没怎么用过flex ,那你可以尝试换一下使用flex,如果你没怎么用过float,可以尝试用一下。只有你的切图方式多样化了,你切起图来才能比较灵活。
原文:https://blog.csdn.net/tjx11111/article/details/104498451
目前我们现在用的前后端分离模式属于第一阶段,下一阶段可以在前端工程化方面,对技术框架的选择、前端模块化重用方面,可多做考量。也就是要迎来“==前端为主的 MV* 时代==”。
当您必须使用匿名函数,请使用箭头函数表示法,它创建了一个在 this 上下文中执行的函数的版本,这通常是你想要的,而且这样的写法更为简洁。如果你有一个相当复杂的函数,你或许可以把逻辑部分转移到一个声明函数上。
standard是一个开源的JS代码规范库,制定了所谓standard(标准)的JS代码规范,配合编辑器插件可以实时检查代码规范以及语法错误,通过执行命令检查代码规范以及语法错误,自动修复(可以直接修复的)不合规范的代码,使其符合规范
对于一个多人团队来说,制定一个统一的规范是必要的,因为个性化的东西无法产生良好的聚合效果,规范化可以提高编码工作效率,使代码保持统一的风格,以便于代码整合和后期维护。
为了编写可维护的代码,我们把很多函数分组,分别放到不同的文件里,这样,每个文件包含的代码就相对较少,很多编程语言都采用这种组织代码的方式。在Node环境中,一个.js文件就称之为一个模块(module)
引号的使用,单引号优先(如果不是引号嵌套,不要使用双引号)、空格的使用问题:(关键字后 符号后 排版 函数 赋值符号= )等、不写没有使用过的变量,如果定义了一个变量,后来一直没有参与过运算,那么不应该定义这个变量...
嵌套的节点应该缩进;在属性上,使用双引号,不要使用单引号;属性名全小写,用中划线做分隔符;不要在自动闭合标签结尾处使用斜线(HTML5 规范 指出他们是可选的);不要忽略可选的关闭标签;
CommonJS规范规定,每个模块内部,module变量代表当前模块。这个变量是一个对象,它的exports属性(即module.exports)是对外的接口。加载某个模块,其实是加载该模块的module.exports属性。module.exports属性表示当前模块对外输出的接口
W3C通过设立领域(Domains)和标准计划(Activities)来组织W3C的标准活动,围绕每个标准计划,会设立相关的W3C工作组织(包括工作组、社区组、商务组等)。W3C会根据产业界的标准需求调整Domains和Activity的设置及相关的工作组设置。
不要使用 @import 与 <link> 标签相比,@import 指令要慢很多,不光增加了额外的请求次数,还会导致不可预料的问题。CSS有些属性是可以缩写的,比如padding,margin,font等等,这样精简代码同时又能提高用户的阅读体验。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!