CSS最佳实践团队开发 来源：w3cplus你有过多少次接手别人开发过的项目，却发现作者的代码思路一团糟吗？或是你跟几个团队成员合作开发，他们每个人都有自己书写代码的方式吗？或是你重新回顾你多年前开发的项目，不记得当初是怎么想的？　　我总是遇到这种事情。事实上，我最近在修复供应商提供facepalm-inducing的css上花费了将近300个小时。这300个小时，使我充满了挫败感，不仅是因为我自己，还有我的团队成员的原因。而且他占用了本应该花费在新项目上的宝贵时间和资源　　如果供应商在他的css中已经遵循了一些基本的指导方针。那么将会为他节省宝贵的时间和金钱，更不用说我会已更好的状态去对待他。在本文中,你将学习书写CSS的最佳实践来帮助你避免不一致和冗余;实际上,这样制定标准,简化了团队开发的工作。　　结构化　　书写好的css的基础是有良好的结构。这样的css可以帮助我以及任何将来要更新这段代码的人，更好的理解并快速定位到要找的样式上。　　在开始写样式前，我先定义了一个css文件结构，根据页面中不同内容部分划分的区块。通常，这些结构是每个网站通用的:　　1.Header　　2.Navigation　　3.Main content　　4.Sidebar　　5.Footer　　在我的样式文件里，我添加了必要的注释，以标明每个部分的样式从哪里开始/*---GLOBAL---*/ /*---HEADER---*/ /*---NAV---*/ /*---CONTENT---*/ /*---SIDEBAR---*/ /*---FOOTER---*/注意第一个注释global的部分，他不是针对于网站的特定内容，而是针对网站上的通用样式，例如布局结构，以及标题、段落、列表和链接等基础样式。　　在样式头部设置通用的样式，有助于全站更好的继续共有样式，并在需要时覆盖即可。　　越多的css就需要越多的组织　　在创建超大型的网站，处理相当多的css时，我就会给每个区块里添加二级注释。例如，在global里我定义这样的二级结构分类：/*---GLOBAL---*/ /*--Structure--*/ /*--Typographic--*/ /*--Forms--*/ /*--Tables--*/ /*---HEADER---*/ /*---NAV---*/ /*--Primary--*/ /*--Secondary--*/ /*---CONTENT---*/ /*---SIDEBAR---*/ /*---FOOTER---*/　同样你也看到了我给NAV也添加了二级注释，分别为主导航和次导航。　　事实上，对于很少css的小型网站，我通常是不使用二级注释的。但是对于大型的css文件，二级注释被证实是很管用的。　　自由格式化　　你使用的注释格式完全取决于你。以上你看到的例子是我和我的团队很钟爱的方式。也有些人喜欢用两行定义他们的注释格式：/* HEADER ------------------------------*/一些人不使用二级注释，他们用一种完全不同的结构，不是根据页面内容划分，而是用元素的类型划分如：headers，images，lists等等。关键是用你喜欢的格式去定义并一直这么使用。　　想根据内容元素划分？没问题。想要小写注释，那就去做。不想使用二级注释缩进？那就不用.不喜欢连字符想用时间？ok。你只需要做对于你和你的团队最有意义的事情就好。　　交流注释用法　　我们已经了解了注释的结构，但是你应该就这如何使用注释的问题跟你团队的同事交流一下。　　什么时间，谁做了什么　　作为团队成员的一份子，很有必要在团队成员之间交流已经写好的css文件的相关细节。在我的团队里，我们在css文件的头部添加了一些css文件创建和更新信息的摘要注释。/*----TITLE: Main screen styles | AUTHOR: EPL | UPDATED: 03/23/10 by EPL----*/在处理多个样式表时，头部的信息是有用的。如一个屏幕，一个用于打印，一个用于移动甚至是关于ie的hack写法。作者的信息让团队成员知道一旦css出了问题应该去找谁。而更新信息让团队了解谁最后做的更新以及更新时间。　　至于你的摘要注释，仅需要包含对你团队有用的信息。如果你不需要作者信息，跳过。如果想要版权声明加上。我甚至见过摘要里面有地址和联系信息的。/*---- IE6 screen styles (ie6.css) Company ABC 1234 Avenue of the Americas New York, NY 10020 http://companyabc.com Updated: 03/23/10 by EPL ----*/颜色值　　我遇到过的最有用的css注释之一是网站用到的颜色值。/*---COLORS: Green #b3d88c | Blue #0075b2 | Light Gray #eee | Dark Gray #9b9e9e | Orange #f26522 | Teal #00a99d | Yellow #fbc112---*/颜色值在开发阶段很有用，节省你测试颜色和从其他样式里查找的时间。你不需要知道这个十六进制值是不是蓝色，你只需要找到这个颜色值，然后复制粘贴即可。　　在我的团队里，我们在css文件头部添加通用的颜色值，要在所有样式声明和注释前，摘要注释后面添加。我们也尝试保持关键字尽可能简单方便维护，但是他到底有多复杂完全取决于你。　　格式也全取决于你。你可以让所有定义的颜色值放在一行显示，也可以把他们分成多行显示:/*---COLORS Green #b3d88c Blue #0075b2 Light Gray #eee Dark Gray #9b9e9e Orange #f26522 Teal #00a99d Yellow #fbc112 ---*/同样，找到一个最好的有利于你需要的格式，一旦定义好就要保持他的一致性。　　开发和调试　　有时候在我开发的过程中，不得不徘徊在我的css 和团队其他成员之间。而这时注释就派上用场了。当我有时冥思苦想为什么css在ie下会有这样的bug，我就只需要走开即可。　　你或是你的同事做个笔记，包括可能的样式，和没有解决的困惑：/*--//--Styling for link states is pending new changes from designer, please don't edit | EPL 03/23/10--\\--*/ a, a:link, a:visited { color:#0075b2; text-decoration:none; } a:hover, a:focus, a:active { color:#b3d88c; }为了让他们与众不同，我通常用一种不同于其他注释的格式，同时让他们尽可能的详细。还是使用最适合你的格式。　不过记住，一旦你完成开发和调试工作，这些注释就没有用了。他们既不跟你的工作有关，也不跟你的css有关，他们的存在只会增大你的文件体积。　　样式重置　　样式重置已经很流行。他们出现在样式文件的头部，用来设置html元素在跨浏览器显示的基本样式:/*---RESET---*/ html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td { margin: 0; padding: 0; border: 0; outline: 0; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline; }以上的例子摘自Eric Meyer的重置文档，这个我也经常用。但是我倾向于去掉我用不到的标签，我也建议你这样做。比如我的团队构建的网站里面几乎没有<kbd>,也没有<iframe>,<applet>或是包含以上的一些元素。　　所以，我去掉这些元素选择器。虽然在页面加载或是文件体积上只有很小的不同，但是我感觉这样有助于，避免团队成员间对于不使用的标签的困扰。　　如果我不想要覆盖浏览器的内置样式，我也可以编辑重置样式表，例如如何处理无序列表。在这种情况下，我确保这些元素不包含在样式表声明里。　　不过，我应该澄清一下，css重置并不适用于所有人。你有很多不使用他的理由，这由你决定。如果你要重置样式，要保持你的重置样式表尽量干净和特殊。　　命名约定　　最头疼的事情之一是，遇到其他人写的css，而且是定义的类名和id名毫无意义的那种。例如像下面这样：.f23 { background: #fff; border: 1px solid #ff0; font-weight: bold; padding: 10px; }我根本不知道.f23是什么意思。甚至更糟的是都没有任何形式的注释。我不知道.f23代表什么内容。是标题？主要内容？还是导航？　　这种情况，尤其是对于大型网站，就可能浪费大量的时间去查找出现这个类名的标签位置。如果作者用一个约定好的名字命名，如那些有意义的，那些基于内容的样式的：.alert { background: #fff; border: 1px solid #ff0; font-weight: bold; padding: 10px; }如你所见，类名.alert提供的上下文信息要比用一个随机数组成的类名提供的信息多。　　不仅仅是上下文，有语意的命名还可以节约时间。考虑到一个公司品牌的频繁更换，如果你开发的css使用表现的类名而不是语义化的类名和id名，那么在寻找、维护css时，你将比预期花费更多的时间。　　例如，如果你给网站上一块内容，定义一个bluebox的类名，使用了公司logo的蓝色基调。然后公司重组了，他们现在用红色基调的logo，这时你的.blueBox就没有意义啦。所以你不仅需要更新样式表的十六进制颜色值，还需要修改标签中的所有引用到blueBox的地方。　　相反如果你用callOut作为类名（或是同样有意义的名字），你会省去手头的很多工作量。　　类名滥用　　在css 的使用中，我倾向于能少则少的原则。不能因为你可以给每个元素指定类名，就意味着你就应该给每个元素指定类名。　　在我修复供应商糟糕的css过程中，发现类名被滥用了，出现在许多本来不需要的地方。例如每一个lable标签就定义一个lable类名，每一个form就定义一个form。但是我们的设计和结构中只需要给一个form元素设置样式，它里面也只包含一个label元素。form.form { float: right; margin: 0; padding: 5px; } label.label { clear: both; float: left; text-align: right; width: 145px; }　由此产生的css本身和他造成的冗余并不可怕，可怕的是他造成的困惑。作为一个设计师看到了这个form类，可能猜想是不是其他样式表里也定义了叫form的类名，然后去查找根本不存在的样式，这就是我时间浪费的原因。　　类名不等于特异性　　上面只是一个简单的例子。一个我遇到的有关类名更疯狂的例子是渴望给予元素特殊性<div id="feature"> <ul> <li><a href="#newServices">New Services</a></li> <li><a href="#newProducts">New Products</a></li> </ul> </div>注意到tabs的类名应用到了上面结构中的每一个标记？导致如下的css目录列表:div.tabs ul.tabs li.tabs { float: left; font-weight: bold; padding: 3px; }对于li最简便的解决方法应该是这样：#feature li { float: left; font-weight: bold; padding: 3px; }如果你的元素定义样式不需要类名，那就不要用。用的太多类名，不仅使你的结构和css很臃肿，也失去了他们在css 中的意义。　　你也许注意到了在最后的例子中，我仅使用了# feature作为选择器而不是div#feature。只有在为了区别其他选择器的情况下，添加div才合适，否则只会给你的团队带来负担。而且尽量少用特殊的声明，也为日后覆盖任何样式提供方便。　　多类　　最后一点，我不喜欢多类，你也许还有印象。虽然我不提倡使用不必要，多余的类名，但是对于通过多类保持元素表现的共用，我可是一个忠实的粉丝，然而可能有一些理解的不同之处：.announcement { background: #eee; border: 1px solid #007b52; color: #007b52; font-weight: bold; padding: 10px; } .newsAnnouncement { background: #eee; border: 1px solid #007b52; color: #007b52; float: right; font-weight: bold; padding: 10px; }上面的两个声明，除了.newsAnnouncement多了一个浮动外，都完全一样。所以我大可像下面这样而不是重复写相同的样式:.announcement { background: #eee; border: 1px solid #007b52; color: #007b52; font-weight: bold; padding: 10px; } .floatR { float:right; }然后给我的新闻内容添加两个类名<div class="announcement floatR">但是且慢，我不是说过要根据约定好的名字而不是根据表现命名吗？没错，但是凡事总有个例外。　　是的，.floatR是一个表现类名，但是他适用于这种情况，而且可以用于其他需要多类的情况，所以这是我的团队经常使用的方法。　　分组选择器　　在我的300个小时的折磨里，遇到的另一个问题是完全相同的样式出现在多个样式表里，而唯一的区别就是声明他们的选择器不同：#productFeature { background: #fff; border: 1px solid #00752b; float: left; padding: 10px; } #contactFeature { background: #fff; border: 1px solid #00752b; float: left; padding: 10px; } #serviceFeature { background: #fff; border: 1px solid #00752b; float: left; padding: 10px; }这不仅使得css文件体积过于臃肿，也使维护成了噩梦。解决方法就是合并他们成一个样式声明：#productFeature, #contactFeature, #serviceFeature { background: #fff; border: 1px solid #00752b; float: left; padding: 10px; }现在如果要更新样式只需要修改一个声明而不是三个。　　一行还是多行书写？　　本文中出现的所有css实例都是用的多行的格式，每一对属性和值占单独一行。这个是广泛使用的约定，不仅是在css文件中，也多出现在书里和文章里。许多人认为他的可读性很好，这也就是什么我在本文使用他的原因。　　然而在和团队的工作中，尤其是大型的css文件，我是将样式写成一行:.alert {background: #fff; border: 1px solid #ff0; font-weight: bold; padding: 10px;}就我个人和我的团队而言，觉得单行的可读性更好。当你查找css时多行样式就变得很麻烦，相比较而言单行查找更容易。　　对于你和你的团队，选择最合适你的团队的格式，并一直使用他。　　需要依照字母顺序排列吗？　　一些人建议将每个声明按照字母表的顺序排列，方便快速查找一个属性。以前我对这样的事情并不在意，但是经过处理供应商混乱的css之后，我意识到将一些思想应用到样式声明的组织中是个很好的主意。　　尽管我发现按照字母表排序很有用，但是我还是会根据上下文来组织哪些属性放在一起。比如，我喜欢将所有的盒模型属性放在一起。如果我使用了绝对定位，我就把这些属性放在一起:#logo { border: 1px solid #000; margin: 0; padding: 0; position: absolute; top: 5px; right: 3px; }这里没有对错之分，仅仅是决定用哪种属性的排序并一直用它就好了。　　使用简写　　使用css简写一直是认为可以提高你的css水平的方法。他同时也适用于团队，它不仅可以有助于浏览，而且可以方便设置大家遵守的标准。这样就减少了花费在思考和书写样式的时间。　　0值　　如果你使用0值，没有必要给他指定单位:margin: 2px 3px 0px 4px   变成margin: 2px 3px 0 4px颜色模式　十六进制颜色值如果是由三对数组成，可以从每组中抽出一个数组成该颜色值的简写:color: #ff0000写成color: #f00盒模型属性　　盒模型中的margin，padding，border如果四边值相同，可以合并:padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px合并成padding: 5px如果上下，左右值一样，你只需要写两个就够了：padding: 5px 10px 5px 10px合并成padding: 5px 10px字体属性　　多条字体属性可以合并成一条font-style:italic; font-weight:bold; font-size: 90%; font-family: Arial, Helvetica, sans-serif;合并成font: italic bold 90% Arial, Helvetica sans-serif背景色属性　　背景属性也是可以合并的background-color:#fff; background-image: url(logo.png); background-repeat: no-repeat; background-position: 0 10%;合并成background: #f00 url(logo.png) no-repeat 0 10%请注意最后两个例子，字体和背景属性。属性值的声明顺序要按照w3c的标准来。　　验证，验证，再验证　　虽然一些人认为验证css需要指定一个很好的验证规则，这一点我不强求但是他绝对是有要求的。验证能够确保你的工作，是否准备好分享给团队的其他成员，所以他应该满足下面要求：　　1.容易开发和故障排除　　2.保证现在和未来的浏览器显示一致　　3.保证页面的快速加载　　4.作为可访问性的一部分　　5.把他正确的写出来　　我建议使用W3C CSS验证服务。　　压缩工具　　如果你的团队关心文件大小，页面加载和带宽的话，你应该考虑使用一个压缩工具。它主要是用来去除不必要的注释，空格。这里有一些压缩工具可以考虑：　　1.CSS Compressor　　2.CSS Optimizer　　3.Code Beautifer　　4.CSS Tidy　　我不建议在开发的过程中压缩文件，因为压缩可以减小你的文件大小，同时也削弱了你和团队之间协同开发和处理css 的能力。因为他去掉了具有可读性的所有注释和空格，所以应该把压缩作为产品上线的最后一道工序。　　冰山一角　　本文中提到的只是少数基础实践，他们可以帮助你和团队高效的工作。遵循这些准则可以进一步完善你的css。如果你很感兴趣的话，我推荐你阅读下面的文章:　　1.Different Ways to Format CSS　　2.Unique Pages, Unique CSS Files　　3.Single-line vs. Multi-line CSS　　4.CSS Property Order Convention　　5.On HTTP: Page Load Times, Multiple File Requests and Deferred JavaScript　　6.Don’t Use @import　　7.Efficient CSS with shorthand properties　　8.CSS Sprites: What They Are, Why They’re Cool, and How To Use Them　　9.Object Oriented CSS　　遵守黄金定律　　不管你是工作在一个团队中，还是作为外包或是作为团队的唯一成员，这些css准则将为你日后成为一个优秀的团队成员打好坚实的基础，它不仅节约你的开发时间，也避免了不必要的沮丧情绪。　　译者手语：初次翻译前端技术博文，整个翻译依照原文线路进行，并在翻译过程略加了个人对技术的理解。如果翻译有不对之处，还烦请同行朋友指点。谢谢！　　英文原文：http://msdn.microsoft.com/en-us/magazine/ff679957.aspx

HTML5！酷炫的canvas        HTML5早在2004年就被WHATWG提出，于2007年被W3C接纳，并成立了新的HTML工作团队。在2008年1月22日，第一份正式草案已公布，预计将在2010年9月正式向公众推荐。HTML 5有两大特点：首先，强化了Web网页的表现性能。除了可描绘二维图形外，还准备了用于播放视频和音频的标签。       但是，今天我简单的研究了一下HTML5的<vdieo>标签发现这个标签只支持OGG和MPEG4的视频播放，其他的主流视频如AVI等文件，均不支持！其次，真的是有了HTML5就可以放弃FLASH吗？答案是不可能的！FLASH依然有着她的优势，比如在FLV流媒体等方面有着显著的优势！       canvas是HTML5提出的一个基于JS的语言，她可以直接在WEB页面上绘制二维图像，这点是现在的JS不太兼容的地方！现在网上流传着一些检测HTML5兼容性的页面，我发现绝大多数的都是HTML5+JS的       说到HTML5就不能不说现在的DW5.5！DW5.5号称支持HTML5，但是我测试了一下，虽然标签有了，但是设计式图中，缺陷还是很大！如果大家想要自己测试HTML5的话，最好还是准备IE9.0吧！因为现在对HTML5兼容性最好的就是IE9.0了！       其实HTML5还有很多路要走，随着W3C的规范，相信HTML5在以后的规范当中还是有很大的发展。       对了~顺便说一句！HTML5+CSS3.0真的很好！近期会发布第一个用纯用HTML5+CSS的页面出来！敬请期待吧~哈哈！