恰逢我们需要用 Javascript 开发一套应用框架，于是尝试模仿原生程序的模式来做，完全没用 CSS，所有 style 定义都用 JS 函数动态生成。HTML 代码也用得很少，差不多就是一个初始框架，然后就进入 script 状态，靠 JS 来完成。框架已基本搭好，功能也正常。这里自然就产生一个问题：CSS 还有用吗？
我们毕竟水平有限，不敢过早下结论。请问各路大侠：对此你们怎么看？
89 个解决方案
#1
首先,据说css文件的执行速度要明显快于javascript,有些神人就只用css做些个动态玩艺.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
#2
首先,据说css文件的执行速度要明显快于javascript,有些神人就只用css做些个动态玩艺.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
#3
够用即可，如果js能完成全部需求，那么只用js即可。
如果js提供的功能与特性不能完全满足，再考虑css也可以。
相对于js，css控制dom的样式有一点点不同之处。
公共的css可以供多个页面访问，变更方便，而js需要测试的步骤要略多一步。
另外js操作效率要比浏览器解析速度要慢（也要分浏览器而论），如果加载的数据较多，性能可能有影响。
暂时就想到这些。
#4
谢谢楼上两位的回复。下面继续讨论。
JS 和 CSS 谁更有利于项目管理？我感觉此问题值得商榷。假定一个 JS 函数和一组 CSS 定义完成同样的功能，看起来二者差别不大，但 JS 函数很容易借助参数来变通，同一个函数可以完成多种 style 定义，而且通过传参数的方式让程序清晰易读。CSS 实现同样的变通很困难，勉强做出来也搞得程序晦涩难懂。CSS 本质上是一种静态描述。
假定有个 JS 函数 setObjStyle，用来给 object 设定 style，其中包含一组默认设定，这是固定的。但是还可以传入这样的对象参数 {color:'red', backGround:'yellow'}，用来通知函数：这两项要用参数指定的值，而不是默认值。CSS 能这么容易实现同样功能吗？
JS 和 CSS 谁更有利于项目管理？我感觉此问题值得商榷。假定一个 JS 函数和一组 CSS 定义完成同样的功能，看起来二者差别不大，但 JS 函数很容易借助参数来变通，同一个函数可以完成多种 style 定义，而且通过传参数的方式让程序清晰易读。CSS 实现同样的变通很困难，勉强做出来也搞得程序晦涩难懂。CSS 本质上是一种静态描述。
假定有个 JS 函数 setObjStyle，用来给 object 设定 style，其中包含一组默认设定，这是固定的。但是还可以传入这样的对象参数 {color:'red', backGround:'yellow'}，用来通知函数：这两项要用参数指定的值，而不是默认值。CSS 能这么容易实现同样功能吗？
#5
css文件可能不需要，但css知识是跑不开的。
#6
如果你是一种修辞，同意你的说法。
CSS 知识大致包含以下几部分：
1. style 概念，style 属性名称和赋值方式。
2. CSS 语法和词汇，即如何建造 CSS 结构。
3. CSS 结构在 Web 体系中的使用方法。
如果不再使用 CSS，后面两部分知识也就不需要了，只需要了解第一部分。style 概念既已融入 JS，那就成为纯粹的 JS 对象，和 CSS 没什么关系了。对新手来说这是一种解脱，毕竟要熟练掌握 CSS 构造和使用方法需要投入大量时间。国外那些 CSS 专家能为此写出一大本教科书来。还有那些大神级高手，把 CSS 玩得出神入化，让菜鸟们望而生畏。不禁让人想起那些红学专家，连秦可卿的腰带都能鼓捣出一大篇长文来。玩弄这些真的有必要吗？
#7
css 是少不了的。
dom.style 也是 css
dom.style 也是 css
#8
hch126163，谢谢提醒。按我的理解，JS 能访问所有 DOM 对象。DOM 是一种公共平台，多种语言都可以访问。既然如此，那么 CSS 就不是必不可少。
很想在此把问题彻底弄清。我们的应用框架至今大约写了几千行，涉及 Web 开发的方方面面，还没有发现 JS 不能取代 CSS 之处（暂时不涉及运行速度，那需要严格测试才能确定）。如果你能找出这样的例子，非 CSS 不能完成，或者最后发现找不出这样的例子，我们都将不胜感激。
#9
额.........楼主就是想用js的话,在一部分地方确实行的通,毕竟现在都能用js做浏览器系统了.不过在我看来什么事情都是一样,尽量把它们分解开来处理计较容易理解,这就跟好几样菜要用好几个盘子盛一个意思,都用js很容易把画面美工和程序动作混在一起,十几个人还好,人一多很乱,很难搞的.
另外,现实也确实要求css存在,恰巧今天就接了个新项目,人家就问到美工由哪边负责,我们当然就说他们做好了css+html样本发给我们,而不是我们照着他们的css再往自己的js上贴.
另外,现实也确实要求css存在,恰巧今天就接了个新项目,人家就问到美工由哪边负责,我们当然就说他们做好了css+html样本发给我们,而不是我们照着他们的css再往自己的js上贴.
#10
css肯定会要的
javascript是根据需要动态改变css的内容
javascript是根据需要动态改变css的内容
#11
CSS和js完全不同的两个东西
#12
shangdaming 反复强调项目组分工问题。我感觉这的确是个着重点，不能忽视，毕竟目前流行的开发方式都需要美工参与前期编码，需要有一个适当切分点，让美工和后期编码衔接起来。
假如有一款软件，给美工提供某种所见即所得工作环境，只管页面布局、色彩、图片、字体等等，完全不接触代码，软件把美工设计自动转换成代码，是否可行？不是 DreamWeaver 那样的软件，DreamWeaver 要做的事太多，不适合美工用，生成的代码也不适合我们现在讨论的目标。这种软件应该集中完成比较窄的专业功能，就像那种音乐创作软件，创作者只管在 midi 键盘上敲敲打打，软件自动生成五线谱和 midi 文件。
假如有这样一款软件，是否可以解决上面说的项目分工问题，无需纠缠 CSS 还是 JS？
假如有一款软件，给美工提供某种所见即所得工作环境，只管页面布局、色彩、图片、字体等等，完全不接触代码，软件把美工设计自动转换成代码，是否可行？不是 DreamWeaver 那样的软件，DreamWeaver 要做的事太多，不适合美工用，生成的代码也不适合我们现在讨论的目标。这种软件应该集中完成比较窄的专业功能，就像那种音乐创作软件，创作者只管在 midi 键盘上敲敲打打，软件自动生成五线谱和 midi 文件。
假如有这样一款软件，是否可以解决上面说的项目分工问题，无需纠缠 CSS 还是 JS？
#13
UI方面..css比js更好理解和维护,比如:
你用JS如何实现??你是动态创建 style 标签(这还是用到css了)? 还是便历所有 #demo 下的p标签然后修改每一个p标签的css属性??
#demo p{color:red}
你用JS如何实现??你是动态创建 style 标签(这还是用到css了)? 还是便历所有 #demo 下的p标签然后修改每一个p标签的css属性??
#14
终于见到实例，谢谢 plzzz。不忙回答，希望看到更多例子。
#15
在这种问题上扣貌似没什么意义，怎么爽怎么写。
#16
你这观点只站在个人角度看问题，很难苟同。假如 CSS 真的不需要，为何还要那么多人去研究它，还要初学者花那么多时间来学？本来可以用一种语言编写的软件，我偏要用两种语言来写，就因为我觉得爽，然后还要让你来维护，你喜欢吗？
#17
定位完全不重叠。
#18
css和js是两种不同的概念，分工不同。
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
#19
css和js是两种不同的概念，分工不同。
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
上面的链接，是css做出的各种形状。
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
上面的链接，是css做出的各种形状。
#20
当深入理解css，就会发现其实css功能也很强大，甚至有的css功能可以完全代替一些js的效果。比如3d旋转。
#21
学习了,之前一直用notpad++
#22
朱羽佳是 CSS 粉丝呀，欢迎加入讨论。
CSS 粉丝如云，这很自然。CSS 比 Javascript 差不多早了十年。CSS 正式版是 96 年发布，那时候 JS 刚有个雏形，其后发展也不顺利。有 Java 和微软的 script 当道，谁更有出息当时都不好说。也就是七、八年前，JS 才被人看好，但一直被当做一种小技巧玩。一直到 HTML5 流行了，大家才说：噢，JS 还有这么多功能啊。
Web 前端开发需要一种功能强大的编程语言，只靠 HTML 和 CSS，浏览器永远都是网络版电子书，不可能达到 native 程序那种境界。现在看来，这种语言非 JS 莫属。
JS 包含了 CSS 的全部样式描述功能。可以这么说，凡 CSS 能做的事，JS 都能做，反之则不成立。我们讨论的分歧点是：同一件事，用 CSS 做更合理还是用 JS 独自完成更合理。这里说的合理是指更易读易维护，更有效率。如果多数情况下用 CSS 更合理，那么它还有生命力，否则将随着 JS 的流行而退位，变成少数玩家的鉴赏品。
JS 的样式描述是以对象的 style 属性来实现，和 HTML 标签有点相似，不像 CSS，先定义 selector 和style，然后再以各种形式应用到代码中。因此很多人产生一种错觉，感觉 JS 操作 style 的方式要低一个档次。其实，JS 既然是一种程序设计语言，它就可以借助变量和函数灵活操纵数据，完全可以像 CSS 那样事先定义 style 然后再去应用，而且可以做得比 CSS 更好。如果你有兴趣，甚至可以借助 JS 设计出一套不同的 CSS 来（我们做过这种尝试，此处不谈细节）。
CSS 粉丝如云，这很自然。CSS 比 Javascript 差不多早了十年。CSS 正式版是 96 年发布，那时候 JS 刚有个雏形，其后发展也不顺利。有 Java 和微软的 script 当道，谁更有出息当时都不好说。也就是七、八年前，JS 才被人看好，但一直被当做一种小技巧玩。一直到 HTML5 流行了，大家才说：噢，JS 还有这么多功能啊。
Web 前端开发需要一种功能强大的编程语言，只靠 HTML 和 CSS，浏览器永远都是网络版电子书，不可能达到 native 程序那种境界。现在看来，这种语言非 JS 莫属。
JS 包含了 CSS 的全部样式描述功能。可以这么说，凡 CSS 能做的事，JS 都能做，反之则不成立。我们讨论的分歧点是：同一件事，用 CSS 做更合理还是用 JS 独自完成更合理。这里说的合理是指更易读易维护，更有效率。如果多数情况下用 CSS 更合理，那么它还有生命力，否则将随着 JS 的流行而退位，变成少数玩家的鉴赏品。
JS 的样式描述是以对象的 style 属性来实现，和 HTML 标签有点相似，不像 CSS，先定义 selector 和style，然后再以各种形式应用到代码中。因此很多人产生一种错觉，感觉 JS 操作 style 的方式要低一个档次。其实，JS 既然是一种程序设计语言，它就可以借助变量和函数灵活操纵数据，完全可以像 CSS 那样事先定义 style 然后再去应用，而且可以做得比 CSS 更好。如果你有兴趣，甚至可以借助 JS 设计出一套不同的 CSS 来（我们做过这种尝试，此处不谈细节）。
#23
继续上面的讨论。先思考一个问题：native 程序也需要修饰界面，甚至比网页要求更高，为何没有出现类似 CSS 这样的东西？
答案应该不难找到。native 程序从一开始就是靠编程语言来实现。从汇编语言到高级语言，从简单的 DOS 界面到图形用户界面，一切都靠编程语言动态实现。现代操作系统都在底层准备好了图形用户界面的基本元素，应用程序只要调用 API 功能就能实现复杂的交互界面。各种集成化编程环境又把这种调用包装成所见即所得操作，应用开发者甚至不用考虑界面编码问题，其强大功能和复杂程度远非 HTML + CSS 所能及。这种环境自然没有 CSS 类静态描述手段的生存余地。
由于面向对象设计方法的影响，native 程序员从初学时都要遵循一条原则：对象的描述和操作代码，无论是属性、事件还是方法，应当尽量包封在一起，做成一个零部件，通过规范的接口与外界连接。紧内聚，松耦合，这是 native 设计的座右铭。按照这种原则，一个对象的 style 描述应当和对象核心代码包封在一起。这并不意味不同对象的 style 描述会导致大量重复代码，因为不同对象可以通过函数调用共享代码。
那么，JS 是否可以实现类似 native 程序那样的设计方式？理论上应该可以实现，JS 也的确具备这种功能。只不过浏览器还没有为此做好准备，浏览器比起操作系统来还很原始。HTML5 对浏览器标准做了大量横向扩展，甚至把图形和多媒体都包括进来，但其纵向功能几乎停留在原始状态。JS 要完成这些横向功能，需要码农们自己去堆砌大量代码，导致加载和运行缓慢，影响用户体验。FaceBook 为此还栽了个跟头，差点真成了“非死不可”。
但这并不说明 Web 设计应该停留在 HTML + CSS 时代。要是那样的话，Web 应用取代 native 应用只能是幻想，HTML5 也没什么前途。FireFox OS 也许是个不错的尝试，还未实际体验过，不知他们细节处理得怎么样。但愿他们能冲破 Web 设计的惯性思维，搞出点新东西来。
答案应该不难找到。native 程序从一开始就是靠编程语言来实现。从汇编语言到高级语言，从简单的 DOS 界面到图形用户界面，一切都靠编程语言动态实现。现代操作系统都在底层准备好了图形用户界面的基本元素，应用程序只要调用 API 功能就能实现复杂的交互界面。各种集成化编程环境又把这种调用包装成所见即所得操作，应用开发者甚至不用考虑界面编码问题，其强大功能和复杂程度远非 HTML + CSS 所能及。这种环境自然没有 CSS 类静态描述手段的生存余地。
由于面向对象设计方法的影响，native 程序员从初学时都要遵循一条原则：对象的描述和操作代码，无论是属性、事件还是方法，应当尽量包封在一起，做成一个零部件，通过规范的接口与外界连接。紧内聚，松耦合，这是 native 设计的座右铭。按照这种原则，一个对象的 style 描述应当和对象核心代码包封在一起。这并不意味不同对象的 style 描述会导致大量重复代码，因为不同对象可以通过函数调用共享代码。
那么，JS 是否可以实现类似 native 程序那样的设计方式？理论上应该可以实现，JS 也的确具备这种功能。只不过浏览器还没有为此做好准备，浏览器比起操作系统来还很原始。HTML5 对浏览器标准做了大量横向扩展，甚至把图形和多媒体都包括进来，但其纵向功能几乎停留在原始状态。JS 要完成这些横向功能，需要码农们自己去堆砌大量代码，导致加载和运行缓慢，影响用户体验。FaceBook 为此还栽了个跟头，差点真成了“非死不可”。
但这并不说明 Web 设计应该停留在 HTML + CSS 时代。要是那样的话，Web 应用取代 native 应用只能是幻想，HTML5 也没什么前途。FireFox OS 也许是个不错的尝试，还未实际体验过，不知他们细节处理得怎么样。但愿他们能冲破 Web 设计的惯性思维，搞出点新东西来。
#24
各有所需吧。。。
#25
举一个常见场景
有一个 div 在不同状态下有不同的表现
你是 每种状态给一个 样式
还是 每种状态 在代码中设置一堆 属性呢？
另外 编程 最终 就是 围绕配置 编程
大堆的 数据一般 都是写在配置文件中的
样式表 你恰恰可以看成一个 配置文件
你说的 style 全是 动态生成 那么我觉得 要么你的代码的可配制性不够 要么你的代码 只涉及了很简单的css
有一个 div 在不同状态下有不同的表现
你是 每种状态给一个 样式
还是 每种状态 在代码中设置一堆 属性呢？
另外 编程 最终 就是 围绕配置 编程
大堆的 数据一般 都是写在配置文件中的
样式表 你恰恰可以看成一个 配置文件
你说的 style 全是 动态生成 那么我觉得 要么你的代码的可配制性不够 要么你的代码 只涉及了很简单的css
#26
目前来说，css还没有退位的迹象，
只能是css有其所不足，而js有其无所不能！
最近本人做的一个小站，就是因为css力不从心，最终还是借助js在几位大佬的帮助下，实现了最终的功能。
只能是css有其所不足，而js有其无所不能！
最近本人做的一个小站，就是因为css力不从心，最终还是借助js在几位大佬的帮助下，实现了最终的功能。
#27
emituofo 说得真含蓄：只能是css有其所不足，而js有其无所不能！虽有点绕嘴，意思不错。
上面 plzzz 举了这样一个 CSS 例子：#demo p{color:red}。不妨借此例诠释一下 emituofo 的说法。
此处，demo 是标签的 id，p 是 tagName。假如我们有一个setObjStyle 函数，专门用来为 object 设置 style，函数大致如此：
function setObjStyle(obj){
if (!obj) return;
if (obj.id == 'demo' && obj.tagName == 'P'){
obj.style.color = 'red';
// 以下是其他设置
}
// 以下是其他条件
}
这只是函数的一部分。既然要为所有 object 设置 style，它当然还要包含其他内容。需要说明的是，实际函数也许不会这样写，这里只是为了说明 plzzz 的例子。从设计模式角度来说，此函数是整个程序的样式处理中心，而 demo 只是个案，其样式设置应该放在 demo 自身的处理过程中（在其中调用 setObjStyl 函数），这样才易读易维护。从此例已经可以看出 JS 的灵活性和强大功能。
那么，在 demo 处理过程中为 p 标签设置样式，是否如 plzzz 所担心，需要遍历 p 呢？按我们的处理方式是不需要的。我们的应用框架中，除了 head 和 body 这样的基础标签，差不多所有 DOM 结点都是动态生成，其 style 在生成时就可以设定，无需另外再遍历。
上面 plzzz 举了这样一个 CSS 例子：#demo p{color:red}。不妨借此例诠释一下 emituofo 的说法。
此处，demo 是标签的 id，p 是 tagName。假如我们有一个setObjStyle 函数，专门用来为 object 设置 style，函数大致如此：
function setObjStyle(obj){
if (!obj) return;
if (obj.id == 'demo' && obj.tagName == 'P'){
obj.style.color = 'red';
// 以下是其他设置
}
// 以下是其他条件
}
这只是函数的一部分。既然要为所有 object 设置 style，它当然还要包含其他内容。需要说明的是，实际函数也许不会这样写，这里只是为了说明 plzzz 的例子。从设计模式角度来说，此函数是整个程序的样式处理中心，而 demo 只是个案，其样式设置应该放在 demo 自身的处理过程中（在其中调用 setObjStyl 函数），这样才易读易维护。从此例已经可以看出 JS 的灵活性和强大功能。
那么，在 demo 处理过程中为 p 标签设置样式，是否如 plzzz 所担心，需要遍历 p 呢？按我们的处理方式是不需要的。我们的应用框架中，除了 head 和 body 这样的基础标签，差不多所有 DOM 结点都是动态生成，其 style 在生成时就可以设定，无需另外再遍历。
#28
继续讨论，谈谈 JS 的配置功能。KK3K2005 的说法触及到我们讨论的焦点：JS 有没有 CSS 那样的配置功能？这里说的配置应该不是纯函数形式，我们不能一改变配置就去修改函数。应该有一种文本形式来描述整个应用的初始样式设置，只要修改文本就能修改配置。这正是创建 CSS 的初衷。
如果熟悉 native 软件设计，应该不必怀疑 JS 此项功能。所有 native 编程环境都可以创建灵活多样的初始化配置，JS 作为一种编程语言也是这样。我们可以用 json 形式为它写配置，也可以模仿 CSS 格式来写，顺便把 CSS 中带 '-' 的标记改成 HTML 和 JS 的统一格式（鬼知道为何要弄出两套东西来），或者采用另外一种更简洁高效的格式。这都没关系，JS 想做什么都不难。我们还可以实现客户化配置：给用户一个专门界面来设定自己的配置。如果不惧 HTML5，不妨用 localStorage 来保存用户配置。
其实，像 CSS 那样用文本来写配置并不合理。最好的做法就是有个专门的配置程序，来个所见即所得，就像上面我曾经提到过的。这样，美工就不必再去研究编码问题，可以专心于自己的美术设计。这种功能当然离不开 JS。
需要特别强调的是，我们不能滥用配置。配置应该是面向全局的，需要尽量缩小应用范围。把什么都往配置里塞，会让程序的处理代码和属性描述分离，这不符合面向对象的设计概念，会增加维护的难度。有些人玩 CSS 玩得兴起，就不考虑这一点了。
如果熟悉 native 软件设计，应该不必怀疑 JS 此项功能。所有 native 编程环境都可以创建灵活多样的初始化配置，JS 作为一种编程语言也是这样。我们可以用 json 形式为它写配置，也可以模仿 CSS 格式来写，顺便把 CSS 中带 '-' 的标记改成 HTML 和 JS 的统一格式（鬼知道为何要弄出两套东西来），或者采用另外一种更简洁高效的格式。这都没关系，JS 想做什么都不难。我们还可以实现客户化配置：给用户一个专门界面来设定自己的配置。如果不惧 HTML5，不妨用 localStorage 来保存用户配置。
其实，像 CSS 那样用文本来写配置并不合理。最好的做法就是有个专门的配置程序，来个所见即所得，就像上面我曾经提到过的。这样，美工就不必再去研究编码问题，可以专心于自己的美术设计。这种功能当然离不开 JS。
需要特别强调的是，我们不能滥用配置。配置应该是面向全局的，需要尽量缩小应用范围。把什么都往配置里塞，会让程序的处理代码和属性描述分离，这不符合面向对象的设计概念，会增加维护的难度。有些人玩 CSS 玩得兴起，就不考虑这一点了。
#29
接楼上的 不懂编程 或者 编程水平一般的人 是写不出 结构合理的配置的
而对于 html概念不深的程序员 也写不出 好的 css
所以 前端是一个有难度的工作 需要对于 页面和逻辑都精通的人才 能进行view层次框架性质的开发
mvc么 很多程序员其实都只在c层写代码
而对于 html概念不深的程序员 也写不出 好的 css
所以 前端是一个有难度的工作 需要对于 页面和逻辑都精通的人才 能进行view层次框架性质的开发
mvc么 很多程序员其实都只在c层写代码
#30
一般情况下，能用CSS就可以设置好的，就不要用js来做。主要原因就是效率问题。一般情况下，美工是专门做CSS，会js的话要求太高了。
#31
这应该是个人风格问题..
比如隐藏一个元素,很多人都是setStyle('display':'none')这样设置,而YUI3推荐的方法是 addClass('xxx-hidden'),然后另外再写一个CSS如: .xxx-hidden{display:none}
这样检测元素是否可见 用 hasClass('xxx-hidden') ,而 getStyle('display')这个计算感觉比 hasClass 要复杂.
比如隐藏一个元素,很多人都是setStyle('display':'none')这样设置,而YUI3推荐的方法是 addClass('xxx-hidden'),然后另外再写一个CSS如: .xxx-hidden{display:none}
这样检测元素是否可见 用 hasClass('xxx-hidden') ,而 getStyle('display')这个计算感觉比 hasClass 要复杂.
#32
存在即合理，如果只是想自己实现某些功能，那么用JS完全可以，如果商业项目中，假如是传统页面，那么肯定是CSS，JS分开，如果是web app，那么HTML中则不需要什么东西，处于性能考虑，肯定是能独立出CSS文件的，全部都独立出CSS文件。
#33
js控制样式不还是借助css 还是说你们只是在讨论是否有必要写.css文件?
#34
css很有用,特别是开发组件的时候,它可以让你的组件逻辑与样式分离,这意味着可以把样式留给专业的美工来做,js程序员可以把时间放在组件逻辑上,提高开发效率.
并且样式与逻辑分离,这也意味着组件更灵活,使用者可以通过重写一个css在全局改变组件的默认样式
并且样式与逻辑分离,这也意味着组件更灵活,使用者可以通过重写一个css在全局改变组件的默认样式
#35
不说别的了，楼主看看Google，微软等大牛云集的网站，看看有没有css
#36
wbb123yu，JS 的 style 是否属于 CSS，我觉得这无关紧要，谈论这个没有意义。
也不仅仅是 CSS 文件的问题。CSS 也可以没有独立文件呀。分歧点在于：如果 JS 能完成，是否还需要定义独立的 CSS 结构，程序员是否还有必要去研讨 CSS 语法和用法，那毕竟也是一套独特的知识体系。撇开 CSS 和 JS 用两套标识符不说，要熟练掌握 selector 的定义方式也不易。还有其他分歧，先不提了。
用 JS 的好像有两类人。一类是从 HTML, CSS 走过来的，另一类是从 native 程序设计转来的（我属于这种）。感觉这两帮人就像两个部落，中间隔着一堵墙。
也不仅仅是 CSS 文件的问题。CSS 也可以没有独立文件呀。分歧点在于：如果 JS 能完成，是否还需要定义独立的 CSS 结构，程序员是否还有必要去研讨 CSS 语法和用法，那毕竟也是一套独特的知识体系。撇开 CSS 和 JS 用两套标识符不说，要熟练掌握 selector 的定义方式也不易。还有其他分歧，先不提了。
用 JS 的好像有两类人。一类是从 HTML, CSS 走过来的，另一类是从 native 程序设计转来的（我属于这种）。感觉这两帮人就像两个部落，中间隔着一堵墙。
#37
这个问题我在前面已谈过不少，你大概没看吧？
#38
说这个没意义。科技不是靠人多势众，也不是靠权威和名气。当年微软对移动计算看不上眼，英特尔也是不摆 ARM，这才过了几年，现在怎么样？有道理就讲道理，千万别甩出权威来以势压人，IT 界不兴这个。
#39
我个人觉得有集中原因 css文件便于管理 和css效率比js的高 js可以做css的工作但是他没有css原生做得好； 不是一个语言能做另一个语言的事就能代替它的 你要比他方便，效率高，便于管理，功能强大等等。。 这样才会被替代
#40
我们的目的都是一样的，就是将页面完美的呈现出来，只是所用的方式不同。
像我这种对于JS不怎么熟练的开发人员来说，更偏向于用CSS来表现页面。毕竟先接触CSS，后接触JS。
而且现在的页面都是等到HTML加载完了，再去加载JS，这个过程就会让用户先看到很呆板的纯文字的页面，如果最后加载的JS有一点小错误的话，可能会导致JS写的那些CSS效果加载不出来，影响用户查看页面。
而CSS不同，CSS优先加载，而后在加载HTML结构，这样就不会影响用户查看页面。
另外，CSS相对于JS，修改起来也方便（个人觉得）。大小也要比JS小吧。
像我这种对于JS不怎么熟练的开发人员来说，更偏向于用CSS来表现页面。毕竟先接触CSS，后接触JS。
而且现在的页面都是等到HTML加载完了，再去加载JS，这个过程就会让用户先看到很呆板的纯文字的页面，如果最后加载的JS有一点小错误的话，可能会导致JS写的那些CSS效果加载不出来，影响用户查看页面。
而CSS不同，CSS优先加载，而后在加载HTML结构，这样就不会影响用户查看页面。
另外，CSS相对于JS，修改起来也方便（个人觉得）。大小也要比JS小吧。
#41
我们也做过HTML结构都是由JS生成的项目（所有的HTML都是由JS生成，动态添加），但是都是在我做好的HTML+CSS基础上完成的。
LZ说了，所有样式定义都是JS动态生成。我想这应该也是在做好的页面（HTML+CSS）上完成的吧，不然怎么知道哪里该用什么样的样式呢？
#42
全用js页面风格如何复用统一，如何修改维护，全都改一遍吗
#43
谢谢理性回帖。
你好像不熟悉 JS 编程，所以有此担心。CSS 是样式描述语言，JS 是程序设计语言，二者不是一个等级。前者不能代替后者，后者却能完成前者的功能。我在前面已详尽说明，还包括 plzzz 举的例子，烦请再去读一下。
#44
...真不知道LZ再说什么 你说JS代替CSS 怎么代替 JS本身又没有改变元素样式的功能 他的改变样式也是改的CSS 没CSS 你怎么变
再说了 CSS和JS效率根本不能比
再比如 js改变dom结构 那么难道每次都要用js在刷一下样式么 不然根本就是默认样式 css文件的样式是即时渲染的 但是js改变dom结构后的 比如加个样式已有的div一样的div 那这个div的样式还必须用js全部重新写 用css则不必 真不懂怎么会出现这种说法
再说了 CSS和JS效率根本不能比
再比如 js改变dom结构 那么难道每次都要用js在刷一下样式么 不然根本就是默认样式 css文件的样式是即时渲染的 但是js改变dom结构后的 比如加个样式已有的div一样的div 那这个div的样式还必须用js全部重新写 用css则不必 真不懂怎么会出现这种说法
#45
终于见到同类了，呵呵。我们的编程方式完全不同，HTML 只有 head 和 body 两个简单标签，body 里面只有 script，一上来就运行 JS StartUp 函数，很像早年 C 语言里那个 main 函数。能理解兄台的担心：看不到东西怎么调试呢？我们是采用构件方式来解决。大致描述下，希望能说明问题。
像 Delphi, C++, VB, Java, Flex 这类都可以用构件来生成界面，不用运行就能看到界面效果，那需要有 IDE 集成环境的支持。DreamWeaver 也提供了类似集成环境，但功能太弱，缺少对 JS 的支持。但这不等于说 JS 不能用构件编程。其实，native 程序的构件也不是非要所见即所得。构件最终还是一堆 OOP 代码，只要构件成熟，直接去调用构件对象，效果是一样的，不同的只是运行起来才能看到效果。
JS 也算是一种准 OOP 语言吧，只是不如 native 编程语言好用。我们是以 div, table 这类 DOM 成员建造基础 JS 对象，用 construtor 设置默认样式。每个对象有个可变参数 style，其内容可想而知，就是用来改变默认样式。所以，像前面几位说的，能不能整体修改维护，那都不是问题。
只有基本 JS 构件还不行，我们以此为基础建造了 Layout 构件，用来形成页面布局。Layout 对象可以借助参数形成多种多样的布局，同时也借助 style 参数形成不同样式。有了这些，只需几行 JS 代码就能完成一个 Web 页面，包括下拉菜单、标签页、图片集、分栏文本等等，样式也可以丰富多彩。由于构件都是事先调试好的，做二次开发时不用担心弄错哪里显示不出来。JS 就这毛病，要是不熟练，一点问题就能搞得天昏地暗，到最后发现就错了一个字符，所以更需要一种合理的团队组织方式。
我们研究过流行的 Web 设计框架，吸取了它们的长处，同时也尽量回避其缺点。设计这种东西不容易。正像兄台及前面几位所说，既要考虑编程效率，也要考虑加载速度和运行速度。我们还只是一种尝试，需要做的还很多。好在我们的代码足够精炼，目前没有太大问题。如果 JS 构件库变得很大，就得选择动态加载：需要什么加载什么，不需要的留在服务器端。
#46
楼上很多认为牵涉到样式就是css 不过想一想css是"层叠样式表"就会明白样式是在css之前的.用js控制样式的话,跟css是没有任何关系的.
#47
CSS是用来排版用的，js是用来互动用的，不能混淆
#48
native vs web，
复杂运用 vs 简单页面
复杂类库+层层封装 vs 切面处理，html管内容，css管样式，js管特效
web向native学习，以AJAX为工具模仿运用，超大的类库还是个硬伤，10秒内看不到内容，手机用户下载xxxK的库都会严重影响用户体验。
所以看运用环境吧，某些特定环境下纯js是成立的，但大部分的轻量级运用，css文件还是比纯js来得简洁。
复杂运用 vs 简单页面
复杂类库+层层封装 vs 切面处理，html管内容，css管样式，js管特效
web向native学习，以AJAX为工具模仿运用，超大的类库还是个硬伤，10秒内看不到内容，手机用户下载xxxK的库都会严重影响用户体验。
所以看运用环境吧，某些特定环境下纯js是成立的，但大部分的轻量级运用，css文件还是比纯js来得简洁。
#49
ftiger 说得很在行，句句到位，除了最后那句。
轻量级应用，JS 和传统 Web 速度差别不大。个人感觉 JS 更简洁，因为 JS 可以把复杂结构变成简单的函数调用。其复杂性在于构筑底层 API。一旦 API 成形，二次开发比传统 Web 简单。
复杂应用，传统 Web 做不到，JS 能实现，但有点笨重。所以目前 JS 还不能取代 native 程序。围绕 Facebook 那场争执，一方说：HTML5 还没准备好；另一方说：不是 HTML5 不行，是你不会用。看不到细节，所以不好断定。
往后就不好说了。相信 JS 引擎还能提速，但要有关键技术改进。硬件也会提速，期待 10 纳米技术。每次硬件提速都会引起软件改革。要是用20年前的硬件，Windows 95 也跑不动。
大趋势是传统 Web 技术被淘汰，但还需要时间。
轻量级应用，JS 和传统 Web 速度差别不大。个人感觉 JS 更简洁，因为 JS 可以把复杂结构变成简单的函数调用。其复杂性在于构筑底层 API。一旦 API 成形，二次开发比传统 Web 简单。
复杂应用，传统 Web 做不到，JS 能实现，但有点笨重。所以目前 JS 还不能取代 native 程序。围绕 Facebook 那场争执，一方说：HTML5 还没准备好；另一方说：不是 HTML5 不行，是你不会用。看不到细节，所以不好断定。
往后就不好说了。相信 JS 引擎还能提速，但要有关键技术改进。硬件也会提速，期待 10 纳米技术。每次硬件提速都会引起软件改革。要是用20年前的硬件，Windows 95 也跑不动。
大趋势是传统 Web 技术被淘汰，但还需要时间。
#50
程序是现实世界的抽象，模式是程序的抽象。
从要表现的内容来看，个人认为web程序抽象有两个方向的不同侧重，面向业务或面向内容/娱乐。
面向业务，表现为一大堆相似的view，大量的表格表单，复杂的菜单，复杂而多变的业务逻辑。在这个方向上，个人认为复杂类库+层层封装，使用MVVP模式也就是将view先抽象出来，然后可以集中精力去处理业务逻辑，在这样的运用环境下，放弃css文件是可行的。
面向内容/娱乐，比如blog，bbs，信息发布平台,相对简单的逻辑，大量成熟的程序，很多新手下载个源码就可以搭建起来，这时候个性化改版成为常规要求，这时只学习html+css的网页美工切工能力占优，程序员反而大部分美感缺缺，css相对简单的结构，可以在可视化环境下修改界面的优势比用js实现占优。
css和js已经并行发展了这么多年，谁也没能说能代替谁。
从要表现的内容来看，个人认为web程序抽象有两个方向的不同侧重，面向业务或面向内容/娱乐。
面向业务，表现为一大堆相似的view，大量的表格表单，复杂的菜单，复杂而多变的业务逻辑。在这个方向上，个人认为复杂类库+层层封装，使用MVVP模式也就是将view先抽象出来，然后可以集中精力去处理业务逻辑，在这样的运用环境下，放弃css文件是可行的。
面向内容/娱乐，比如blog，bbs，信息发布平台,相对简单的逻辑，大量成熟的程序，很多新手下载个源码就可以搭建起来，这时候个性化改版成为常规要求，这时只学习html+css的网页美工切工能力占优，程序员反而大部分美感缺缺，css相对简单的结构，可以在可视化环境下修改界面的优势比用js实现占优。
css和js已经并行发展了这么多年，谁也没能说能代替谁。
#1
首先,据说css文件的执行速度要明显快于javascript,有些神人就只用css做些个动态玩艺.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
#2
首先,据说css文件的执行速度要明显快于javascript,有些神人就只用css做些个动态玩艺.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
其次,css和js文件分开有利与项目管理.
最后,也是最重要的,比如我们公司,大规模开发,美工和我们是分开的,让他们搞javascript太难了.
#3
够用即可，如果js能完成全部需求，那么只用js即可。
如果js提供的功能与特性不能完全满足，再考虑css也可以。
相对于js，css控制dom的样式有一点点不同之处。
公共的css可以供多个页面访问，变更方便，而js需要测试的步骤要略多一步。
另外js操作效率要比浏览器解析速度要慢（也要分浏览器而论），如果加载的数据较多，性能可能有影响。
暂时就想到这些。
#4
谢谢楼上两位的回复。下面继续讨论。
JS 和 CSS 谁更有利于项目管理？我感觉此问题值得商榷。假定一个 JS 函数和一组 CSS 定义完成同样的功能，看起来二者差别不大，但 JS 函数很容易借助参数来变通，同一个函数可以完成多种 style 定义，而且通过传参数的方式让程序清晰易读。CSS 实现同样的变通很困难，勉强做出来也搞得程序晦涩难懂。CSS 本质上是一种静态描述。
假定有个 JS 函数 setObjStyle，用来给 object 设定 style，其中包含一组默认设定，这是固定的。但是还可以传入这样的对象参数 {color:'red', backGround:'yellow'}，用来通知函数：这两项要用参数指定的值，而不是默认值。CSS 能这么容易实现同样功能吗？
JS 和 CSS 谁更有利于项目管理？我感觉此问题值得商榷。假定一个 JS 函数和一组 CSS 定义完成同样的功能，看起来二者差别不大，但 JS 函数很容易借助参数来变通，同一个函数可以完成多种 style 定义，而且通过传参数的方式让程序清晰易读。CSS 实现同样的变通很困难，勉强做出来也搞得程序晦涩难懂。CSS 本质上是一种静态描述。
假定有个 JS 函数 setObjStyle，用来给 object 设定 style，其中包含一组默认设定，这是固定的。但是还可以传入这样的对象参数 {color:'red', backGround:'yellow'}，用来通知函数：这两项要用参数指定的值，而不是默认值。CSS 能这么容易实现同样功能吗？
#5
css文件可能不需要，但css知识是跑不开的。
#6
如果你是一种修辞，同意你的说法。
CSS 知识大致包含以下几部分：
1. style 概念，style 属性名称和赋值方式。
2. CSS 语法和词汇，即如何建造 CSS 结构。
3. CSS 结构在 Web 体系中的使用方法。
如果不再使用 CSS，后面两部分知识也就不需要了，只需要了解第一部分。style 概念既已融入 JS，那就成为纯粹的 JS 对象，和 CSS 没什么关系了。对新手来说这是一种解脱，毕竟要熟练掌握 CSS 构造和使用方法需要投入大量时间。国外那些 CSS 专家能为此写出一大本教科书来。还有那些大神级高手，把 CSS 玩得出神入化，让菜鸟们望而生畏。不禁让人想起那些红学专家，连秦可卿的腰带都能鼓捣出一大篇长文来。玩弄这些真的有必要吗？
#7
css 是少不了的。
dom.style 也是 css
dom.style 也是 css
#8
hch126163，谢谢提醒。按我的理解，JS 能访问所有 DOM 对象。DOM 是一种公共平台，多种语言都可以访问。既然如此，那么 CSS 就不是必不可少。
很想在此把问题彻底弄清。我们的应用框架至今大约写了几千行，涉及 Web 开发的方方面面，还没有发现 JS 不能取代 CSS 之处（暂时不涉及运行速度，那需要严格测试才能确定）。如果你能找出这样的例子，非 CSS 不能完成，或者最后发现找不出这样的例子，我们都将不胜感激。
#9
额.........楼主就是想用js的话,在一部分地方确实行的通,毕竟现在都能用js做浏览器系统了.不过在我看来什么事情都是一样,尽量把它们分解开来处理计较容易理解,这就跟好几样菜要用好几个盘子盛一个意思,都用js很容易把画面美工和程序动作混在一起,十几个人还好,人一多很乱,很难搞的.
另外,现实也确实要求css存在,恰巧今天就接了个新项目,人家就问到美工由哪边负责,我们当然就说他们做好了css+html样本发给我们,而不是我们照着他们的css再往自己的js上贴.
另外,现实也确实要求css存在,恰巧今天就接了个新项目,人家就问到美工由哪边负责,我们当然就说他们做好了css+html样本发给我们,而不是我们照着他们的css再往自己的js上贴.
#10
css肯定会要的
javascript是根据需要动态改变css的内容
javascript是根据需要动态改变css的内容
#11
CSS和js完全不同的两个东西
#12
shangdaming 反复强调项目组分工问题。我感觉这的确是个着重点，不能忽视，毕竟目前流行的开发方式都需要美工参与前期编码，需要有一个适当切分点，让美工和后期编码衔接起来。
假如有一款软件，给美工提供某种所见即所得工作环境，只管页面布局、色彩、图片、字体等等，完全不接触代码，软件把美工设计自动转换成代码，是否可行？不是 DreamWeaver 那样的软件，DreamWeaver 要做的事太多，不适合美工用，生成的代码也不适合我们现在讨论的目标。这种软件应该集中完成比较窄的专业功能，就像那种音乐创作软件，创作者只管在 midi 键盘上敲敲打打，软件自动生成五线谱和 midi 文件。
假如有这样一款软件，是否可以解决上面说的项目分工问题，无需纠缠 CSS 还是 JS？
假如有一款软件，给美工提供某种所见即所得工作环境，只管页面布局、色彩、图片、字体等等，完全不接触代码，软件把美工设计自动转换成代码，是否可行？不是 DreamWeaver 那样的软件，DreamWeaver 要做的事太多，不适合美工用，生成的代码也不适合我们现在讨论的目标。这种软件应该集中完成比较窄的专业功能，就像那种音乐创作软件，创作者只管在 midi 键盘上敲敲打打，软件自动生成五线谱和 midi 文件。
假如有这样一款软件，是否可以解决上面说的项目分工问题，无需纠缠 CSS 还是 JS？
#13
UI方面..css比js更好理解和维护,比如:
你用JS如何实现??你是动态创建 style 标签(这还是用到css了)? 还是便历所有 #demo 下的p标签然后修改每一个p标签的css属性??
#demo p{color:red}
你用JS如何实现??你是动态创建 style 标签(这还是用到css了)? 还是便历所有 #demo 下的p标签然后修改每一个p标签的css属性??
#14
终于见到实例，谢谢 plzzz。不忙回答，希望看到更多例子。
#15
在这种问题上扣貌似没什么意义，怎么爽怎么写。
#16
你这观点只站在个人角度看问题，很难苟同。假如 CSS 真的不需要，为何还要那么多人去研究它，还要初学者花那么多时间来学？本来可以用一种语言编写的软件，我偏要用两种语言来写，就因为我觉得爽，然后还要让你来维护，你喜欢吗？
#17
定位完全不重叠。
#18
css和js是两种不同的概念，分工不同。
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
#19
css和js是两种不同的概念，分工不同。
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
上面的链接，是css做出的各种形状。
css注重页面的表现形式，而js更注重与用户的交互。
比如，css能够给div加上圆角，可以给文字加上阴影，可以是背景色有线性变换，这些不知道js能够实现么？（本人js水平菜鸟级）
http://css-tricks.com/examples/ShapesOfCSS/
上面的链接，是css做出的各种形状。
#20
当深入理解css，就会发现其实css功能也很强大，甚至有的css功能可以完全代替一些js的效果。比如3d旋转。
#21
学习了,之前一直用notpad++
#22
朱羽佳是 CSS 粉丝呀，欢迎加入讨论。
CSS 粉丝如云，这很自然。CSS 比 Javascript 差不多早了十年。CSS 正式版是 96 年发布，那时候 JS 刚有个雏形，其后发展也不顺利。有 Java 和微软的 script 当道，谁更有出息当时都不好说。也就是七、八年前，JS 才被人看好，但一直被当做一种小技巧玩。一直到 HTML5 流行了，大家才说：噢，JS 还有这么多功能啊。
Web 前端开发需要一种功能强大的编程语言，只靠 HTML 和 CSS，浏览器永远都是网络版电子书，不可能达到 native 程序那种境界。现在看来，这种语言非 JS 莫属。
JS 包含了 CSS 的全部样式描述功能。可以这么说，凡 CSS 能做的事，JS 都能做，反之则不成立。我们讨论的分歧点是：同一件事，用 CSS 做更合理还是用 JS 独自完成更合理。这里说的合理是指更易读易维护，更有效率。如果多数情况下用 CSS 更合理，那么它还有生命力，否则将随着 JS 的流行而退位，变成少数玩家的鉴赏品。
JS 的样式描述是以对象的 style 属性来实现，和 HTML 标签有点相似，不像 CSS，先定义 selector 和style，然后再以各种形式应用到代码中。因此很多人产生一种错觉，感觉 JS 操作 style 的方式要低一个档次。其实，JS 既然是一种程序设计语言，它就可以借助变量和函数灵活操纵数据，完全可以像 CSS 那样事先定义 style 然后再去应用，而且可以做得比 CSS 更好。如果你有兴趣，甚至可以借助 JS 设计出一套不同的 CSS 来（我们做过这种尝试，此处不谈细节）。
CSS 粉丝如云，这很自然。CSS 比 Javascript 差不多早了十年。CSS 正式版是 96 年发布，那时候 JS 刚有个雏形，其后发展也不顺利。有 Java 和微软的 script 当道，谁更有出息当时都不好说。也就是七、八年前，JS 才被人看好，但一直被当做一种小技巧玩。一直到 HTML5 流行了，大家才说：噢，JS 还有这么多功能啊。
Web 前端开发需要一种功能强大的编程语言，只靠 HTML 和 CSS，浏览器永远都是网络版电子书，不可能达到 native 程序那种境界。现在看来，这种语言非 JS 莫属。
JS 包含了 CSS 的全部样式描述功能。可以这么说，凡 CSS 能做的事，JS 都能做，反之则不成立。我们讨论的分歧点是：同一件事，用 CSS 做更合理还是用 JS 独自完成更合理。这里说的合理是指更易读易维护，更有效率。如果多数情况下用 CSS 更合理，那么它还有生命力，否则将随着 JS 的流行而退位，变成少数玩家的鉴赏品。
JS 的样式描述是以对象的 style 属性来实现，和 HTML 标签有点相似，不像 CSS，先定义 selector 和style，然后再以各种形式应用到代码中。因此很多人产生一种错觉，感觉 JS 操作 style 的方式要低一个档次。其实，JS 既然是一种程序设计语言，它就可以借助变量和函数灵活操纵数据，完全可以像 CSS 那样事先定义 style 然后再去应用，而且可以做得比 CSS 更好。如果你有兴趣，甚至可以借助 JS 设计出一套不同的 CSS 来（我们做过这种尝试，此处不谈细节）。
#23
继续上面的讨论。先思考一个问题：native 程序也需要修饰界面，甚至比网页要求更高，为何没有出现类似 CSS 这样的东西？
答案应该不难找到。native 程序从一开始就是靠编程语言来实现。从汇编语言到高级语言，从简单的 DOS 界面到图形用户界面，一切都靠编程语言动态实现。现代操作系统都在底层准备好了图形用户界面的基本元素，应用程序只要调用 API 功能就能实现复杂的交互界面。各种集成化编程环境又把这种调用包装成所见即所得操作，应用开发者甚至不用考虑界面编码问题，其强大功能和复杂程度远非 HTML + CSS 所能及。这种环境自然没有 CSS 类静态描述手段的生存余地。
由于面向对象设计方法的影响，native 程序员从初学时都要遵循一条原则：对象的描述和操作代码，无论是属性、事件还是方法，应当尽量包封在一起，做成一个零部件，通过规范的接口与外界连接。紧内聚，松耦合，这是 native 设计的座右铭。按照这种原则，一个对象的 style 描述应当和对象核心代码包封在一起。这并不意味不同对象的 style 描述会导致大量重复代码，因为不同对象可以通过函数调用共享代码。
那么，JS 是否可以实现类似 native 程序那样的设计方式？理论上应该可以实现，JS 也的确具备这种功能。只不过浏览器还没有为此做好准备，浏览器比起操作系统来还很原始。HTML5 对浏览器标准做了大量横向扩展，甚至把图形和多媒体都包括进来，但其纵向功能几乎停留在原始状态。JS 要完成这些横向功能，需要码农们自己去堆砌大量代码，导致加载和运行缓慢，影响用户体验。FaceBook 为此还栽了个跟头，差点真成了“非死不可”。
但这并不说明 Web 设计应该停留在 HTML + CSS 时代。要是那样的话，Web 应用取代 native 应用只能是幻想，HTML5 也没什么前途。FireFox OS 也许是个不错的尝试，还未实际体验过，不知他们细节处理得怎么样。但愿他们能冲破 Web 设计的惯性思维，搞出点新东西来。
答案应该不难找到。native 程序从一开始就是靠编程语言来实现。从汇编语言到高级语言，从简单的 DOS 界面到图形用户界面，一切都靠编程语言动态实现。现代操作系统都在底层准备好了图形用户界面的基本元素，应用程序只要调用 API 功能就能实现复杂的交互界面。各种集成化编程环境又把这种调用包装成所见即所得操作，应用开发者甚至不用考虑界面编码问题，其强大功能和复杂程度远非 HTML + CSS 所能及。这种环境自然没有 CSS 类静态描述手段的生存余地。
由于面向对象设计方法的影响，native 程序员从初学时都要遵循一条原则：对象的描述和操作代码，无论是属性、事件还是方法，应当尽量包封在一起，做成一个零部件，通过规范的接口与外界连接。紧内聚，松耦合，这是 native 设计的座右铭。按照这种原则，一个对象的 style 描述应当和对象核心代码包封在一起。这并不意味不同对象的 style 描述会导致大量重复代码，因为不同对象可以通过函数调用共享代码。
那么，JS 是否可以实现类似 native 程序那样的设计方式？理论上应该可以实现，JS 也的确具备这种功能。只不过浏览器还没有为此做好准备，浏览器比起操作系统来还很原始。HTML5 对浏览器标准做了大量横向扩展，甚至把图形和多媒体都包括进来，但其纵向功能几乎停留在原始状态。JS 要完成这些横向功能，需要码农们自己去堆砌大量代码，导致加载和运行缓慢，影响用户体验。FaceBook 为此还栽了个跟头，差点真成了“非死不可”。
但这并不说明 Web 设计应该停留在 HTML + CSS 时代。要是那样的话，Web 应用取代 native 应用只能是幻想，HTML5 也没什么前途。FireFox OS 也许是个不错的尝试，还未实际体验过，不知他们细节处理得怎么样。但愿他们能冲破 Web 设计的惯性思维，搞出点新东西来。
#24
各有所需吧。。。
#25
举一个常见场景
有一个 div 在不同状态下有不同的表现
你是 每种状态给一个 样式
还是 每种状态 在代码中设置一堆 属性呢？
另外 编程 最终 就是 围绕配置 编程
大堆的 数据一般 都是写在配置文件中的
样式表 你恰恰可以看成一个 配置文件
你说的 style 全是 动态生成 那么我觉得 要么你的代码的可配制性不够 要么你的代码 只涉及了很简单的css
有一个 div 在不同状态下有不同的表现
你是 每种状态给一个 样式
还是 每种状态 在代码中设置一堆 属性呢？
另外 编程 最终 就是 围绕配置 编程
大堆的 数据一般 都是写在配置文件中的
样式表 你恰恰可以看成一个 配置文件
你说的 style 全是 动态生成 那么我觉得 要么你的代码的可配制性不够 要么你的代码 只涉及了很简单的css
#26
目前来说，css还没有退位的迹象，
只能是css有其所不足，而js有其无所不能！
最近本人做的一个小站，就是因为css力不从心，最终还是借助js在几位大佬的帮助下，实现了最终的功能。
只能是css有其所不足，而js有其无所不能！
最近本人做的一个小站，就是因为css力不从心，最终还是借助js在几位大佬的帮助下，实现了最终的功能。
#27
emituofo 说得真含蓄：只能是css有其所不足，而js有其无所不能！虽有点绕嘴，意思不错。
上面 plzzz 举了这样一个 CSS 例子：#demo p{color:red}。不妨借此例诠释一下 emituofo 的说法。
此处，demo 是标签的 id，p 是 tagName。假如我们有一个setObjStyle 函数，专门用来为 object 设置 style，函数大致如此：
function setObjStyle(obj){
if (!obj) return;
if (obj.id == 'demo' && obj.tagName == 'P'){
obj.style.color = 'red';
// 以下是其他设置
}
// 以下是其他条件
}
这只是函数的一部分。既然要为所有 object 设置 style，它当然还要包含其他内容。需要说明的是，实际函数也许不会这样写，这里只是为了说明 plzzz 的例子。从设计模式角度来说，此函数是整个程序的样式处理中心，而 demo 只是个案，其样式设置应该放在 demo 自身的处理过程中（在其中调用 setObjStyl 函数），这样才易读易维护。从此例已经可以看出 JS 的灵活性和强大功能。
那么，在 demo 处理过程中为 p 标签设置样式，是否如 plzzz 所担心，需要遍历 p 呢？按我们的处理方式是不需要的。我们的应用框架中，除了 head 和 body 这样的基础标签，差不多所有 DOM 结点都是动态生成，其 style 在生成时就可以设定，无需另外再遍历。
上面 plzzz 举了这样一个 CSS 例子：#demo p{color:red}。不妨借此例诠释一下 emituofo 的说法。
此处，demo 是标签的 id，p 是 tagName。假如我们有一个setObjStyle 函数，专门用来为 object 设置 style，函数大致如此：
function setObjStyle(obj){
if (!obj) return;
if (obj.id == 'demo' && obj.tagName == 'P'){
obj.style.color = 'red';
// 以下是其他设置
}
// 以下是其他条件
}
这只是函数的一部分。既然要为所有 object 设置 style，它当然还要包含其他内容。需要说明的是，实际函数也许不会这样写，这里只是为了说明 plzzz 的例子。从设计模式角度来说，此函数是整个程序的样式处理中心，而 demo 只是个案，其样式设置应该放在 demo 自身的处理过程中（在其中调用 setObjStyl 函数），这样才易读易维护。从此例已经可以看出 JS 的灵活性和强大功能。
那么，在 demo 处理过程中为 p 标签设置样式，是否如 plzzz 所担心，需要遍历 p 呢？按我们的处理方式是不需要的。我们的应用框架中，除了 head 和 body 这样的基础标签，差不多所有 DOM 结点都是动态生成，其 style 在生成时就可以设定，无需另外再遍历。
#28
继续讨论，谈谈 JS 的配置功能。KK3K2005 的说法触及到我们讨论的焦点：JS 有没有 CSS 那样的配置功能？这里说的配置应该不是纯函数形式，我们不能一改变配置就去修改函数。应该有一种文本形式来描述整个应用的初始样式设置，只要修改文本就能修改配置。这正是创建 CSS 的初衷。
如果熟悉 native 软件设计，应该不必怀疑 JS 此项功能。所有 native 编程环境都可以创建灵活多样的初始化配置，JS 作为一种编程语言也是这样。我们可以用 json 形式为它写配置，也可以模仿 CSS 格式来写，顺便把 CSS 中带 '-' 的标记改成 HTML 和 JS 的统一格式（鬼知道为何要弄出两套东西来），或者采用另外一种更简洁高效的格式。这都没关系，JS 想做什么都不难。我们还可以实现客户化配置：给用户一个专门界面来设定自己的配置。如果不惧 HTML5，不妨用 localStorage 来保存用户配置。
其实，像 CSS 那样用文本来写配置并不合理。最好的做法就是有个专门的配置程序，来个所见即所得，就像上面我曾经提到过的。这样，美工就不必再去研究编码问题，可以专心于自己的美术设计。这种功能当然离不开 JS。
需要特别强调的是，我们不能滥用配置。配置应该是面向全局的，需要尽量缩小应用范围。把什么都往配置里塞，会让程序的处理代码和属性描述分离，这不符合面向对象的设计概念，会增加维护的难度。有些人玩 CSS 玩得兴起，就不考虑这一点了。
如果熟悉 native 软件设计，应该不必怀疑 JS 此项功能。所有 native 编程环境都可以创建灵活多样的初始化配置，JS 作为一种编程语言也是这样。我们可以用 json 形式为它写配置，也可以模仿 CSS 格式来写，顺便把 CSS 中带 '-' 的标记改成 HTML 和 JS 的统一格式（鬼知道为何要弄出两套东西来），或者采用另外一种更简洁高效的格式。这都没关系，JS 想做什么都不难。我们还可以实现客户化配置：给用户一个专门界面来设定自己的配置。如果不惧 HTML5，不妨用 localStorage 来保存用户配置。
其实，像 CSS 那样用文本来写配置并不合理。最好的做法就是有个专门的配置程序，来个所见即所得，就像上面我曾经提到过的。这样，美工就不必再去研究编码问题，可以专心于自己的美术设计。这种功能当然离不开 JS。
需要特别强调的是，我们不能滥用配置。配置应该是面向全局的，需要尽量缩小应用范围。把什么都往配置里塞，会让程序的处理代码和属性描述分离，这不符合面向对象的设计概念，会增加维护的难度。有些人玩 CSS 玩得兴起，就不考虑这一点了。
#29
接楼上的 不懂编程 或者 编程水平一般的人 是写不出 结构合理的配置的
而对于 html概念不深的程序员 也写不出 好的 css
所以 前端是一个有难度的工作 需要对于 页面和逻辑都精通的人才 能进行view层次框架性质的开发
mvc么 很多程序员其实都只在c层写代码
而对于 html概念不深的程序员 也写不出 好的 css
所以 前端是一个有难度的工作 需要对于 页面和逻辑都精通的人才 能进行view层次框架性质的开发
mvc么 很多程序员其实都只在c层写代码
#30
一般情况下，能用CSS就可以设置好的，就不要用js来做。主要原因就是效率问题。一般情况下，美工是专门做CSS，会js的话要求太高了。
#31
这应该是个人风格问题..
比如隐藏一个元素,很多人都是setStyle('display':'none')这样设置,而YUI3推荐的方法是 addClass('xxx-hidden'),然后另外再写一个CSS如: .xxx-hidden{display:none}
这样检测元素是否可见 用 hasClass('xxx-hidden') ,而 getStyle('display')这个计算感觉比 hasClass 要复杂.
比如隐藏一个元素,很多人都是setStyle('display':'none')这样设置,而YUI3推荐的方法是 addClass('xxx-hidden'),然后另外再写一个CSS如: .xxx-hidden{display:none}
这样检测元素是否可见 用 hasClass('xxx-hidden') ,而 getStyle('display')这个计算感觉比 hasClass 要复杂.
#32
存在即合理，如果只是想自己实现某些功能，那么用JS完全可以，如果商业项目中，假如是传统页面，那么肯定是CSS，JS分开，如果是web app，那么HTML中则不需要什么东西，处于性能考虑，肯定是能独立出CSS文件的，全部都独立出CSS文件。
#33
js控制样式不还是借助css 还是说你们只是在讨论是否有必要写.css文件?
#34
css很有用,特别是开发组件的时候,它可以让你的组件逻辑与样式分离,这意味着可以把样式留给专业的美工来做,js程序员可以把时间放在组件逻辑上,提高开发效率.
并且样式与逻辑分离,这也意味着组件更灵活,使用者可以通过重写一个css在全局改变组件的默认样式
并且样式与逻辑分离,这也意味着组件更灵活,使用者可以通过重写一个css在全局改变组件的默认样式
#35
不说别的了，楼主看看Google，微软等大牛云集的网站，看看有没有css
#36
wbb123yu，JS 的 style 是否属于 CSS，我觉得这无关紧要，谈论这个没有意义。
也不仅仅是 CSS 文件的问题。CSS 也可以没有独立文件呀。分歧点在于：如果 JS 能完成，是否还需要定义独立的 CSS 结构，程序员是否还有必要去研讨 CSS 语法和用法，那毕竟也是一套独特的知识体系。撇开 CSS 和 JS 用两套标识符不说，要熟练掌握 selector 的定义方式也不易。还有其他分歧，先不提了。
用 JS 的好像有两类人。一类是从 HTML, CSS 走过来的，另一类是从 native 程序设计转来的（我属于这种）。感觉这两帮人就像两个部落，中间隔着一堵墙。
也不仅仅是 CSS 文件的问题。CSS 也可以没有独立文件呀。分歧点在于：如果 JS 能完成，是否还需要定义独立的 CSS 结构，程序员是否还有必要去研讨 CSS 语法和用法，那毕竟也是一套独特的知识体系。撇开 CSS 和 JS 用两套标识符不说，要熟练掌握 selector 的定义方式也不易。还有其他分歧，先不提了。
用 JS 的好像有两类人。一类是从 HTML, CSS 走过来的，另一类是从 native 程序设计转来的（我属于这种）。感觉这两帮人就像两个部落，中间隔着一堵墙。
#37
这个问题我在前面已谈过不少，你大概没看吧？
#38
说这个没意义。科技不是靠人多势众，也不是靠权威和名气。当年微软对移动计算看不上眼，英特尔也是不摆 ARM，这才过了几年，现在怎么样？有道理就讲道理，千万别甩出权威来以势压人，IT 界不兴这个。
#39
我个人觉得有集中原因 css文件便于管理 和css效率比js的高 js可以做css的工作但是他没有css原生做得好； 不是一个语言能做另一个语言的事就能代替它的 你要比他方便，效率高，便于管理，功能强大等等。。 这样才会被替代
#40
我们的目的都是一样的，就是将页面完美的呈现出来，只是所用的方式不同。
像我这种对于JS不怎么熟练的开发人员来说，更偏向于用CSS来表现页面。毕竟先接触CSS，后接触JS。
而且现在的页面都是等到HTML加载完了，再去加载JS，这个过程就会让用户先看到很呆板的纯文字的页面，如果最后加载的JS有一点小错误的话，可能会导致JS写的那些CSS效果加载不出来，影响用户查看页面。
而CSS不同，CSS优先加载，而后在加载HTML结构，这样就不会影响用户查看页面。
另外，CSS相对于JS，修改起来也方便（个人觉得）。大小也要比JS小吧。
像我这种对于JS不怎么熟练的开发人员来说，更偏向于用CSS来表现页面。毕竟先接触CSS，后接触JS。
而且现在的页面都是等到HTML加载完了，再去加载JS，这个过程就会让用户先看到很呆板的纯文字的页面，如果最后加载的JS有一点小错误的话，可能会导致JS写的那些CSS效果加载不出来，影响用户查看页面。
而CSS不同，CSS优先加载，而后在加载HTML结构，这样就不会影响用户查看页面。
另外，CSS相对于JS，修改起来也方便（个人觉得）。大小也要比JS小吧。
#41
我们也做过HTML结构都是由JS生成的项目（所有的HTML都是由JS生成，动态添加），但是都是在我做好的HTML+CSS基础上完成的。
LZ说了，所有样式定义都是JS动态生成。我想这应该也是在做好的页面（HTML+CSS）上完成的吧，不然怎么知道哪里该用什么样的样式呢？
#42
全用js页面风格如何复用统一，如何修改维护，全都改一遍吗
#43
谢谢理性回帖。
你好像不熟悉 JS 编程，所以有此担心。CSS 是样式描述语言，JS 是程序设计语言，二者不是一个等级。前者不能代替后者，后者却能完成前者的功能。我在前面已详尽说明，还包括 plzzz 举的例子，烦请再去读一下。
#44
...真不知道LZ再说什么 你说JS代替CSS 怎么代替 JS本身又没有改变元素样式的功能 他的改变样式也是改的CSS 没CSS 你怎么变
再说了 CSS和JS效率根本不能比
再比如 js改变dom结构 那么难道每次都要用js在刷一下样式么 不然根本就是默认样式 css文件的样式是即时渲染的 但是js改变dom结构后的 比如加个样式已有的div一样的div 那这个div的样式还必须用js全部重新写 用css则不必 真不懂怎么会出现这种说法
再说了 CSS和JS效率根本不能比
再比如 js改变dom结构 那么难道每次都要用js在刷一下样式么 不然根本就是默认样式 css文件的样式是即时渲染的 但是js改变dom结构后的 比如加个样式已有的div一样的div 那这个div的样式还必须用js全部重新写 用css则不必 真不懂怎么会出现这种说法
#45
终于见到同类了，呵呵。我们的编程方式完全不同，HTML 只有 head 和 body 两个简单标签，body 里面只有 script，一上来就运行 JS StartUp 函数，很像早年 C 语言里那个 main 函数。能理解兄台的担心：看不到东西怎么调试呢？我们是采用构件方式来解决。大致描述下，希望能说明问题。
像 Delphi, C++, VB, Java, Flex 这类都可以用构件来生成界面，不用运行就能看到界面效果，那需要有 IDE 集成环境的支持。DreamWeaver 也提供了类似集成环境，但功能太弱，缺少对 JS 的支持。但这不等于说 JS 不能用构件编程。其实，native 程序的构件也不是非要所见即所得。构件最终还是一堆 OOP 代码，只要构件成熟，直接去调用构件对象，效果是一样的，不同的只是运行起来才能看到效果。
JS 也算是一种准 OOP 语言吧，只是不如 native 编程语言好用。我们是以 div, table 这类 DOM 成员建造基础 JS 对象，用 construtor 设置默认样式。每个对象有个可变参数 style，其内容可想而知，就是用来改变默认样式。所以，像前面几位说的，能不能整体修改维护，那都不是问题。
只有基本 JS 构件还不行，我们以此为基础建造了 Layout 构件，用来形成页面布局。Layout 对象可以借助参数形成多种多样的布局，同时也借助 style 参数形成不同样式。有了这些，只需几行 JS 代码就能完成一个 Web 页面，包括下拉菜单、标签页、图片集、分栏文本等等，样式也可以丰富多彩。由于构件都是事先调试好的，做二次开发时不用担心弄错哪里显示不出来。JS 就这毛病，要是不熟练，一点问题就能搞得天昏地暗，到最后发现就错了一个字符，所以更需要一种合理的团队组织方式。
我们研究过流行的 Web 设计框架，吸取了它们的长处，同时也尽量回避其缺点。设计这种东西不容易。正像兄台及前面几位所说，既要考虑编程效率，也要考虑加载速度和运行速度。我们还只是一种尝试，需要做的还很多。好在我们的代码足够精炼，目前没有太大问题。如果 JS 构件库变得很大，就得选择动态加载：需要什么加载什么，不需要的留在服务器端。
#46
楼上很多认为牵涉到样式就是css 不过想一想css是"层叠样式表"就会明白样式是在css之前的.用js控制样式的话,跟css是没有任何关系的.
#47
CSS是用来排版用的，js是用来互动用的，不能混淆
#48
native vs web，
复杂运用 vs 简单页面
复杂类库+层层封装 vs 切面处理，html管内容，css管样式，js管特效
web向native学习，以AJAX为工具模仿运用，超大的类库还是个硬伤，10秒内看不到内容，手机用户下载xxxK的库都会严重影响用户体验。
所以看运用环境吧，某些特定环境下纯js是成立的，但大部分的轻量级运用，css文件还是比纯js来得简洁。
复杂运用 vs 简单页面
复杂类库+层层封装 vs 切面处理，html管内容，css管样式，js管特效
web向native学习，以AJAX为工具模仿运用，超大的类库还是个硬伤，10秒内看不到内容，手机用户下载xxxK的库都会严重影响用户体验。
所以看运用环境吧，某些特定环境下纯js是成立的，但大部分的轻量级运用，css文件还是比纯js来得简洁。
#49
ftiger 说得很在行，句句到位，除了最后那句。
轻量级应用，JS 和传统 Web 速度差别不大。个人感觉 JS 更简洁，因为 JS 可以把复杂结构变成简单的函数调用。其复杂性在于构筑底层 API。一旦 API 成形，二次开发比传统 Web 简单。
复杂应用，传统 Web 做不到，JS 能实现，但有点笨重。所以目前 JS 还不能取代 native 程序。围绕 Facebook 那场争执，一方说：HTML5 还没准备好；另一方说：不是 HTML5 不行，是你不会用。看不到细节，所以不好断定。
往后就不好说了。相信 JS 引擎还能提速，但要有关键技术改进。硬件也会提速，期待 10 纳米技术。每次硬件提速都会引起软件改革。要是用20年前的硬件，Windows 95 也跑不动。
大趋势是传统 Web 技术被淘汰，但还需要时间。
轻量级应用，JS 和传统 Web 速度差别不大。个人感觉 JS 更简洁，因为 JS 可以把复杂结构变成简单的函数调用。其复杂性在于构筑底层 API。一旦 API 成形，二次开发比传统 Web 简单。
复杂应用，传统 Web 做不到，JS 能实现，但有点笨重。所以目前 JS 还不能取代 native 程序。围绕 Facebook 那场争执，一方说：HTML5 还没准备好；另一方说：不是 HTML5 不行，是你不会用。看不到细节，所以不好断定。
往后就不好说了。相信 JS 引擎还能提速，但要有关键技术改进。硬件也会提速，期待 10 纳米技术。每次硬件提速都会引起软件改革。要是用20年前的硬件，Windows 95 也跑不动。
大趋势是传统 Web 技术被淘汰，但还需要时间。
#50
程序是现实世界的抽象，模式是程序的抽象。
从要表现的内容来看，个人认为web程序抽象有两个方向的不同侧重，面向业务或面向内容/娱乐。
面向业务，表现为一大堆相似的view，大量的表格表单，复杂的菜单，复杂而多变的业务逻辑。在这个方向上，个人认为复杂类库+层层封装，使用MVVP模式也就是将view先抽象出来，然后可以集中精力去处理业务逻辑，在这样的运用环境下，放弃css文件是可行的。
面向内容/娱乐，比如blog，bbs，信息发布平台,相对简单的逻辑，大量成熟的程序，很多新手下载个源码就可以搭建起来，这时候个性化改版成为常规要求，这时只学习html+css的网页美工切工能力占优，程序员反而大部分美感缺缺，css相对简单的结构，可以在可视化环境下修改界面的优势比用js实现占优。
css和js已经并行发展了这么多年，谁也没能说能代替谁。
从要表现的内容来看，个人认为web程序抽象有两个方向的不同侧重，面向业务或面向内容/娱乐。
面向业务，表现为一大堆相似的view，大量的表格表单，复杂的菜单，复杂而多变的业务逻辑。在这个方向上，个人认为复杂类库+层层封装，使用MVVP模式也就是将view先抽象出来，然后可以集中精力去处理业务逻辑，在这样的运用环境下，放弃css文件是可行的。
面向内容/娱乐，比如blog，bbs，信息发布平台,相对简单的逻辑，大量成熟的程序，很多新手下载个源码就可以搭建起来，这时候个性化改版成为常规要求，这时只学习html+css的网页美工切工能力占优，程序员反而大部分美感缺缺，css相对简单的结构，可以在可视化环境下修改界面的优势比用js实现占优。
css和js已经并行发展了这么多年，谁也没能说能代替谁。