css 规范思考

css 写法中的一些疑惑,
前提:.最近和同事对css命名有过争论,对css命名规则有些疑惑;发出来给大家参考参考
对于CSS,为了避免样式冲突,我们总会给其赋予相当特殊的命名,或是在选择符上添加HTML标记,或是使用层级.因此我有思考有疑惑
1.css 劲量避免多层嵌套或者嵌套过多;
参考:

http://www.zhangxinxu.com/wordpress/2010/09/%E7%B2%BE%E7%AE%80%E9%AB%98%E6%95%88%E7%9A%84css%E5%91%BD%E5%90%8D%E5%87%86%E5%88%99%E6%96%B9%E6%B3%95/

我理解,在CSS命名之“三无原则”中

例如

这样多层结构;我们应该不用id,尽量让变量命名有意义,尽量不要层级,
而且,css的命名要尽量语义,明确化

参考:(CSS命名规范——BEM思想(非常赞的规范)) :

http://blog.csdn.net/chenmoquan/article/details/17095465

因此,我定义了css 样式:

.xxmodel{
    xx:xx
}
.xxmodel-child{
    xx:xx
}
.xxmodel-child-grandson{
    xx:xx
}

这样都是第一层级,而且可以看出他们的层级关系(有的时候也许我们需要一个parent作为一个模块的样式标识,来避免样式重复
ps:这边其实暂时没用到张大神里面讲到按功能命名的规则);

而不赞同:

.xxmodel{
    xx:xx
}
.xxmodel .child {
    xx:xx
};

这是某机油提出个问题:你这样命名太长了,如果不推荐层级,那为什么sass 他自动构建的时候是层级嵌套的?如果大家一起快速开发,用sass ,人家就是这么生成的怎么办?
对此,我哑火.我没详细使用过sass,对此我不能发表反驳;有看到的或许可以给我解答一下.
2.命名名称过长,使用了驼峰

在一次css讨论上.聊到多层命名上;
我们现在使用多层命名,我们尽量的避免命名过长,尽量语义化,那么依然有情况:我们可能描述某个模块,使用了英文单词拼接:比如:xxModel,通常我们单词拼接都讲究驼峰命名吧?,那么为了语义化我们写成这样:"xxModel-child-xxBtn"是否可以呢?
某同事提:哪有你这样写的啊?去看看别人谁这样写了?
我哑火,因为我不是别人.
驼峰规则命名没问题,-中横线命名没问题,为什么加起来就有问题了,我迷惑..

如果没看到:(CSS命名规范——BEM思想(非常赞的规范))这篇博文的时候:
类似这样的写法:"site-search__button,header__logo",这样的命名为了更语义化,更便于维护;
是不是又遭到询问:css不都是用中横线连接的吗?你见过谁这样又是中横线又是下横线啦?
是啊,没见过,至少周围没见过,常用的ui框架也没见过..
同样是为了语义,为了更方便维护,咋就有区别了呢;

3.对于通用格式的命名:
第一种:mt5,mt10,mt20,mt30...
第二种:mt-s,mt-l,mt-xl,mt-xxl....
我习惯于第一种,毕竟在书写页面时,可以很明确的知道我需要的是什么属性;而对于mt-s.mt-l,说实话,我开始要点进去,我才知道他代表的是什么,或许经常使用过后大脑已经形成了反射,瞬间知道比如:mt-xxl代表的什么
这时,同事询问:你这样写,如果以后我们要改规范,修改css,mt-l不表示10了,我们表示15,我们是不是只需要改一处就可以了?你这个mt-10如果改成值mt-10{maring-top:15};让人家怎么怎么维护,岂不是还要所有的页面都去改一下?改错了怎么办?
我一时无话,我一时觉得有道理,可是总觉的少了点什么..

http://www.cnblogs.com/lyzg/p/5561001.html

我觉得,这提出的问题其实并不是问题;

借用诸葛里面有段话(他解析的时张大神的某个插件):
"首先他这部分代码里面,包含了我们在网页开发中大部分常用的css属性,如display,height,margin,padding,border,color,font-size等。在属性类的命名上,基本上都是采取属性跟属性值的缩写。其他可说明的是:

1)width除了有固定值的属性类定义外,还包含了百分比的属性类定义,毕竟这个在实际工作中也时有用到;

