假如我确实喜欢HTML、CSS和JavaScript又将如何？

to hax：
你还是在追求完美啊。当然我一直很尊敬追求完美的同志，否则这个世界就不会改变了。不过我感觉你的观点其实跟DHH的观点并不冲突，但是DHH并不是一个追求完美者。你说的那个TV的需求其实我们90%以上的情况下都不会遇到，到是将来可能会经常遇到需要支持智能手机的浏览器。DHH和我也不是要完全否定table布局，这是某些别有用心的人的故意窄化。

你们都很讨厌Dojo的Widget，不过Dojo的事件模型我认为是其中较为出彩的部分。这个基于AOP的事件模型非常强大和灵活，当然付出的代价就是要使用Dojo特定的API。我不知道你们怎么看待Dojo的这个事件模型？

Sure。昨天晚上我拿DHH原文看了一遍，我觉得他只是不满于Adobe/Microsoft摆出一副解救众生于Web水火中的姿态，而许多人高声应和。

另外，看看comments，也有许多人反对他的意见的——其中甚至包括一个Adobe的Flex Marketing Team的……多数人的论调是：工具么，各有擅场。老实说，这种实用主义论调还真是不可爱，难怪好多人（包括dlee）要对老是引用南方公园中的愤青Cartman的粗口的DHH崇拜有加。

从技术美感的角度说，我不能隐藏我是如此喜爱xhtml/css/javascript，我的英文简历上甚至有一句也许狗屁不通的话：Have my own vision of the future of RWC, Ajax, web development framework and patterns. Comprehending the rationale of the essential technologies such as CSS has even been part of my thinking style.

但是回到现实中，现有的标准，现有的实现，确实有太多不足了。也难怪人家鼓吹新的银弹么。

Dlee这个标题翻译得...太晦涩了，还不如东北话：
“俺就是喜欢HTML、CSS和Javascript，怎地？”

Web标准的设计者的确在为开发着谋福利。但是目前开发者并不能直接享受这些福利，而是需要去忍受厂商提供的实现差异。

开发者一定要尽最大的努力去实践标准，因为这是解放自己的唯一出路。

当前，很多为了兼容考虑的项目中，大量的work-around的确让人心烦，而css mastery这样的书都比较实干的面对这样的问题，这种态度很好（Friends of ED的书似乎都有这种风格）。我在我们的团队开会中面对标准化这个问题的时候一直保持这样的态度：要努力学习和充分的领会标准，令一方面要充分的尊重dirty work，因为不是所有的产品都只限制在现在浏览器中使用。

Dlee推荐的基本书里面：《Web开发敏捷之道--应用Rails进行敏捷Web开发》第2版，《Ajax模式与最佳实践》，《Ajax实战》我觉得最有特点。

因为它们不仅介绍技术本身，更多的去分析技术后面的想法，让你潜移默化的得到升华。

不采用ajax库不就彻底无浸入了 server端处理dom节点的速度并不慢负担很轻

server端可以提供post和rest风格的接口 前台需要分析的问题是如何交互和布局 
提交什么 想获得什么

ror虽然能比java快一个量级 但毕竟是语言级的快速开发 和直接面向信息处理的开发方式没有可比性

被你看穿了。。。我是追求完美的处女座。。。

关于TV那个，恰好是我先前的工作涉及到的（俺先前在搞跟盛大盒子战略有关的工作）。但是也不能说仅仅是TV应用。凡给定界面的都或多或少倾向于grid布局，仅仅是复杂程度的问题。例如仿桌面的界面（蛮流行的）。因为桌面应用中，几乎大都使用各种类型的grid布局。我以前一直鼓吹在web上就应该使用flow布局而不应使用grid布局。但是随着对交互设计的认识加深，我意识到应该从用户体验出发。从技术上说，flow布局的主要好处是灵活适应不同的viewport，但是真正把一个1280*1024的界面转换到640*480或者更小的viewport里，不是那样简单的。他们的应用场景很可能有很大不同。理想上，我未来能使用css media query，来为不同的分辨率（应用场景）来设计，对布局乃至流程做完全不同的调整。但是理想不等于现实。无法实现或太晚实现……都可能导致我们不愿看到的情况。

