你们平时是怎么写html和css的？

[浮-沉]

拿到一个效果图，应该按照怎样的方式去写html和css才能更效率呢？
我从开始学到现在，一直都是拿着效果图就按照从上到下，从左到右，纯粹按照效果图去实现，有些时候出现了什么不正常，偏移的问题就硬性去解决，比如 !important这种方法，相当于就是先考虑实现上面的效果，然后等把整个页面弄完后，再去修改html和css，看哪些地方能优化的，最近发现网页大了以后，感觉按照这种从上到下，从左到右的方法写好累，经常写到一半就写不下去了
你们都是怎么写的？有什么好点的方法吗？

[world_broken]

不管3721，reset.css是要弄一个。接下来写好整个页面布局，从外到内分块，无非是上中下、左中右。3、内容填充，分类，写点class 。最后，调整特殊的内容CSS。

[豪情]

一不小心写的太多，
我先说一下，熟练后拿到效果图时这样的一个状态：

http://imcn.me/html/y2012/9871.html/comment-page-1
拿到效果图时，有这么几步，就我了解的情况做一下分享，不一定全部都是科学，但可以部分借鉴。
1. 拿到效果图先是分析：
分析什么，分析上下游的相关情况。先说上游设计和产品，如果设计有相关的文档，则仔细通读文档，就文档中相关业务流程，页面跳转，交互行为，设计细节相关清楚不清楚的问题找设计产品了解确认清楚，如果必要需要邮件确认，免得其后扯皮说，当时没说清楚，当时说的不是这，怎么怎么的。如果可能还需要开会，让相关把关人与会参与，比如项目经理，技术总监。
业务流程就是直观的就是需求设计里边的流程图，比如注册，电话->成功->失败等等，但这不是最终的页面，只是流程，然后就要跟流程对页面，哪个页面对应流程中的那个节点，页面的跳转，跳转的可能，依赖次序，以及重复页面的梳理等等。
然后在分析下游后台，页面的数据是否可以顺利的实现，后台接口数据提供的日期，大概约定等等。是否有前台业务逻辑判断的可能，是否前台需要更复杂简单的处理。是否在评审中有遗漏的细节，需要重新评估，或者直接否决，等等。
分析这些的目的就是：这些页面交给下游后台时会出现的一些问题，防止页面交出去以后，有些链接的去向不明，数据不正确，以及少页面，漏模块等等情况的发生。
2. 写页面之前的需要了解的2种方式：
当然切的时候有2种方式，一部分前端可能是第1种方式，就是把psd转换成html页面，交给后端，进行数据的完善。其实这种方式有几个问题：
a. 页面的结构划分没有决定权，比如，有些页面在后端来说，可以通过后台技术来进行一定的拆分组合。但是纯html页面不能实现这个功能，要是不能合理的拆分，有些资源的调用，或后期页面的修改有很大的麻烦。
b. 页面的数据的结构状态，因为设计交与的页面状态是一个理想的状态，但是页面至少有三种状态，比如，数据最少的情况，数据最多的情况，以及数据刚好的状态，而设计给你的是数据刚好的状态，其它的如果项目紧设计人员少，那就需要自己脑补，如果有真正的效果图出来，那还好有参考的依据。否则，后期在测试部门回溯的时候也是比较麻烦。
c. 任务完成的不连续性，因为有些ajax的交互发生，需要重新的渲染页面，这样结构或样式可能会发生改变，如果是纯html页面，那只有等后端完成数据状态之后，在去完成相关ajax的相关模块，或者是等后端自己完成ajax，然后出现问题在找你，等等的情况，都加大了合作之间出现bug的风险或可能。
鉴于以上情况，我个人建议利用后端语言的优势来写静态的数据结构或者直接输出动态的最终view层页面。这样在前端层的页面控制权完全交与前端来负责，但是这样得具备一个条件：
对前端的技术储备有大大的要求，必须了解一门后端语言为基础，了解ajax的整个交互过程或一些常见问题的处理。
当然，说起来很玄乎，其实这些东西都不难。比如流行的web后端语言php，以及php相关的一些框架提供的view模板，可能说，有一定的编程基础或静下心来的决心，少花点时间基本都没有问题。
这种方式也有一个缺点，就是小型的活动页面，或者一些专题页面，如果完全套用这种方式，可能盘子太大，不适合。用纯html的页面反而会更快。
3. 然后才是真正的动手写页面切图：
写页面也是需要一个过程，从最初的写出基本的效果到解决常见浏览器的兼容bug到最后兼顾页面复用性，健壮性以及扩展性：
a. 页面的健壮性：　这个怎么说呢，这个前面已经提过，UI出的psd图是一个页面理想状态下的形态，而页面有数据，会出现两种极端状态，一，数据极多，二，数据极少。所以在页面排版的时候，考虑这两种状态，以免数据太多的时候，撑破页面，以免数据太少，页面部分元素会出现收回去状况，这样的页面会出现一些细节没有处理的常规失误。
b. 页面的扩展性：　可以说，这个也是第一条的扩充，扩展性的意思为，在页面的模块很少的时候，要考虑未来添加子模块或兄弟模块的状态，为将来留好html接口。在将来添加模块的时候，尽可能少的去动原来的html结构，使html易于扩展。这个具体情况，具体处理。一般的处理就是如果有可能会有兄弟元素就多套一层，为后台添加兄弟元素尽可能的不影响现有结构。这个点乍看起来很小，其实如果扩充到整个项目，多个项目就有可观的效应了。
c. 页面的复用性：　由于页面中风格相似的模块很多，或页面中与页面中相似的模块很多，但是总会有那么一丁点的差异，这是设计师认识世界然后在表达世界的产物，我们理解设计师的职业操守，所以只能在前期做一些技术处理，免得后期问候某岗位的亲人。具体的有的模块高点有的模块低点，还有结构完全一样，但底纹不一定。这样建议把表现形式的样式放在一个class中，物理属性放在一个class中。还有就是装饰性的图片决不不以明标签的方式插入到页面中，内容式的内容绝对以<img src="" />的方式插入中去，以免将来多主题，多语言版本的实现。
可能有时候还有的情况是，页面完全切不出来，html，css完全不知道怎么写了。但基础掌握良好，概念基本清楚。这时候我个人建议应该是吸收别人好的东西时候到了，也是个人水平瓶颈的时候，需要在坚持一下完全的突破。具体的方式就是，用firebug去分析先有的bat各个项目的各个页面，总有你可以借鉴的地方。
4. 切完页面之后：
本着职业操守或一个有责任的前端，需要进一步分析各个页面的结构是否在原来加班的时候，或问候亲人的时候没有考虑完全的，或者原来的实现方式不是太好，需要进一步完善，有性能优化或结构优化的可能。
已经同步到我博客，欢迎收看图文混排版：
http://www.cnblogs.com/jikey/p/4034353.html