看某前端设计书上说，在 base.css 里先定义一些基础样式然后在 html 里面加上相应的 class，这样是否和语义化相矛盾？
程序员文章站
2022-05-16 15:57:36
...
比如： .w100{width:100px;}.w200{width:200px;}.w300{width:100px;}.m100{margin:100px;}.m200{margin:200px;}.m300{margin:300px;}……
我的理解是：既然标签要语义化那class，id应该也是语义化的而不是完全沦为为样式服务的，诚然这样做很方便
这个问题问的很好。
请先阅读彬GO的文章《CSS代码命名惯例语义化的方法》http://blog.bingo929.com/css-coding-semantic-naming.html
另外再请参阅本人的文章《再谈语义化》http://ued.ctrip.com/blog/?p=2735
语义化分为html标签的语义化和css命名的语义化，你这里指的是CSS命名的语义化。
.w100定义了宽度为100px的通用属性，可以很方便的挂在需要宽度设为100的模块上。但让我们来考虑一下一旦需求发生变更，宽度要改为200呢？或者改为250？这时你是去修改原型html里的类名？明显这与我们的初衷不吻合。既然我们将CSS单独放在一个文件中，我们的期望就是为了易于维护，样式与html分离，一旦外观样式发生变化，我们可以最少程度的去修改原型文件，而直接通过修改样式即可解决。
彬GO的一句总结很好：语义化命名，而不是结构化命名。（目前看来欠妥）
当然，这种方法最大程度的抽象出了通用属性，可以节省一定的CSS冗余代码，但这仅仅适用于后期变更很少的项目，即确定了此模块为100后期基本不会变化的情况。
还是一句话，前端技术没有银弹，没有最好的方法，只有最合适的方法。
--------------------------------
PS:感谢@贺师俊 指出，的确“结构化命名”欠妥，因为还有可能是诸如"color-red"这类型的通用原子类，而“结构化命名”仅仅指的是CSS的框模型的命名。希望没有误导大家。“样式描述命名”显得更合理一点。
没错，这样做是违背语义化的要求的。我已经批判过这种流传甚广的anti-pattern多次了。请顺序阅读这几篇blog：
http://hax.iteye.com/blog/497338
http://hax.iteye.com/blog/500015
http://hax.iteye.com/blog/849826 其实还是要根据项目来，并不能绝对说这种方法好或者不好。
比如那种需要很快输出，基本不需要要后期维护的项目，（例如活动页，新闻页等）。那这种预先定义样式的方法效率就很高。
而那种有大把时间死扣优化，或者体量很大需要精细维护的项目，还是模糊命名比较合适。
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名是需要语义化的，如果你的产品中发现需要这样的纯表现化的类，那么我觉得是没有设计好。 话说关于前端模块化的问题，我之前就蛮想探讨一下，不过没想到有人尽然问了，那我也顺便分享下自己的一些看法：
语义化与CSS、class的命名没有关系，跟JS也没直接关系（除了AJAX为主的网页在GOOGLE是有用URL中的hash地址来进行定位之外）。 有点太极端了就不好了，如果项目定型了，很少去动，可以用这样的，如果项目变动大，改起来太麻烦！有利有弊，以前有过这样的教训，所以，建议保留常用的几个，没必要w1到w100什么的，太碎了，很多都用不到！
我的理解是：既然标签要语义化那class，id应该也是语义化的而不是完全沦为为样式服务的，诚然这样做很方便
回复内容：
我想你指的.w100等应该指的是基础样式文件（如base.css）里面的通用原子类吧？这个问题问的很好。
请先阅读彬GO的文章《CSS代码命名惯例语义化的方法》http://blog.bingo929.com/css-coding-semantic-naming.html
另外再请参阅本人的文章《再谈语义化》http://ued.ctrip.com/blog/?p=2735
语义化分为html标签的语义化和css命名的语义化，你这里指的是CSS命名的语义化。
.w100定义了宽度为100px的通用属性，可以很方便的挂在需要宽度设为100的模块上。但让我们来考虑一下一旦需求发生变更，宽度要改为200呢？或者改为250？这时你是去修改原型html里的类名？明显这与我们的初衷不吻合。既然我们将CSS单独放在一个文件中，我们的期望就是为了易于维护，样式与html分离，一旦外观样式发生变化，我们可以最少程度的去修改原型文件，而直接通过修改样式即可解决。
彬GO的一句总结很好：语义化命名，而不是结构化命名。（目前看来欠妥）
当然，这种方法最大程度的抽象出了通用属性，可以节省一定的CSS冗余代码，但这仅仅适用于后期变更很少的项目，即确定了此模块为100后期基本不会变化的情况。
还是一句话，前端技术没有银弹，没有最好的方法，只有最合适的方法。
--------------------------------
PS:感谢@贺师俊 指出，的确“结构化命名”欠妥，因为还有可能是诸如"color-red"这类型的通用原子类，而“结构化命名”仅仅指的是CSS的框模型的命名。希望没有误导大家。“样式描述命名”显得更合理一点。
没错，这样做是违背语义化的要求的。我已经批判过这种流传甚广的anti-pattern多次了。请顺序阅读这几篇blog：
http://hax.iteye.com/blog/497338
http://hax.iteye.com/blog/500015
http://hax.iteye.com/blog/849826 其实还是要根据项目来，并不能绝对说这种方法好或者不好。
比如那种需要很快输出，基本不需要要后期维护的项目，（例如活动页，新闻页等）。那这种预先定义样式的方法效率就很高。
而那种有大把时间死扣优化，或者体量很大需要精细维护的项目，还是模糊命名比较合适。
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名是需要语义化的，如果你的产品中发现需要这样的纯表现化的类，那么我觉得是没有设计好。 话说关于前端模块化的问题，我之前就蛮想探讨一下，不过没想到有人尽然问了，那我也顺便分享下自己的一些看法：
- 为什么需要CSS语义化？既然要用的话，你至少要知道原因吧，总不能因为“XX书上说要这样用”，所以我也这样用。个人认为是在CSS发展的初期，部分人喜欢用“样式信息”来为选择器命名，也就是用例如redBox，floatArea。这样的话，很明显是不太能满足开发的需要的，也就是 @interjc 同学提到的，后期可能会更改需求。所以，后来大家都开始建议用比较语义化的选择器，这样，一方面即使更改了需求，另外一方面，语义化毕竟是html&css发展的趋势，也算是为后期铺路（其中做得“最语义化”的应该就是微格式：http://microformats.org/，有兴趣的可以google下相关的）。
- 为什么要用模块化写法？我记得以前看过一本《Web前端开发修炼之道》（http://book.douban.com/subject/4881987/）的书，作者貌似是当时新浪前端的大牛，他在里面就提到了用.mt10，.fl等选择器来将一个“语义化的选择器”拆分，这样可以减少整体的代码量。除此之外，可以将大型网站的css利用MVC的设计思想，分为比较模块化的结构。
- 模块化写法和css语义化是否冲突？个人比较认同@顾轶灵 ，按照个人比较直白的话，就是这个意思：不要单纯追求“语义化”，你学到的相关知识都是为项目服务的。
- 我目前个人的项目经验，使用这种模块化写法并不和语义化相冲突。我一般会在比较大的区域上用语义化写法，而在嵌套不超过两层的标签上用模块化写法。因为现在每个项目，开始做的和最后成型的总是有差别的（也就是前面@火柴 同学说的），而且作为一个前端开发工程师，你到后面能改的，主要还是CSS（html如果已经和后台相关代码嵌套，要改的话多少会有点麻烦），如果完全用模块化写法，根本无法满足后期的需求；如果完全用语义化写法，会增加多于的选择器（比如有个地方只是要把那个字显示成红色）。
语义化与CSS、class的命名没有关系，跟JS也没直接关系（除了AJAX为主的网页在GOOGLE是有用URL中的hash地址来进行定位之外）。 有点太极端了就不好了，如果项目定型了，很少去动，可以用这样的，如果项目变动大，改起来太麻烦！有利有弊，以前有过这样的教训，所以，建议保留常用的几个，没必要w1到w100什么的，太碎了，很多都用不到！