另外一方面，我恰恰是想要完全否定table布局的，正是基于此，我认为出现这样讽刺的情况，即遵循标准的人活得比不遵循的人更累，是很有问题的。这种矛盾在我身上存在着，2001年的时候我在某bbs上发了个贴，大数table布局之罪，但是过了几天我又跑上去说table布局在某种情况下也可以用用。dlee同志貌似到现在也跟我当时一样。如果你确实认为，table布局从实用主义角度无法被完全否定，那DHH同志采用实用主义的角度来力挺html/css/js就也有点心虚，那个标题也就显得带点任性味道。。。

to hax：
那本翻译的很烂的《网站重构》里面提出了一种从传统的table布局向完全的CSS布局的过渡策略，是我目前看到过的较为理想的方式。

在我前面的一个应用中，当然不是完全不使用table。不过我一般只使用table来容纳表格型的数据，而table本身与表现有关的部分全部使用CSS来设置。这是W3C设计table的原意。

我在积累了一些CSS布局的经验，又对Web浏览器的盒模型和IE6的bug有了深入理解之后，页面的制作效率就比以前高了很多。而且，最大的优点是维护起来非常方便，整个应用界面的一致性也很容易保证。

我只在一个地方被迫使用table布局，就是Dojo的下拉式日历Widget只有当使用table的时候，才能在同一行放两个Widget。这又是一个你们可以诅咒Dojo Widget的场合，呵呵。

对于更加复杂的界面需求，是否CSS能够胜任，我还无法确定。
另外其他页面制作人员更轻松是因为他们可以使用WYSIWYG的编辑工具，但是这种轻松和开发效率当需要大规模改版的时候就不复存在了。基于CSS制作的页面改版要容易很多，而且很容易实现换肤等效果。一个有复杂交互的Ajax应用，对于页面质量的要求要高的多，WYSIWYG工具制作出的页面往往无法满足要求。

有人说，你们追求这些都是吃饱了撑的，我天天使用table布局，天天将SQL代码写入JSP文件，也没见到天塌下来。但是，你有没有注意到你们的网站性能和可伸缩性都很差？种瓜得瓜，种豆得豆，你什么都不种，根本不愿意花时间深刻理解XHTML/CSS/DOM/JavaScript、HTTP、REST，那么最后你无法得到满意的效果不是很正常吗？

我们是说我和jindw？我先代表偶本人表达一下，偶并不是对于dojo有特别偏见（认为dojo的代码质量不够好另算），其实对于所有的js widget之类的方案我都有保留，这恰恰是因为偶的“正统标准”观。我更喜欢xforms，喜欢用css来customise那些xforms controls。

其实dojo的widget我也不是完全不喜欢，我只是不喜欢在widget标签混入样式，这难道不是违背了html/css/js的原则？

关于事件模型，我其实对于某种特定API并不感冒，反正你总是需要一种API。我认为dojo的event.connect是很精巧，但有走火入魔之嫌。这表现在两个方面：

1. 混合了对象级别的event和组件级别的event。

DOM事件体系是后者。我并不是说一定要既有bubble又有capture，因为姑且认为那是政治结果（最初netscape是capture，ie是bubble），但是显然后者涉及到一个事件在层级中传播的问题。这样一种事件体系本质上比对象事件要复杂。使用相同的API，并不能减少这种复杂性。我也在思考统一DOM事件体系和语言级别事件体系的可能性，但是一定不是简单的统一到一个API上。

