当前位置:Gxlcms > html代码 > 看某前端设计书上说,在base.css里先定义一些基础样式然后在html里面加上相应的class,这样是否和语义化相矛盾?

看某前端设计书上说,在base.css里先定义一些基础样式然后在html里面加上相应的class,这样是否和语义化相矛盾?

时间:2021-07-01 10:21:17 帮助过:21人阅读

比如: .w100{width:100px;}.w200{width:200px;}.w300{width:100px;}.m100{margin:100px;}.m200{margin:200px;}.m300{margin:300px;}……
我的理解是:既然标签要语义化那class,id应该也是语义化的而不是完全沦为为样式服务的,诚然这样做很方便

回复内容:

我想你指的.w100等应该指的是基础样式文件(如base.css)里面的通用原子类吧?
这个问题问的很好。

请先阅读彬GO的文章《CSS代码命名惯例语义化的方法》blog.bingo929.com/css-c

另外再请参阅本人的文章《再谈语义化》ued.ctrip.com/blog/?

语义化分为html标签的语义化和css命名的语义化,你这里指的是CSS命名的语义化。


.w100定义了宽度为100px的通用属性,可以很方便的挂在需要宽度设为100的模块上。但让我们来考虑一下一旦需求发生变更,宽度要改为200呢?或者改为250?这时你是去修改原型html里的类名?明显这与我们的初衷不吻合。既然我们将CSS单独放在一个文件中,我们的期望就是为了易于维护,样式与html分离,一旦外观样式发生变化,我们可以最少程度的去修改原型文件,而直接通过修改样式即可解决。


彬GO的一句总结很好:语义化命名,而不是结构化命名。(目前看来欠妥)


当然,这种方法最大程度的抽象出了通用属性,可以节省一定的CSS冗余代码,但这仅仅适用于后期变更很少的项目,即确定了此模块为100后期基本不会变化的情况。


还是一句话,前端技术没有银弹,没有最好的方法,只有最合适的方法。


--------------------------------

PS:感谢@贺师俊 指出,的确“结构化命名”欠妥,因为还有可能是诸如"color-red"这类型的通用原子类,而“结构化命名”仅仅指的是CSS的框模型的命名。希望没有误导大家。“样式描述命名”显得更合理一点。


没错,这样做是违背语义化的要求的。我已经批判过这种流传甚广的anti-pattern多次了。请顺序阅读这几篇blog:
hax.iteye.com/blog/4973
hax.iteye.com/blog/5000
hax.iteye.com/blog/8498 其实还是要根据项目来,并不能绝对说这种方法好或者不好。

比如那种需要很快输出,基本不需要要后期维护的项目,(例如活动页,新闻页等)。那这种预先定义样式的方法效率就很高。

而那种有大把时间死扣优化,或者体量很大需要精细维护的项目,还是模糊命名比较合适。

bootstrap基本上是属于前者的。

就像前面知友所说的,没有对不对,只有合适不合适。 多人维护的时候可以做到一目了然,不过实际上不太好:
比如这个 .m100 ,我如果在实际中要改成 margin: 110px 该怎么办呢?
是不是要把所用到的 .m100 全部替换成 .m110 呢,或者只改了 css 中的内容而不改名称? 那样不就歧义了么。

我的建议(当然名字你可以随便起):
.w100 -> .w-narrow
.w200 -> .w-normal
.w300 -> .w-wide
.m100 -> .m-near
.m200 -> .m-normal
.m300 -> .m-far

这样既能在部署时保持一目了然,又能做到可以灵活修改。

---------------

个人理解,所谓语义化是为了更好的理解和维护代码服务的,并不是强制性的(而且只是针对HTML)。
在尽量高效美观的前提下,你的id和class只要不是 div1、div2、div3 这一类毫无意义的符号就好了。 个人认为这样的做法的确是把样式名称和 HTML 结构做了很深的耦合,但是开发维护是需要效率的,不是一味的追求纯粹的语义化和解耦,最终的方案都是权衡的结果。我们要明白设计开发最终的目的是什么。 这是一个比较蛋疼的问题,这种写法确实可以减少代码量,但需要很多人员的配合,比如视觉,而且需求要确定下来,万一需求修改了,那么祝贺你。。。所以慎用 不知道是什么书上写的,实在不知道.w100{width:100px;}这个意义是什么,这个类做了什么抽象?如果宽度变成150,类名不改成w150吗?这样做还要这个原子类有什么用呢?

类名和id名是需要语义化的,如果你的产品中发现需要这样的纯表现化的类,那么我觉得是没有设计好。 话说关于前端模块化的问题,我之前就蛮想探讨一下,不过没想到有人尽然问了,那我也顺便分享下自己的一些看法:
  1. 为什么需要CSS语义化?既然要用的话,你至少要知道原因吧,总不能因为“XX书上说要这样用”,所以我也这样用。个人认为是在CSS发展的初期,部分人喜欢用“样式信息”来为选择器命名,也就是用例如redBox,floatArea。这样的话,很明显是不太能满足开发的需要的,也就是 @interjc 同学提到的,后期可能会更改需求。所以,后来大家都开始建议用比较语义化的选择器,这样,一方面即使更改了需求,另外一方面,语义化毕竟是html&css发展的趋势,也算是为后期铺路(其中做得“最语义化”的应该就是微格式:microformats.org/,有兴趣的可以google下相关的)。
  2. 为什么要用模块化写法?我记得以前看过一本《Web前端开发修炼之道》(book.douban.com/subject)的书,作者貌似是当时新浪前端的大牛,他在里面就提到了用.mt10,.fl等选择器来将一个“语义化的选择器”拆分,这样可以减少整体的代码量。除此之外,可以将大型网站的css利用MVC的设计思想,分为比较模块化的结构。
  3. 模块化写法和css语义化是否冲突?个人比较认同@顾轶灵 ,按照个人比较直白的话,就是这个意思:不要单纯追求“语义化”,你学到的相关知识都是为项目服务的。
  4. 我目前个人的项目经验,使用这种模块化写法并不和语义化相冲突。我一般会在比较大的区域上用语义化写法,而在嵌套不超过两层的标签上用模块化写法。因为现在每个项目,开始做的和最后成型的总是有差别的(也就是前面@火柴 同学说的),而且作为一个前端开发工程师,你到后面能改的,主要还是CSS(html如果已经和后台相关代码嵌套,要改的话多少会有点麻烦),如果完全用模块化写法,根本无法满足后期的需求;如果完全用语义化写法,会增加多于的选择器(比如有个地方只是要把那个字显示成红色)。
语义化只跟HTML内容及URL地址有关,主要是指head标签里的内容、及BODY标签里的内容的标签名、层叠关系和顺序。

语义化与CSS、class的命名没有关系,跟JS也没直接关系(除了AJAX为主的网页在GOOGLE是有用URL中的hash地址来进行定位之外)。 有点太极端了就不好了,如果项目定型了,很少去动,可以用这样的,如果项目变动大,改起来太麻烦!有利有弊,以前有过这样的教训,所以,建议保留常用的几个,没必要w1到w100什么的,太碎了,很多都用不到!

人气教程排行