2)margin,border,padding由于包含上下左右相关的属性,所以他还提供了针对上下左右单边的属性类,方便单独使用。

另外他的代码都有浏览器兼容性方面的考虑,所以要是在自己的工作中用的话,最好是参考着他的来。

这种方法在我使用之前,我比较顾虑的是它的可维护性。因为这些属性类很多都包含属性值,比如.f12{font-size: 12px},所以在html元素的class属性值就肯定会包含f12这样的css属性类名,假如要修改的对应的属性值该怎么办呢?那么就需要修改三个地方才行:首先是属性值定义的地方,第二是属性类名定义的地方,最后就是在html中使用的地方。当时想到这个问题的时候,我觉得这种方法不可行,因为在实际工作中,尼玛UI岗位的同事改设计的情况太多了,那样的话,页面上用到这种属性命名类的地方都要经常改来改去。

但是后来我发现,即使不用这种命名方法,我还是改变不了UI调整设计图的情况,而且只要设计图一改,甚至我的html结果以及我那些采用语义化命名的css类都要改,那个麻烦程度其实比用属性命名类的方法更厉害,所以我最后就开始在项目中尝试这个方法。结果发现,其实特别好用,尤其是做些文本类的排版,垂直布局,分栏布局,以及百分比布局等特别简单高效,前面提到的那个维护的问题也很小。我有两个方法来解决来那个问题:

1)假如原先用f12,后来设计把font-size改成14px,那么我只用再增加一个f14即可,再把原先html中需要把f12替换成f14的地方,换成f14即可。如果f12没有别的地方用到了,我会考虑把f12再删掉。

2)假如原先用f54,由于这种属性类并不具备通用性,所以我可能考虑直接把f54替换成我需要的属性类,比如f52。"

我想到这些问题:
如果只是为了避免后面修改规范的时候只需要修改一个地方;
首先,是什么情况下需要修改规范?规范在我看来这个就是一个底层的东西,除非有更好的规范替代,才去修改,而不是去修改其中的样式数值;规范的修改应该是一个很严肃的问题啊,或许可以比喻数据库的结构呀命名呀的设计?
另外什么情况下才需要修改默认的数值?那就是ui调整的时候啦~~单独调整一个属性值,对整个项目的整体结构不会有影响吗?这个是mt.或许真不会,最多什么地方丑点,其他的呢?比如:fz-xl?会不会出现错位,挤压?
而且,轮到这种全局修改的情况了,真的整体的ui不会动吗?我是不信的..(同事说你去看看阿里,京东他们怎么写的....我哑火,宝宝泪崩.没去过...实在说不出来,大公司肯定有非常严谨的规范我信.但随意改规范我还是不信的..);
所以,直观一点貌似也没什么错?..
或许我可以讲一下,你看人家也是这么写的....(噗).
:
个人观点,小结:
为什么要有规范,为的是 保持 CSS 易于维护,保持代码清晰易懂,保持 CSS 的可拓展性
不光光是css,我们规范为的是方便大家协同开发,整体风格严谨;规范的代码可以促进团队合作;减少bug率;降低维护成本,帮助代码走查..太多了.
至于争论规范到底是什么. 哪种才是最好的?
用我们大佬一句话:别吵了,我们这里就是这个规范!很霸道,很霸气对不对?没错就是这么霸气,就是这么对!
首先:
1规范是人定的.每个人的标准或多或少都不不一样,世上没有两片相同的叶子,我们css可以使用中横线-,因为这样也的确比较方便直观,你也许认为驼峰方便(或许现在并没有强烈的,明确的解释为什么css 不可以使用驼峰?),那就用驼峰;
2,规范是人用的,规范是我们自己,我们的团队,我们自己的团队需要用的,他是方便互相协同的,不是用来争的,有个规范,大家按着规范走就可以了,规范团队经理可以定,你可以定,我可以定,大家都能定,你一个人,你定的你自己严格遵照;团队定的,严格遵从就行了;开发的规范出发目的一切还是为了更快更好的开发.其他行业的规范不也如此?
也许,我们也可以是他人口中的别人家的规范(孩子)?保持好奇心,求同而存异,团队至上.

你可能感兴趣的:(css 规范思考)