2. 关于AOP，我的朋友aimingoo在他的qomo中实现了一个较dojo更纯正的AOP框架，我所谓更纯正，是指它看上去和用起来更像AspectJ，且可以切函数也可切类也可切对象。但是无论哪一个，都不能改变一个事实，这样的AOP实现其实底下是悄悄的替换了函数。俺不是说这样不行，或者一定会产生什么副作用（确实可能有），但是我存在一个疑问，js本来就可以是函数式的，为什么还一定要引入AOP的概念，从而被迫偷偷摸摸？换一种说法，我更喜欢光明正大的，一目了然的做法。比方说：
var x={doSth:function(){...}}; dojo.event.connect(x, 'doSth', f)，此时x.doSth就被偷偷包了一层，已非我原装的了。（若我对dojo实现的理解不正确，请指正）
我宁可var x={doSth:Method(...)}; x.doSth.before.add(f);
或者对于不在你控制范围内的x，可以这样：
x.doSth = Method(x.doSth); ...
甚至可以有快捷函数对整个x上的函数进行包装：FunctionsToMethods(x);

当然上述只是我的一点想法，并不能代表其他人哦。

网站重构是翻译的蛮烂的。可恶的是其在网上公布的前面若干章翻译的还好，待我买来一看，后面翻译的实在有好多低级错误。不过这本书的引入对于国内开发者来说确实还是有里程碑意义的。

再说table吧，从实用主义角度说，谨慎的table布局也许更简单，因为它更好的映射到了grid模型上。如果你转用div/span，标签是清晰了，但是css是混乱的！！为什么？因为你无论绝对定位也好，float也罢，这些属性是分散的，css代码无法反映整体，无法记录你的grid布局意图！这是为什么我们经常说我有一个css trick的原因，它是trick而已，是你达到最终目的的手段，但是你的目的，你的意图，没有好好加入文档的话，那维护起来恐怕也不见得轻松：
table布局+其他css样式 = 清晰的布局意图和内容的混合体
vs
div容器+css样式 = 内容样式分离，但是从css代码中很难看出布局意图

关于div/css布局还有一些误区，简单的把table标签换成div是没有意义的（若干层级的div可能比table更糟糕）。实际上我们希望的是语义标签。所以我们希望避免无意义或仅仅为layout或presentational的div标签，但是有时候居然是css hack的代价（比方说在某些css圆角实现中）！

也许归根到底是怪css还不够好，怪browser的实现还不够好。比方说你要在一行上放两个东西，实际上可能需要的是css column支持。。。但是还是那样，开发者的耐心是有限的，勾画的美好蓝图从来不如微软的甜蜜诱惑。特别是他们许诺通过更智能（更邪恶的宝葫芦的秘密？）的ide，也能提供你所说的web标准网站的可维护性的时候。对于他们来说，html+css+js，或者是flash，只是开发者看不见的presentation层而已（据csdn新闻上元红岗同志的说法是不依赖於表现层的表现层），它帮你抹平了，你不用担心。按照这种逻辑，现在的WYSIWYG工具只是不够智能而已而已。。。

要知道，DHH或者dlee的论战对手，可不是那些“天天使用table布局，天天将SQL代码写入JSP文件，也没见到天塌下来”的人，真正的对手是主导的商业公司，他们理解商业运作、市场规律、普罗大众的需求，作为w3c的会员，他们甚至知道现有标准的弱点。

我力挺web标准是因为我认为web标准很优美且开放。这种美感落实到实际中就是不同的部分（html,css等）很好的匹配每个部分的concern，将不同角色的意图忠实表达出来，并完美结合成最终的web。但是现实中残缺的browser严重破坏了美感。所以我越是深刻认识html/css/dom/js，越感觉沮丧。

所以你知道问题在哪里，我和DHH一样，I actually like HTML, CSS, and JavaScript，但是我认为现在不是够好，而是远远不够。面对微软、Adobe，甚至红岗同志，俺都感觉底气不是那么足。

这个讨论很有价值

我也觉得div标签有问题。

如果可以直接将xml数据节点渲染成view是最理想的 因为xml数据节点本身是富含信息的（比如用xml表达的微格式 一个商品信息节点）
<产品 点击="view()" 拖拽＝“buy()”>>
<价格/>
<折扣/>
<说明/>
</产品>
当用户点击这个节点 我可以直接将整个节点发到server端 如果用div分割后就麻烦了 节点内容乱了

css是否可以直接对xml进行渲染  我知道xslt+xsl是可以的 但浏览器未必支持xsl2.0