为了帮助了解当今HTML 5的一些新玩意儿，我们现在就进入正题，开始使用一些新的结构元素。我们创建HTML 5文档第一件需要做的事情就是使用新的文档类型。
根据你们询问的人，不是迈向创造更语义化的网络的下一 个重要步伐，就是用一系列不完整的标签和标记大杂烩让网络陷入困境的灾难。
争论双方的问题在于，很少的站点在自然环境下使用HTML 5，所以现在所认识到的问题的理论解决方案仍然在很大程度上未经考验。
即便如此，我们不难发现下一代网络标记工具的好处和潜在的问题。
内容
1. HTML 5有什么不同？
2. 最终，一个任何人都可以记住的文档类型
3. 最基本的语义结构
1. <header>
2. <nav>
3. <section>
1. <article>
2. <aside>
3. <footer>
4. 把他们放在一起
5. 为新元素编写样式
6. 兼容老的浏览器
7. 现在你可以使用HTML 5了，但你会用么？
HTML 5有什么不同？
首先，我们通过HTML 5表达什么？First off, what do we mean by HTML 5?理论上，我们表达所有的事——新的语义结构标签，例如canvas或者离线储存等API规范，以及新的内联语义标签。尽管如此，我们把实际的原因 （PS：浏览器支持问题）仅仅局限于结构标签。canvas，离线储存，本地视频或者地理定位API都很绝妙，然而他们还不能被所有浏览器一致的支持。
“但是等等”你说，“大多数浏览器也都不支持新的结构元素！”这是真的，但他们中的绝大多数将 会很乐意去接受你想要创建的任何标签。甚至连IE6也可以处理新标签，尽管如果你想要使用CSS设置样式，你需要一点JavaScript的帮助。
当你对新标签设置样式时，你需要记住一件事，那就是未知标签在大部分浏览器中没有默认样式。他 们同时被认为是行级元素。尽管如此，由于大部分HTML 5的新标签可以构造，我们将让他们拥有块级元素的行为。解决方法是确认你在CSS样式中包含了display:block;。
为了帮助了解当今HTML 5的一些新玩意儿，我们现在就进入正题，开始使用一些新的结构元素。
最终，一个任何人都可以记住的文档类型
我们创建HTML 5文档第一件需要做的事情就是使用新的文档类型。现在，如果你还清楚的记得HTML 4或者XHTML 1.x的文档类型，你真是一个比我们更强的淘气鬼。每当我们新建一个页面，我们必须打开一个旧的文件，剪切并粘贴文档类型定义。
这真是痛苦，也是为什么我们喜欢。你准备好了么？他出现了：
不会太难记。简单并且容易理解。不区分大小写。
这个构想是停止HTML版本化，使向后兼容变得更容易。从长远看是否成功是另外的事情，但至少 他节省了你输入的平均时间。
最基本语义结构
我们已经将我们的页面定义为HTML 5文档。到现在为止，一切都还不错。现在，这些我们已经听说的新标签到底是什么？
在我们钻研新标签前，想想你一般网页的结构，大概像这样：
这对于展示用途很好，但如果我们想要知道一些关于页面元素包含什么的问题，这又怎么办呢？
上面的例子中，我们为我们所有的结构div添加了ID。这在有见识的设计师中是很平常的事。目 的有两个方面，首先，ID提供了可以能用于给页面的特殊段落应用样式的锚，其次，ID充当基本的伪语义结构。高明的解析器将会查看标签的ID属性，并尝试 去猜测他们的含义，但当每个站点的ID名称不同的时候很难。
这就是新结构标签到来的理由。
当认识到这些ID成为了惯例，HTML 5的缔造者们更进一步，使这些元素中的一部分变成他们独立的标签。这儿有一个HTML 5中生效的新标签的快速概要：
<header>
头部标签被设计作为关于一个章节或者一整张网页介绍信息的容器。<header> 标签可以包含从你位于大多数页面顶部的典型标志或者标语，到介绍一个章节的标语和开场白的任何东西。如果你还在你的页面里使用<div id=”header”>，那可以使用<header>替换
<nav>
nav元素非常明显，这是你的导航元素。当然什么被算为导航是有一些争议的，有一个基本的站点 导航，但一些情况下还可能有页面导航元素。HTML5的缔造者WHATWG最近在修改<nav>的解释，来表现怎样在同一个页面使用两次。
更多关于nav的信息以及关于HTML5的激烈争论，参见。
如果你还在使用<div id=”nav”>标签来包含你的页面导航，你可以使用简洁的<nav>标签来替换。
<section>
Section可能是新标签中最模糊的。根据，一个章节是一个内容的主题集合，通常在header标签后，在footer标签前。但是如果 需要，section也可以相互嵌套。
在我们上面的例子里，被“content”标记的div就是一个变为section的很好的选 择。另外在那个section内，根据内容，我们可以增加section。
<article>
根绝WHATWG的注释，article元素可以包含“组成文档或站点独立部分的一段内容；例 如，杂志或者新闻的文章，或者博客条目。”
记住一个页面里可以有多个article标签；例如一个博客首页可能有最新的十篇文章，每一篇 包含在一个article标签内。Article也可以通过使用section标签分为多个段落，然而当你计划你的结构时需要稍微仔细一些，否则你容易引 起以一些难看的标签大杂烩结尾的情况。
<aside>
另一个相当模糊的标签，aside元素用于“与组成文档主要的正文流内容无关的”内容。那表示 一条附加的评论，内联的脚注，引用，注解或者像你看到的在这篇文章右边的更多典型的边栏内容。
根据WHATWG的注释，看起来<aside>可以用于所有的这些情况，尽管你边 栏里的引用和标签云有着很大的不同。
没人说HTML 5是完美的！
<footer>
Footer的用处也应该是很明显的，除了可能你不清楚可以拥有多个脚标。换句话说，除了通常 在大多数页面底部看到的主脚标，段落也可以含有脚标。
把他们放在一起
让我们使用新标签重新编写我们原来的例子：
非常清楚，并且容易理解，不是么？一些注释：我们可以在header标签中包含我们 的<h1>My Article</h1>标题。我没有这样做，因为h1元素已经表达了标题的含义，但如果你还有发布日期，署名或者其他数据在你文章的顶部， 为标签集添加一个header容器标签是一个很好的选择。
同时注意我们可以在article元素下添加第二个footer元素来包含诸如翻页导航，相关 文章或者其他内容。
为新标签编写样式
在大多数浏览器中，所有你需要做的就是像你通常做的那样，为在新标签上应用样式表，简单的定义 你的样式。但请确认为每一个元素添加了display:block;规则，无论如何，从现在开始。经过一段时间后，当浏览器开始标准化，并支持新元素后， 那就不必要了。
例如，让我们在我们的header里应用一些样式：
记住，你仍然可以给这些标签添加类和ID属性。所以，如果你想要单独为一个导航设置样式，你可 以轻易的给这个标签添加一个类或者样式，就象这样：
然后你可以应用一个样式：
兼容老的浏览器
但等一下，IE怎么办？这些样式完全不能在IE6下工作。如果你仍然需要支持像IE6一类遗产 般的浏览器，这儿有一个解决方法。IE6解析和显示这些标签还好，但你不能对他们设置任何CSS。解决方法是使用一点JavaScript。
我们只需要让IE去给我们使用createElement方法创造的的HTML 5标签设置样式。在HTML 5文件的head标签内添加这点东西。或者，你可以把他保存在一个特定的文件里，并用这种方法包含。
我知道你在想什么：“哥，你根本没有为那个脚本标签定义一个MIME类型。”
你根本不需要在HTML 5做这些事情。在HTML 5中，所有的脚本都被假定为type=”text/javascript”，所以没有必要让属性把你的脚本标签搞得乱七八糟（除非你的脚本并不是 JavaScript）。
这解决了IE的问题，但我们并没有摆脱困境。现在被证明Gecko渲染引擎有一个bug，导致 了Firefox2和Camino的一些版本在这些标签上卡住。
这儿有两个方法来处理这个bug，没有一个是理想的。更多的细节请查看。这篇文章同时附有一个让所有HTML 5元素都生效的方便脚本。
记住，尽管Firefox 2的使用率很快在所有网站流量中降到了10%以下，但单纯忽略这个bug可能还是需要根据你网站的访问者来定。
现在你可以使用HTML 5了，但你会用么？
简短的回答是：我们会。
复杂一点的是：那要看站点了。如果你指责重新制作CNN主页，好吧，你可能会有一点抗拒，直到 浏览器的支持变好些。但如果你要给你的博客改版，我们支持你。这儿还有一些可以帮助你的Wordpress插 件，如果你正在使用这么流行的发布系统。这儿是一个Jeff Starr制作的。
同时，试试以站点为主的，并且查看源代码，看看他们做了什么。
尽管如此，如果IE的缺点阻止你了，这样考虑吧：就连Google也在他们的主要搜索页面上使 用了HTML 5的文档类型。就算如果你不使用所有新的结构标签，你可以至少利用一下简洁的脚本声明和下次我们会介绍的关于一些非结构的语义标签。
做了一个页面，与桌面分辨率一样大小，但是在IE全屏（F11）下却显示有滚动条，而火狐确没有。怎么样去掉IE滚动条呢？其实有一个属性就可以解决。
方法1：直接在body里面加上属性scroll
代码如：
< body scroll="no" >
方法2：使用样式表overflow
代码如：
HTML{overflow-x:hidden;}
根据自己的js代码编写经验。
在js代码优化方面主要考虑代码的长短和代码执行的效率。
1.使用局部变量避免使用全局变量
比如
function test(){
var s = document.getElementById('aaa');
s.innerHTML = document.body.clientHeight;
}
改成
架构css
在当前浏览器普遍支持的前提下，css被我们赋予了前所未有的使命。然而依赖css越多，样式表文件就会变得越大越复杂。与此同时，文件维护和组织的考验也随之而来。
(曾几何时)只要一个css文件就够了——所有规则(rule)汇聚一堂，增删改都很方便——可这种日子早已远去。(现在)建立新时，必须花点时间好好筹划怎么组织和架构css。
文件的组织
构建css系统的第一步是大纲的拟定。(我认为)css组织规划的重要性堪比网站目录结构。(htmlor注:用词夸张一点，让你加深记忆) 没有哪种方案放之四海而皆准，因此我们会讨论一些基本的组织方案，以及它们各自的利弊。
主css文件
通常可以使用一个主css文件，来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉和其他等样式。有了主css文件之后，我们开始探讨高级组织策略。
方法一:基于原型
最基本的策略是基于原型页面(archetype page)分离css文件。假如一个网站的首页、子页面和组合页设计不同，就可以采用基于原型的策略。(这种策略下)每个页面都会有专属的css文件。
在原型数量不多的情况下，这个方法简单明了、行之有效。然而，当页面元素并不按部就班的位于各个原型页时，问题就出现了。如果子页面和组合页共享某些元素，而首页却没有，我们应该怎么做呢?
把共享元素放入主css文件。这虽不是最纯正的解决办法，却适用于某些具体情况。可是如果网站庞大，(这样做的话)主css文件会迅速膨胀——这就违背了分离文件的初衷:避免导入不必要的大文件。
在组合页和子页面的css文件里各放一份样式代码。(这么做)就意味着要维护冗余代码，很显然我们不想这样。
创建一个新的文件，由这两种页面共享。这听起来不错。不过假如只有10行代码，我们创建这个文件仅仅是为了共享这10行代码?(htmlor 注:杀鸡用牛刀?) 这方法很纯粹，但如果网站庞大有很多对页面共享很少量元素时(htmlor注:比如30对页面分别共享10行代码)，就显得很笨重了。
创建一个单独的css文件，包含所有共享元素的样式。这方法可能比较简单，却要取决于网站的大小和共享元素的多少。有种情况会很烦:导入了一个很大的css文件，但页面只用到一小部分样式——还是那句话，这违背了分离文件的初衷。
这就是我所说的重叠的两难(overlap dilemma)。零碎css规则的重叠不一而足，并没有一个完全清晰无误的方案来组织它们。
方法二:基于页面元素/块
如果网站使用端include，这个方法会很不错。举例说明，如果使用页眉include，它会有自己相应的css文件。页脚或者其他部分的include可以如法炮制，只须导入自己的css文件。这个方法简单干净，不过可能会产生很多小css文件。
举例来说，假如页脚的样式只需要20行css代码，单独创建一个文件就划不来了。而且这个方法会导致每个页面都包含一堆css文件——因为有多少include，就得有多少css文件。
方法三:基于标记
这个方案直观实际，与前一个类似。如果网站共有30个页面，其中10个含有form，那么可以创建一个css文件专门处理form的样式，只在这10个页面导入它。如果另外10个页面含有table，就创建一个文件专门处理table样式……诸如此类。
另外的组织技巧
除了用主观的方法组织文件，我们还要考虑如打印、手持设备和屏幕等多种媒体类型。这虽然已经很清楚的定义过，可依旧是建立文件结构时应该考虑的一个因素。一旦必须支持多种媒体类型，主css文件里的某些规则可能就得重新考虑。
另外，品牌联合也可能是一个重要因素。(htmlor注:如google和nike联手推出的joga) 如果涉及品牌联合，你就得考虑哪些元素应该调整以适应另一品牌。比如分别使用不同的css文件等。
还有一个常被忽略的技巧:使用嵌套的@import语句。只包含一连串@import语句，或者再加几句css规则，就能创建一个css文件。用这个方法完全可以创建网站的主css文件(用@import导入各部分的样式文件)。假如网站的每个页面都导入了4到5个不同的css文件，无疑你应该考虑使用这个技巧。
规则和选择器的组织
谈完了文件组织，接着讨论一下怎么组织文件里的东西吧。很自然，我们希望在文件里畅通无阻的浏览，迅速找到要编辑的选择器(selector)或规则。
冗余 vs. 附属
正如Dave Shea在其文章《冗余 vs. 附属》(Redundancy vs. Dependency)里所说的，你必须不断了解级联(cascade)。你要决定是对选择器编组(意味着附属)，还是把它们分离(意味着冗余)。编组可以保持代码简洁扼要，可是会建立附属关系，导致维护开销增加。如果不编组，就会增加文件大小，让相似的选择器保持一致变得困难。只有做好这种权衡、取舍，才能每次都作出正确的决定。
按相互关系/上下文编组
既然文件组织可以是主观的，那么显然，按照规则和选择器与其他部分的相互关系来进行编组是最好的方法。举例说明，假设你用容器、页眉和页脚来完成布局，就应该把它们编成一组。
这似乎很简单，其实不然。比如，把页眉中的导航加入css时，是将它跟父元素编组还是独立编组?这种情况下，要视乎规则的上下文。通常，页眉与页面布局相关，应该与其他布局元素一起编组。而导航是页眉的一块，应该和页眉的其他块编组，而不是页眉本身。
使用注释
跟大多数代码类似，注释是组织良好与否的关键。应该根据css的控制范围，清楚的标注每节(section)。最好确保注释视觉突出，以便在内容滚动、一目十行时快速定位。
Doug Bowman在其文章《css组织技巧之一:标记》(CSS Organization Tip #1: Flags)里把css注释玩得高明之极。他详细说明了在节名之前加上等号，以便使用文本编辑器的查找功能迅速跳到某节。
别忘了
你应该细致认真的了解了特异性、级联和继承，并善用它们。它们之中的每一项都可以是你最可怕的敌人，也可以是你最友善的朋友。当建立庞大的网站时，是否理解这些细微精妙之处，决定了你所构建的是坚如磐石的系统，还是经不起风雨的豆腐渣工程。(htmlor注:这句完全意译，比较爽)
属性的组织
现在我们了解了文件的组织，也知道了文件内规则的组织，但还有一个重要的组织环节(没有提到)，那就是属性(attribute)。虽然属性比前两个概念更简单，可是还有一些非常好的、能够保持规则整洁的方法很值得一提。
按字母排序
提到属性，如果说需要遵循什么原则的话，那就是:按-字-母-排-序。其实这招对于属性浏览帮助不大，不过可以防止属性值覆盖这种偶然事件的发生。
举个例子吧，已经数不清有多少次，我为某个选择器定义过了margin值，之后的某天无意间又加了一个(或前或后)。(这种情况下)后一个属性自然会起作用。假设不知道第二个属性存在，不管我怎么调整第一个属性值、刷新浏览器，也看不到页面变化。(htmlor注:这个问题我深有体会) 如果按照字母顺序排列，你就会发现margin被定义了两次(因为它们挨在一起)，这个问题自然可以避免。
优先项
当网站复杂、牵涉太多css文件时，会建立大量的附属关系。一旦需要定制某个元素特有的样式，!important选项似乎是最佳选择。没错，!important是能解一时之需，但最好搞清楚导致问题的根源，然后根据级联关系决定是否真的需要用它。
如果你对上文提到的特异性、级联和继承很熟悉，大可不必抱着!important一颗树不放。(htmlor注:整片森林等着你~) 当然它还是会派上用场，不过使用之前要对具体情况了然于胸。千万不要因为不知问题的症结所在而把!important当作捷径或是补救方案。
小结
当我们变得依赖css而使样式表日渐复杂时，就需要正确的计划来避免犯错，并使代码易于维护。既然完美无缺的方案并不存在，那么了解css的工作方式以及文件、选择器和属性的多种组织方案，无疑有助于我们写出优质的代码，经受住时间考验。
网站制作效果可以很一般,放到网上没人能够认识出你。网站制作效果也可以很独特，充分的展示网站的意思，让人耳目一新。
因此，网站制作不仅仅是技术，而是一种艺术。
你可以泛泛的展示你的产品、企业形象，语言平淡的让人乏味。也可以风趣、幽默、机智。从而使你的网站展示出与众不同的特点。
真正优秀的网站是艺术与灵魂的充分表达。