学习如何书写整洁规范的HTML标记
良好的HTML代码是一个漂亮网站的基础。当我教别人CSS的时候, 我总是首先告诉他们: 良好的CSS只存在于良好的HTML标记基础上。这就好像一间房子需要一个坚固的地基一样,对不? 整洁、语义化的HTML标记具有很多的优势,但却还是有很多网站使用着并不友好的标记写法。
让我们来看一些写得并不友好的HTML标记, 并针对这些问题进行讨论,从而学习如何书写整洁规范的HTML标记。
潘少俊衡注: Chris Cyier在这里使用了两个文档来进行本文的代码说明: bad code 和 good code 。大家学习的时候请参考着这两个文件。
1. 严格的 DOCTYPE
我们要做到这一点,只需要按正确的步骤来做即可. 没必要去讨论是否使用HTML 4.01或 XHTML 1.0,两者都对我们书写正确的代码提出了严格的要求。
但无论如何我们的代码不应该使用任何Tables表格来进行布局, 所以也就没必要使用Transitional DOCTYPE.
相关资源:
- W3C推荐的 DTDs(文件类型声明)
- Fix Your Site With the Right DOCTYPE!
- No more Transitional DOCTYPEs, please
潘少俊衡注: 所谓的DTD就是文档类型声明,简单来说,就是对特定文档所定义的一些规则,这些规则包括一系列的元素和实体的声明。XHTML文档类型有三种: STRICT(严格类型), TRANSITIONAL(过渡类型)和 FRAMESET(框架类型)。目前,我们使用最多的是TRANSITIONAL,比如本站目前也是使用 XHTML 1.0 TRANSITIONAL。如果你的HTML代码书写的还算良好,那把现有的TRANSITIONAL 转为STRICT还是比较方便的。反之,也不用太急着转,个人觉得,STRICT更严谨,但用TRANSITIONAL也并没有太大影响。
2. Character set & encoding characters
在我们的
部份, 第一件事情就是声明字符集. 我们使用了UTF-8, 但是把它放到了除了字符集声明的位置外,
相关资源:
- Wikipedia: UTF-8
- A tutorial on character code issues
- The Extended ASCII table
3. 适当的缩进
在书写代码的时候,缩进并不会影响网页的外观,但使用适当的缩进能使代码更具可读性,标准的缩进方法是当你开始一个新的元素时缩进一个Tab位(或几个空格)。另外,记得,关闭元素的标签与开始标签对齐。
潘少俊衡注: 一些朋友会嫌书写代码的时候缩进比较麻烦,如果仅仅是你一个人阅读这份代码,那可能没什么问题,你自己觉得OK就好。但如果是协作或你的作品是公开发布分享的,那书写漂亮的可读化性更高的代码就很有必要了。
相关资源:
- Clean up your Web pages with HTML TIDY
4. 使用外部CSS 和 JavaScript
我们有一些CSS代码已经延伸到我们的
部分。这是一个严重的犯规,因为它它只能适用于单一的HTML网页。保持独立的CSS文件意味着未来的网页可以链接到它们,并使用相同的代码。Javascript也是同样的道理。潘少俊衡注: 当然,这个问题或许也并不是那么严重。比如作为WordPress主题来说,写在
里面的代码也就作用于所有WordPress页面。但把CSS写在里面仍然是个非常不好的习惯。5. 正确的标签嵌套
在我们的网站标题里面,我们使用
作为网站标题标签,这是完美的。并且添加了一个到首页的链接,但错误就出在把链接放到了外面,链接包围了。这种简单的嵌套错误,大多数浏览器都能良好的处理,但从技术上来说,这是不行的。
锚链接是一个内联元素,而
标题是一个区块元素,区块元素不应该被放在内联元素中。
6. 去除不必要的DIV
我不知道谁首先发明,但我喜欢“ divitis ”这个词,它指的是在HTML标记中过度的使用divs。在学习网页设计的某个阶段,大家学习如何使用一个DIV来包裹诸多其它元素来实现方便的布局和样式化。这就导致了DIV元素的滥用,需要的地方我们用了,完全不必要的地方我们也用了。
在上图的例子中,我们使用了一个 div (”topNav”) 来包含了UL列表 (”bigBarNavigation”). 但DIV和UL都是区块元素,所以没有必要使用DIV来包裹UL元素。
相关资源:
- Divitis: what it is, and how to cure it.
7. 使用更好的命名惯例
现在正好谈一下命名管理, 在上一条所说的示例中,我们的UL使用了ID名称 “bigBarNavigation.” 其中 “Navigation” 很好的说明了该区块的内容,但 “big” 和 “Bar” 描述的却是设计而不是内容. 它可能是在说这个菜单是一个很大的工具条, 但如果这个菜单的设计变成垂直的,那这个名称就会显得混乱和不相关。
友好的 class 和 id 名称 例如 “mainNav,” “subNav,” “sidebar,” “footer,” “metaData,” ,它们描述了所包含的内容. 不好的 class 和 id 名称则描述设计, 比如 “bigBoldHeader,” “leftSidebar,” and “roundedBox.”
潘少俊衡注: Chris 所强调的是按内容还是按设计来进行命名。个人补充一点: ID和Class名称使用大写还是小写,或单词首字母大写。首先,完全的大写单词是不利于阅读的,排除。至于完全使用小写还是单词首字母大写,就看个人的习惯了。重要的一点是,不管使用哪种规则,应该保持一致。不要一会儿纯小写,一会儿又首字母大写,会很混乱。
另外,我个人比较迷糊的是,对比较长的名称,是加下划线“_”, 还是连字符”-”,亦或不用。或者是我想的太复杂了吧。用哪种都好,保持一致就OK。
8. 把字型排版留给CSS
在菜单的设计中,我们一般都使用大写字母。这很简单啊,把菜单项写成大写的不就行了?但为了将来的可扩展性,我们不应该这么做。在代码中,我们应该仍然使用标准的单词大小写写法,或完全写成小写。
而之后,我们可以通过CSS来改变文字的字型,比如通过text-transform:uppercase; 把字母转换为大写,通过text-transform:capitalize;把转换为单词首字母大写。
9. 给 指定Class或id
有的时候,网页中的同一个区块,但在不同页面的时候,我们会对其进行不同的样式化。很多时候,我们会为这个相同的区块取一个新的名称,比如为新样式的DIV区块添加一个“mainContent-500.”的ID属性,为比较窄的侧边栏添加为。
这并不是一个良好的长期解决方案。正如我们第7条指出的,我们需要友好且保持一致的命名惯例。而不是增加一些花俏的新ID或CLASS名称。
为需要样式化某个区块的不同页面指定一个独立的body ID或CLASS将会非常有用。因为页面的所有内容都包含在body标签之中。指定Body名称后,你可以通过CSS Hook来完全重新定义某一个元素的样式。举个例子,原先的页面中,我们对sidebar进行了背景定义.sidebar{background:#FF0;”}而在新的
中,我们要把sidebar的 背景弄成黑色,那很简单,使用boy.aboutpage .sidebar{background:#000;} 即可。
相关资源:
- ID Your Body For Greater CSS Control and Specificity
- Case study: Re-using styles with a body class
10. 验证
一些小的HTML代码错误可能并不会对网页内容有多大影响,但通过W3C验证的代码将更有利于网页内容展示。比如下图示例中的图象,缺少自关闭标记和ALT属性。
就算没有其它原因,通过 W3C验证时看到绿色的通过提示也是件让人舒服的事情。
相关文章:
- The W3C Markup Validation Service
- XHTML-CSS Validator
- Free Site Validator (checks entire site, not just one page)
11. 逻辑顺序
如果有可能的话,尽量保持你的网页部份代码以逻辑顺序来排列是最佳的. 比如下图中,footer放在了sidebar上面,这可能是设计上的需要,内容下面正好是Footer底部,然后才是侧边栏。但如果能通过技术解决,比如Position定位,那你应该把footer放到最下面。
12. Just do what you can
我们已经总结了很多让HTML代码书写的更加简洁的原则在这里,这将是一个很好的开始,但还有更多。当你试图修复你现的代码,可能会发现很困难,而如果你完全当做从头开始学习,却可能会容易的多。不管如何,重要的是,你应该学习如何撰写良好的HTML并且坚持下去。
当你下次书写一个HTML代码项目时,谨记这些简洁原则,Just do what you can, You’ll do better!
。这种简单的嵌套错误,大多数浏览器都能良好的处理,但从技术上来说,这是不行的。
锚链接是一个内联元素,而
标题是一个区块元素,区块元素不应该被放在内联元素中。
6. 去除不必要的DIV
我不知道谁首先发明,但我喜欢“ divitis ”这个词,它指的是在HTML标记中过度的使用divs。在学习网页设计的某个阶段,大家学习如何使用一个DIV来包裹诸多其它元素来实现方便的布局和样式化。这就导致了DIV元素的滥用,需要的地方我们用了,完全不必要的地方我们也用了。
在上图的例子中,我们使用了一个 div (”topNav”) 来包含了UL列表 (”bigBarNavigation”). 但DIV和UL都是区块元素,所以没有必要使用DIV来包裹UL元素。
相关资源:
- Divitis: what it is, and how to cure it.
7. 使用更好的命名惯例
现在正好谈一下命名管理, 在上一条所说的示例中,我们的UL使用了ID名称 “bigBarNavigation.” 其中 “Navigation” 很好的说明了该区块的内容,但 “big” 和 “Bar” 描述的却是设计而不是内容. 它可能是在说这个菜单是一个很大的工具条, 但如果这个菜单的设计变成垂直的,那这个名称就会显得混乱和不相关。
友好的 class 和 id 名称 例如 “mainNav,” “subNav,” “sidebar,” “footer,” “metaData,” ,它们描述了所包含的内容. 不好的 class 和 id 名称则描述设计, 比如 “bigBoldHeader,” “leftSidebar,” and “roundedBox.”
潘少俊衡注: Chris 所强调的是按内容还是按设计来进行命名。个人补充一点: ID和Class名称使用大写还是小写,或单词首字母大写。首先,完全的大写单词是不利于阅读的,排除。至于完全使用小写还是单词首字母大写,就看个人的习惯了。重要的一点是,不管使用哪种规则,应该保持一致。不要一会儿纯小写,一会儿又首字母大写,会很混乱。
另外,我个人比较迷糊的是,对比较长的名称,是加下划线“_”, 还是连字符”-”,亦或不用。或者是我想的太复杂了吧。用哪种都好,保持一致就OK。
8. 把字型排版留给CSS
在菜单的设计中,我们一般都使用大写字母。这很简单啊,把菜单项写成大写的不就行了?但为了将来的可扩展性,我们不应该这么做。在代码中,我们应该仍然使用标准的单词大小写写法,或完全写成小写。
而之后,我们可以通过CSS来改变文字的字型,比如通过text-transform:uppercase; 把字母转换为大写,通过text-transform:capitalize;把转换为单词首字母大写。
9. 给 指定Class或id
有的时候,网页中的同一个区块,但在不同页面的时候,我们会对其进行不同的样式化。很多时候,我们会为这个相同的区块取一个新的名称,比如为新样式的DIV区块添加一个“mainContent-500.”的ID属性,为比较窄的侧边栏添加为
这并不是一个良好的长期解决方案。正如我们第7条指出的,我们需要友好且保持一致的命名惯例。而不是增加一些花俏的新ID或CLASS名称。
为需要样式化某个区块的不同页面指定一个独立的body ID或CLASS将会非常有用。因为页面的所有内容都包含在body标签之中。指定Body名称后,你可以通过CSS Hook来完全重新定义某一个元素的样式。举个例子,原先的页面中,我们对sidebar进行了背景定义.sidebar{background:#FF0;”}而在新的
中,我们要把sidebar的 背景弄成黑色,那很简单,使用boy.aboutpage .sidebar{background:#000;} 即可。相关资源:
- ID Your Body For Greater CSS Control and Specificity
- Case study: Re-using styles with a body class
10. 验证
一些小的HTML代码错误可能并不会对网页内容有多大影响,但通过W3C验证的代码将更有利于网页内容展示。比如下图示例中的图象,缺少自关闭标记和ALT属性。
就算没有其它原因,通过 W3C验证时看到绿色的通过提示也是件让人舒服的事情。
相关文章:
- The W3C Markup Validation Service
- XHTML-CSS Validator
- Free Site Validator (checks entire site, not just one page)
11. 逻辑顺序
如果有可能的话,尽量保持你的网页部份代码以逻辑顺序来排列是最佳的. 比如下图中,footer放在了sidebar上面,这可能是设计上的需要,内容下面正好是Footer底部,然后才是侧边栏。但如果能通过技术解决,比如Position定位,那你应该把footer放到最下面。
12. Just do what you can
我们已经总结了很多让HTML代码书写的更加简洁的原则在这里,这将是一个很好的开始,但还有更多。当你试图修复你现的代码,可能会发现很困难,而如果你完全当做从头开始学习,却可能会容易的多。不管如何,重要的是,你应该学习如何撰写良好的HTML并且坚持下去。
当你下次书写一个HTML代码项目时,谨记这些简洁原则,Just do what you can, You’ll do better!
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。
本文地址:/web/HTML/71862.html