文章|新闻|资料归档: 2008年11月23日

2008年11月27日星期四

敏捷测试的最佳实践，三向敏捷测试转变

引言

简洁，轻量的敏捷开发模型是为了提供给软件开发团队一种迅速应对客户需求变化，能够高效完成项目工作，降低整体风险的开发模式。敏捷的测试也是服务于这个目标的测试团队对测试工作的敏捷定义。

传统测试模式下成长起来的测试团队要如何转向敏捷，从个人和团队的两个层面又要做出那些转变呢？有什么方法和标准衡量敏捷测试团队的绩效？如何帮助团队的每个人规划正确的发展路线？团队在部署敏捷的过程中又会遇到哪些问题呢？本文主体就这些问题展开论述。

有关敏捷测试团队和个人的绩效

在我们过去一年多开发敏捷项目的令人难忘的经历中，测试团队携手开辟了一条新的道路，并发展至今。测试团队也曾多次因其突出的能力，积极的态度以及卓有成效的工作成果屡受嘉奖。今天我们仍然在思考怎样做好敏捷测试，因为我们仍然遇到更新的问题，我们在积累成熟经验的同时也在不断尝试改进原有方式和突破对新问题的困扰。在这里，我们的实践或许因基于幸运的历史背景和人文环境，能够基本成功的部署敏捷，但我们对敏捷测试在整个软件开发过程中的角色定位，和职责的理解，仍然对将要采用敏捷测试，以及感兴趣于敏捷的测试团队，和对那些需要从传统测试转变到敏捷测试模式的团队起到参考作用。

“如何看待敏捷测试和对测试人员做绩效考评呢？”——敏捷团队中无论开发还是测试都不是个人的开发和测试，这是团队的工作。一名好的测试人员除了能够做好本职测试工作外，表现为愿意并能够做超出原有范围的工作，能够并愿意帮助团队其他成员解决其他复杂问题，实现团队的共同目标。测试人员能够主动发现并弥补团队中的重要缺失的环节，帮助团队其他成员完成工作任务。

测试团队的职责也从仅仅发现问题的工作中向着眼于整个项目质量保障转变。因此不难得到结论，在敏捷团队中，优秀的测试人员身上有其他成员的影子。在时间紧迫的情况下，他能转变成其他角色，做出更多的创造性的成绩。充分地发挥了个人战斗力，在帮助他人的同时，自信的态度和各项工作中的技能得到增强，自身也可以获得更大发展。

在一次关于敏捷开发、测试经验交流中，我们认为敏捷测试团队更需要其他团队的协助，在设计测试用例时，团队的设计人员应该帮助测试团队设计测试用例，并帮助测试团队做更多的面向客户环境的真实测试。开发团队也要确保开发任务的按时推进，和测试团队保持紧密的合作，在测试任务紧要时，也能够转变其职能帮助测试团队完成测试任务。

测试人员向敏捷转变所需要的技能储备

这引出我们今天要探讨的一个问题，测试人员如何在技能上做好准备以面临敏捷开发的全新挑战。我们认为，一名优秀的敏捷测试人员，需要有较强的学习能力，至少有主动学习的意愿。除了需要了解各种类型测试以及各种测试工具，测试技术外，也需要了解项目中软件设计模式，软件语言，以及项目的程序组织架构以便建立和团队的共同语言空间。

因为敏捷团队是一个高度协作的团队，在这样的团队中工作需要很好的沟通技巧，语言能力和协作能力。

除此之外，团队的每个成员，都应该认真学习并努力寻找适合自己团队的敏捷模式，并沟通以达到团队成员对敏捷开发模式的统一认识，使得团队其他成员对自己工作的充分理解和建立起成员之间的相互信任。

测试人员向敏捷转变所需要的方法

培养好的敏捷测试人员，需要培养其技术能力，也需要用正确的培养成员的敏捷思想。敏捷的方法指导敏捷团队行动，是敏捷测试原则的实践。从一开始，就深刻影响着团队中每个人。当然，方法不是放之四海皆准的，需要团队对敏捷原则深入理解，执行敏捷测试实践后逐渐形成的规律。而一个传统的测试团队，在固有的行为规律下，在成熟的产品线里，或者层次分明的复杂组织结构里如何做好向敏捷的转变呢？似乎这种改变给许多人带来希望的同时伴随着一点恐慌？我们有没有可行的策略、方法可以遵循呢？可否让团队又能够发挥在传统开发模式下的力量集中的优势，又能够做到敏捷的随需应变呢？回答是肯定的。

在做转变的实施前，我们需要有心里准备，任何从传统开发到敏捷开发转变不可能一蹴而就，自然也没有人能够将一个传统开发模式下的测试团队一夜之间变成彻底的敏捷。对这些还没有敏捷起来，但仍然以此作为目标的项目团队我们建议循序渐进，基于笔者的亲身体验，提供以下实施的方法请大家参考。

首先我们建议采用迭代的开发模式作为向敏捷的模式转变的起点。很多传统开发模式或者基本上还是瀑布式的开发，或者是周期性的瀑布式开发，这些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑布开发的不断累加。换句话说，传统开发是传递性的工作，一方完成，另一方接手。而敏捷活动的迭代行为更强调尽早开展各项活动，从迭代的一开始就协同工作，共同实现团队迭代的目标。而一旦抵达迭代的周期中最后一个工作日，此迭代宣布退出。

当完成了向迭代活动的转变完成后，接着，我们开始寻找项目过程、管理、执行中最紧要的问题，并使用敏捷开发中的最佳实践来一一解决这些实际问题。也许，一开始这个过程是很缓慢，而且很难做到一步成功，但是必须通过不屑的努力和足够的耐心，慢慢转变团队的固有思维方式，并最终努力获得团队对改进后结果的统一认可。而一个问题被解决，或者不再是项目中最严峻的问题时，我们应该开始寻找下一个待解决的困难了。重复这个过程直至成功的将团队中有悖于敏捷原则和实践的过程和方法调整过来，同时将正确的思路和方法带给团队。

在最近的几次与其他敏捷测试团队的讨论中，我们同时了解到许多软件开发项目中的测试团队遇到过类似的一些问题，如开发团队没有做单元测试或做得太少，继而在开发过程中的遗留了大量质量缺陷和频繁的回归现象。这使得测试压力急剧加大，测试过程严重受阻，甚至影响到整个迭代的退出和项目的输出结果等等。又或者传统的开发中的测试团队因为很少有条件去认识客户，了解和实际用户相关业务需求。测试脚本和用例的设计只是基于开发人员撰写的功能说明。因此，难以做到对需求变化做出快速反应。经过讨论，我们推荐给对这样的团队如下参考方案。

首先开始采用测试驱动开发 (Test Driven)。
开发人员首先要善于使用测试驱动开发方法写每一行代码，先写测试脚本后写代码，并反复使用单元测试脚本验证所写代码的正确性。

列出需求
为需求撰写一个单元测试脚本
执行测试确信测试结果是失败的
然后，写上仅仅足够的代码以使得先前的测试可以通过
当所有测试通过了，便可以开始写下一个测试脚本
针对需求有效的实现所有测试脚本
另外，当需要代码重构时候，也应该先重构单元测试脚本，在改动代买之前同样先改写测试脚本。

尽早的开始测试，开始系统测试，不要等待到功能完全做好才开始。
了解计划中的待实现的功能，了解其权重分配，设计系统测试和功能测试用例。测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的安全测试，性能测试，压力测试，并发测试，全球化测试等。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。

然后策略性的进行自动化测试，设计并开发可以用于日后回归测试（Regression）和用户接收测试（Acceptance Test）的自动化脚本，持续维护与开发这些脚本。自动化测试为团队带来的是长期效益，自动化测试的开发也应该首先选择部分测试对象，例如，API，框架等比较稳定和关键的功能做功能测试的自动化；对产品的性能指标，压力测试也要较早的制定自动化测试的计划。

最后，要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。

而且，要做好敏捷测试，我们需要转变测试等待开发的思想，测试人员需要了解开发，需要读懂代码，才能够更好的帮助开发人员分析和分离复杂问题。有甚者，测试人员可以成为开发人员的后备力量。当团队中需要更多的人撰写代码时，测试人员应该勇当其职。

敏捷测试的最佳实践：一敏捷的实质

本文讲述了作者在两年的敏捷测试和开发工作中的经验和体会。从敏捷的实质，敏捷测试的方法和过程，到如何帮助传统团队转变为敏捷团队做了详细阐述。本文是系列的第一篇文章，着重讲述敏捷实质。
从游戏开始……
　　有个非常有意思的游戏能够帮助大家理解敏捷和传统开发的差异。游戏有两个角色，一个是“老板”，另一个是“员工”，在 2 分钟内，“员工”需要在“老板”的完全指挥下，即“向前一步，向后一步，停，向左一步，向右一步”，完成 60 步移动的任务。“员工”需要执行“老板”的每一个指令，不允许做出相违背的动作。“老板”则不参与行动，只发出指令指挥“员工”的活动。我们体验这个游戏时，当场 60% 的参与者成功完成了任务，大致估计出我们的工作效率是 50%*60%=30%。游戏后，参与者被问及对这种行为方式的感受时，无论是“员工”还是“老板”都表示非常不满。

　　接着，大家又做了另一组游戏。2 分钟内参与者被要求独立的、自主的完成 60 步移动任务，在这次游戏里，所有参与者任务相同，大家可以自行决定、并依据自己的判断随时调整其步伐方向，快慢。最后，我们发现所有参与者不但毫无折扣的按时完成了任务，因而工作效率也达到 100%*100%=100%，而且所有人对于这种新的工作方式更是产生了极大的兴趣。

　　以上两个游戏方式的对比就折射出传统开发（前者）与敏捷开发、测试活动方式的对比，其中优劣不言而喻。

　　而敏捷开发、敏捷测试又是怎样一个概念呢？他们是否能够帮助我们的团队突破束缚，在日益激烈的竞争环境里表现得更为出色呢 ? 请参考我的这个系列文章——“敏捷测试的最佳实践”。

敏捷的价值

　　首先我们解释一下什么是敏捷，在字典中我们得到解释，敏捷，即反应迅速、可以快速变化。如今敏捷开发已成为众所周知的时髦 IT 词汇，在这个领域里敏捷又被诠释为迭代的，快速应对需求变化，轻量级，并且简洁。

　　图 1. 面对客户业务复杂度问题提出敏捷的解决方案

　　IBM 重视敏捷开发，敏捷的软件开发策略之也被广泛推广开来。中国软件开发中心是 IBM 软件部部署敏捷开发方法的重点实验室之一。我们也是 IBM 中国软件开发中心最早使用敏捷方法的开发、测试的团队之一。这篇文章主旨为帮助那些愿意采用敏捷，和正在采用敏捷开发、测试的团队正确了解敏捷的实质。

　　笔者做敏捷项目已经近两年时间，对于敏捷的理解，认为最为关键的是需要注意两个方面，它们是“高度迭代”和“持续不断的客户反馈”。

高度迭代：迭代就是指产品的开发过程中，一个完整的开发活动周而复始的进行，产品的功能、性能、可用性在周期活动的叠加中不断得到更新和加强。甚至指在一个迭代周期内产品活动也具显著的周期性。同时，团队间、团队内部成员的高度协作及时帮助解决了各成员的依赖性问题，因此，也促进了各个成员工作的顺利开展，保障了产品活动稳定的持续性、周期性。以测试为例，传统开发模式下，测试人员可以因进入测试阶段的条件不完全满足而继续的等待。而在高度迭代的敏捷项目里，不同的是，我们希望测试人员能够尽可能的做能够做的工作，尽可能的早工作。“等待”在敏捷开发、敏捷测试范畴里已是一种错误概念了。
持续不断的客户反馈：指在产品开发任何时期，代表项目业务（Business）的利益干系人（Stakeholder）都要参与到产品的需求分析，设计，以及其他活动的决策制定中来。致力于在短时间内帮助团队实现将客户的需求转化为高质量的可消费产品，并转化成利润。

敏捷测试的最佳实践，二方法与实践

前言

如果您已经阅读过敏捷测试系列文章的第一篇，敏捷的实质，您应该已经了解敏捷的定义，了解什么样的团队是敏捷的团队了。而您也可能早已开始思考，什么是敏捷测试的实质？敏捷的测试团队又是如何形成自我管理、自我发展的组织呢？测试团队又是如何安排日常工作呢？敏捷测试活动与传统测试活动有很大差异吗？为了进一步让您了解如何将敏捷原则运用到活生生的日常测试活动中，我们为您推荐敏捷测试系列文章的第二篇——敏捷测试的实践。

在敏捷活动如火如荼的推广运动中，我们显然无法预知如何在您的特定的复杂环境中您能否最后达成所愿，也无法为您预测出前进道路的分岔口可能唯一的正确的线路，我们却可以为您点起一盏明亮“街灯”，在这迷雾中驱除黑暗。我们将为您提供一个可以借鉴和可供参考的成功的敏捷测试实践案例。我们将逐一向您介绍、分析这个案例中的敏捷团队的组织结构，主要的敏捷测试行为，迭代的测试模型和一套以四周为周期的敏捷测试活动时间表。

请您运用您已具备的敏捷实质、敏捷原则的知识，并结合您的独特项目环境、带着您的问题，与笔者一起再度分析这个案例，希望您最终也能得到满意的答案，并随后开始实施部署敏捷测试。

敏捷测试的实质

测试不仅仅是测试软件本身，还包括软件测试的过程和模式。产品发布后才发现很多问题，很可能是软件开发过程出了问题。因此测试除了需要确保软件的质量，即软件做了正确的事情，以及软件做了应该做的事情以外，敏捷的测试团队还要保证整个软件开发过程是正确的。

敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续的响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。作为一名优秀的敏捷测试人员，他（她）需要在有限的时间内完成更多的测试的准备和执行，并富有极强的责任心和领导力。更重要的是，优秀的测试人员需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。他（她）将帮助团队其他成员解决困难、帮助实现其预期目标，发扬高度协作精神以帮助团队的最终获取成功。需要指出的是，团队的高度协作既需要团队成员的勇敢，更需要团队成员的主动配合和帮助。对于测试人员如此，对于开发、设计人员，其他成员也是如此。

敏捷测试的方法与实践

是的，敏捷测试也需要高度迭代工作、频繁得到 STAKEHOLDER、客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。

是的，“人”才是敏捷的实体，敏捷测试也是以人为本的。不难理解，“敏捷”的一切都围绕着人展开，如敏捷鼓励直接，平行的沟通；敏捷需要持续的客户反馈以及敏捷活动的设计，方案和决策需要团队协同制定等等，敏捷测试需要一支非同寻常的团队，不同于以往传统开发模式下的团队结构。关于敏捷团队、敏捷测试团队的组成和介绍，将是我们讲述敏捷测试实践的第一步。

“人”是重心，方法、策略是辅。为了适应不同的团队结构，不同的项目环境，敏捷项目和敏捷活动的实践也应该因“人”而异，但是，并不是说可以天马行空，我行我素。一旦脱离了正确的敏捷方法、和敏捷原则的指导，我们的敏捷活动就好比摸黑前行了。

这正是我们需要学习前辈和敏捷主义大师们的经验意义所在了，笔者在过去的实践中受益颇多的也正是前人的实践经验和方法。因此，学习前人的经验和方法，并运用这些最佳实践来帮助敏捷开发团队，甚至是传统团队来解决时下重要的问题是十分有意义的事情。笔者不敢妄自尊大将自己的一般实践纳入经典方法范畴，但经历了两年的研究和改进，笔者提出的敏捷测试的原则也得到了业内同僚和“大师”的普遍认可。经过多次和其他项目团队的经验交流，我们也不断的改进着我们的原则、方法。因此，笔者要非常感谢参与讨论的同僚们，没有你们的热情参与，也不会有今天的笔者信心百倍的执笔了。正如笔者在借鉴了前人的成功案例中的经验和方法之后定制了符合项目需求的测试原则一样，相信，读者们在阅读了笔者的敏捷测试原则和方法后，同样也会有所收获。而对笔者经历的敏捷实践活动中的方法和测试模型的讲解将成为我们讲述敏捷实践的第二步，也是本文的重点。

综上所述，笔者将运用本文的主要篇幅为大家讲解这个敏捷实践。它们是：

敏捷团队组织构成，敏捷测试团队的任务和使命；
敏捷开发团队以测试为驱动的开发方式——测试驱动开发，这是种独特的测试？还是开发？
递增型的迭代测试，它首先是对敏捷测试过程活动和生命周期模型的介绍，通过学习经典的敏捷增量测试模型，我们将敏捷测试的各类活动有机的组合到了一起。在此之上，对定制后的独特敏捷增量测试模型的分析和理解，帮助我们理解测试活动的规划和管理；
以及需要特别关注的递增型迭代测试的关键活动之一——“静态测试”；这也是笔者认为的最高难度、最具影响力的敏捷测试活动。它将测试团队最早的引入产品开发环节，测试人员以第一用户的角度判断设计的有效性，此活动较早的暴露了设计缺陷、避免了团队对目标的不一致理解等，是测试活动中最有创造性价值的部分；
最后，笔者将谈谈测试活动中的测试计划和管理，即关于测试任务估计，测试活动计划，各个重要测试活动时间分配与安排的介绍。
然而，敏捷测试不是一蹴而就的，做到真正的敏捷，无论是从传统测试模式向敏捷测试的过渡，还是组建全新的团队都是需要循序渐进的，同时也需要团队成员的通力合作和不断的实践来完善敏捷测试的实践原则和方法。

敏捷团队

考虑到敏捷团队的组织结构，让我们以笔者亲身经历的项目为例来说明。笔者曾共事的整支产品开发团队被划分成 4 个相对独立的敏捷开发队伍，而每支队伍拥有相同配置的 7 名成员，他们分别具有不同的职能属性。如图 1 所示，每支敏捷队伍组成成员角色包括 1 名 UCD（User Centered Designer），主要负责产品的主要设计，其工作主要包括界面设计、用户的用例设计等等； 1 名 Visual Designer，主要负责产品界面的色彩搭配、控件的外观设计和 UCD 界面设计方案的初步实现和美化；1 名 Information Developer，主要负责产品中信息的编辑和重要文档的撰写工作； 3 名开发人员，主要负责产品的实现。和 1 名 QA，主要负责产品质量的保障。（更多的我们将 QA 定义为具有相比于测试人员拥有更多责任的一个职能，在本文中，为了简便起见，我们仍称之测试人员）。4 支敏捷的队伍拥有相同的 SCRUM MASTER STAKEHOLDER。通常会在同一时间进入一个迭代周期，制定各自的敏捷计划，并在同一时间退出，发布各自功能实现。而 4 支队伍的劳动果实被集成到一起就形成了可发布的产品了。

图 1. 敏捷开发团队的组织结构

因为敏捷团队中只有 1 名测试人员，因此需要一臂承担测试策略的制定，测试计划，测试脚本，测试用例设计以及测试的执行，帮助团队发现潜在问题，并协助解决问题的工作。敏捷团队的敏捷原则也是测试人员敏捷活动的规范，测试也需要拥有和团队的良好沟通，高度迭代的活动和不断的获得 STAKEHOLDER 的反馈。那团队的结构与敏捷本身有什么直接关系呢？与敏捷测试又有多少关联呢？

谈到这里，想起曾经有朋友向我咨询有关敏捷团队的某些职能的人力配备的问题。其实，笔者也无意论证 7 个人为什么是最佳组合，为什么不是 17 个，20 个人的组合。但是，敏捷原则告诉我们敏捷团队是高度协同、民主和平等的团队，为了让团队中每个人充分高效的工作。相同职能下的组员至多不好超过 3 名，最佳配置也是不同职能下配置 1 个人头。因此、在这样一个小型、平行的组织结构里，沟通更加易于建立，沟通复杂度也相对较低，相比 17、20 人的团队组织，沟通的代价也小很多。相反，很难想象在一个敏捷团队中会拥有诸多不同风格的执行者，决策者将是个怎样的混乱情况。

此外，经历过敏捷测试的体验，我们发现一个单一的敏捷团队最好保持较小的“尺寸”。这是因为拥有很多测试人员的敏捷团队通常不但需要更大的实际工作量来匹配庞大的机体而导致团队任务量更巨大，更复杂，失去自我管理的信心，而每个测试人员也将要花费大量精力和时间投入到内部沟通，和可能因为内部缺乏一致而导致的更加频繁的反复沟通中。

图片垂直居中的使用技巧

在曾经的淘宝UED 招聘中有这样一道题目：

“使用纯CSS实现未知尺寸的图片(但高宽都小于200px)在200px的正方形容器中水平和垂直居中。”

当然出题并不是随意，而是有其现实的原因，垂直居中是淘宝工作中最常遇到的一个问题，很有代表性。

题目的难点在于两点：

垂直居中；
图片是个置换元素，有些特殊的特性。
至于如何解决，下面是一个权衡的相对结构干净，CSS简单的解决方法：

.box {
/*非IE的主流浏览器识别的垂直居中的方法*/
display: table-cell;
vertical-align:middle;

/*设置水平居中*/
text-align:center;

/* 针对IE的Hack */
*display: block;
*font-size: 175px;/*约为高度的0.873，200*0.873 约为175*/
*font-family:Arial;/*防止非utf-8引起的hack失效问题，如gbk编码*/

width:200px;
height:200px;
border: 1px solid #eee;
}
.box img {
/*设置图片垂直居中*/
vertical-align:middle;
}

标准化设计解决方案 - 标记语言和样式手册短语元素

在引言和前面的章节中,已经稍微提到过语义标签的概念,使用标签为文件标识意义,而不是单纯的以标签设定显示效果.设计完全使用语义标签的网页是个不错的点子.然而我觉得这个目标太理想化了.当然,没有完全达到目标并不代表努力过程毫无价值.至少朝着这个目标努力很有价值.

在现实情况下,经常有必要加上非语义标签,以便实现特定的设计目标,主要是因为现在著名的浏览器都无法百分之百支持标准的缘故.有些CSS规则在部分浏览器中无法显示正确的效果,而这不幸的让我们在达成某些设计目标的过程中必须使用额外的标签.

有个重要的概念必须放在心上:那就是尽量尝试撰写语义化结构将能带来实际的好处.同时,对标准的支持虽然没有达到百分之百,但也已经越过临界点让我们现在就能使用符合网络标准的方法撰写网页.有些时候必须做点牺牲,但是坚持撰写越多的符合标准的标签,未来的工作就会越轻松.

显示效果 VS 结构标签

本章节将会讨论显示效果与结构标签的不同，更确切的说，是讨论使用< strong>替换< b>,以及使用< em>替换< i>的差异.在本章稍后,我们也会讨论几个其他短语元素以及它们在符合标准,结构化标签语法内的重要性.

你或许听说过某些人建议在需要粗体文字时要用< strong>替换< b>,但是他却没有进一步告诉你为什么需要这样的替换.在不知道"为什么"的情况下,实在很难期待其他网页设计者只因为听过需要这样做就改变他们对标签的使用习惯.

为什么< strong>和< em>比< b>和< i>好?

去掉< b>和< i>标签,替换成< strong>和< em>到底是有什么好处呢?其实这一切都是为了表达语义和结构,而不是为了只是显示效果,本书的所有示例也都努力遵循这个概念.

看看专家怎么说

首先,来看看W3C在HTML4.01的短语元素规范里是怎么叙述< strong>和< em>的(http://www.w3.org/TR/html4/struct/text.html#h-9.2.1):

短语元素能在文字片段之内加上结构信息,常见的短语元素意义如下:

< em> 代表强调

< strong> 代表更强烈的强调

所以在此讨论的是两种不同程度的强调.举例来说,就是一个单字或者短语,念的时候应该比较大声,音调较高,念的快些,或者是...嗯,就是比一般文字内容更强调.

W3C接着还叙述了下面这段内容:

短语元素的展示效果随着浏览器的不同,一般来说可视化浏览器应该以斜体显示< em>的文字内容,以粗体显示< strong>的文字内容.语音合成软件则能配合内容改变合成参数,像是音量,音调与速度等等.

啊哈!最后一句特别有意思,语音合成软件(之前我们称之为屏幕阅读器)将会正确处理必须强调的文字,这的确是件好事.

相对之下,< b>或是< i>只是单纯的显示效果标签.如果我们的目标是将结构与显示效果分离的话,使用< strong>和< em>就是正确的选择,单纯想要显示粗体,斜体文字的时候用css就好了.本章稍后会讨论更多例子.

接着看两个标识示例,帮助我们了解它们的差异.

方法A

your order number for future reference is: < b>6474-82071< /b>.

方法B

your order number for future reference is: < strong>6474-82071< /strong>.

又粗又美丽

这个情况是使用< strong>比< b>更适合的完美例子,我们打算让句子内的特定文字显示的更加重要.除了粗体显示订单编号以外,我们也希望屏幕阅读器也改变它们表达这段内容的方式:提升音量,改变音调或速度.方法B能够同时达到这两个目的.

< em>又如何?

同样的,以< em>取代< i>,能够同时表达重要性,而不只单纯的以斜体显示文字内容.来看看这两个例子:

方法A

It took me not one,but < i>three< /i> hours to shovel my driveway this morning.

方法B

It took me not one,but < em>three< /em> hours to shovel my driveway this morning.

强调语气

在前面的例子里(本书撰写时的真实情况),我的目的是使"three"这个字以强调语气表现,如同我大声念出这个字,视觉上,方法B在大多数浏览器里都会以斜体显示,而屏幕阅读器也会适当的调整音色,速度或音量.

只要粗体或斜体就好

必须注意的是,很多情况下只需要视觉上展示粗体,斜体的文字效果,换句话说,假设你的侧边栏里有一串链接列表,而你喜欢让所有链接用相同的效果显示:也就是粗体(图6-1)

图6-1.粗体链接放在侧边栏里的示例

除了视觉特色外,我们并不打算特别强调链接内容,这里就是以CSS改变链接外观显示效果的好地方,让他们不会被屏幕阅读器以及其他非可视化浏览器特别强调.

举例来说,你真的想让粗体链接被念得更快,更大声,音调更高吗?大概不会,这边的粗体完全只是显示效果.

font-weight相当于粗体

为了达到图6-1的显示效果,让我们假设链接栏放在id设为sidebar的< div>中,这样我们就能用CSS指定#sidebar之内的链接要以粗体显示:

#sidebar a{
font-weight:bold;
}

极度简单,让我觉得一提起就有些可笑,但是这的确是个帮助分离结构与显示效果的好方法.

那是粗体!
同样的,在思考斜体文字的时候也能应用类似的想法,在你不想强调的内容,只单纯想以斜体显示文字时,你能再度使用font-style属性通过CSS处理这些状况

让我们使用相同的#sidebar作为示例,举例来说如果你想使#sidebar里的所有链接显示成斜体,那么可以这样写:

#sidebar a{
font-style:italic;
}

又是个简单至极的概念,但是在结构化标记语法的领域里,我觉得讨论这些情况十分重要--使用CSS处理央视,代替显示效果标签的状况.有些时候最简单的解决方法也最容易被忽略.

共用粗体与斜体

在打算同时用粗体和斜体显示文字内容的时候,我觉得必须先思考一个问题,你打算传达什么程度的强调?根据这个问题的答案,我会选择适当的标签:< em>(强调)或< strong>(更强烈的强调),然后以选择的标签标记文字.

举例来说,以下面的例子来说,我原本打算让"fun"同时以粗体,斜体显示,最后我选择用< em>来强调这个字.

Building sites with web standards can be < em>fun< /em>!

大多数浏览器只会以斜体来显示这个字,要同时使用粗体和斜体,我们有几种选择.哦,我真的希望你同意上面这句话.

普通的< span>

方法之一,是以普通的< span>包在"fun"之外,并且指定CSS规则将所有< em>之内的< span>以粗体显示.标记语法看起来像这样:

Building sites with web standards can be < em>< span>fun< /span>< /em>!

而CSS看起来则像这样:

em span{
font-weight:bold;
}

明显的语义部分并不好,因为我们加上了额外的标签,但是这个方法人人仍然有用.

以class强调

方法则是为< em>标签指定一个class,并且以CSS加上粗体效果,标记语法看起来像这样:

Building sites with web standards can be < em class="bold">fun< /em>!

而CSS看起来则像这样:

em.bold{
font-weight:bold;
}

使用< em>就能达成斜体效果(同时在语义上强调了文字内容),而为它加上bold class则会使< em>之内的文字以粗体显示.

类似的方法也能用来修饰< strong>.这时我们能在加重强调某段文字的时候,设计italic class加上斜体效果,再配上< strong>原来就有的粗体效果.

标记语言看起来像这样:

Building sites with web standards can be < strong class="italic">fun< /strong>!

而CSS则是这样:

strong.italic{
font-style:italic;
}

概述

我想讨论这个主题十分必要,因此这是本书核心主题之一的良好范例:将内容与展示效果分开十分重要,很有好处:而将< b>与< i>标签换成结构上对等的标签(强调内容的时候)是个辅助达成这类分离目标的简单方法.

因此,下次当你听到某人提到"没错,你永远应该使用< strong>替换< b>"的时候,你就有足够的理由去支持这个论点了.

大多数情况下,很适合以< strong>或< em>传达强调语气,而当你只是要追求视觉上的粗体,斜体效果时,就用CSS吧.

技巧延伸

本章到目前为止,都把焦点集中在< strong>和< em>上,这两者只是W3C所谓的"短语元素"的一部分,在这本分我们来多看一些短语元素以及他们和标准之间的关系.

短语元素

除了< strong>和< em>之外,W3C HTML 4.01规范里完整的短语元素列表还包括:

< cite>: 包含其他引用,参考来源的资讯
< dfn>: 代表这是名词的定义示例
< code>: 代表一段代码
< samp>: 代表一段程序,script的输出示范
< kbd>: 代表要使用者输入的文字
< var>: 代表程序的变量
< abbr>: 代表缩写名词(像WWW,HTML,URL,Mass.等)
< acronym>: 代表略称(像WAC,radar等)

让我们深入地看几个标签,首先从< cite>开始:

< cite>的设计
< cite>是个值得讨论的有趣元素,在替换掉单纯指定显示效果的< i>标签时尤为重要.< cite>的用途是参照引用来源:标识作者或出版物.历史上来说,设计者或许会用< i>把书籍标题显示成斜体,但是在本章稍早的地方我们学到了CSS是指定显示效果的最佳工具.

你或许会建议用< em>表示出版物的标题,但是在引用书籍或其他出版物的时候,我们并不打算去强调,也就是将书籍标题显示成斜体(在印刷界也常使用下划线,但是这明显会和链接混淆).

于是就出现了为这个工作量身打造的< cite>标签,大多数浏览器甚至预设会以斜体显示< cite>标签中的内容.而我们也能加上CSS规则达成相同的目的.

规范
W3C的< cite>标签规范有点简略,在HTML 4.01规范中只简单提了(www.w3.org/TR/html4/struct/text.html#h-9.2.1):

< cite>: 包含其他引用,参考来源的资讯

这差不多是我们能掌握的说法了,但是我们也不清楚到底哪类资料可以放在< cite>中,但是从"来源"来看,我们至少可以把作者,出版物放进去.

让我们看看< cite>的用法:

The novel, < cite>The Scarlet Letter< /cite> is set in Puritan Boston and like this book, was written in Salem, Massachusetts

使用了< cite>标签之后,标题The Scarlet Letter 在大多数浏览器中都显示成斜体,我们将加上下面这段十分简单的CSS规则,以便浏览器在没有预设的时候也显示出正确的效果.

cite {
font-style: italic;
}

回顾一下,我们把标题书籍,其他出版物标题的< i>标签替换成< cite>,在大多数浏览器中,仍然能得到斜体显示效果,也再度使页面内容变得结构化语义化.当然这个结构一样能发挥CSS,让我们一起来瞧一瞧.

改变< cite>的样式

在我们讨论以结构,语义构建页面内容的过程中,我们也同样让页面变得更容易用CSS指定样式(以及修改样式).以< cite>标签为例,如果我们固定使用这个标签标记出版物的话,我们就能完全掌握现实的样式,在任何需要的时候都能轻易的修改.

假设所制作的整个网站,过程中使用了< cite>标签标记书籍参考资料以及出版物标题,我们加上全局CSS规则用斜体显示所有的< cite>元素,但是在几个月之后,我们希望不仅以斜体显示书籍出版无标题,还要用粗体,红色文字灰色背景.

当然,可以用几个CSS规则快速完成这项任务,立刻改变先前以< cite>标记的所有参考资料标题,如果使用< i>或者< em>的话就没办法明确指明对象了.

cite {
font-style: italic;
font-weight: bold;
color: red;
background-color: #ddd;
}

图6-2使大多数浏览器的显示效果,而这是另一个先写结构化标记的好例子,让你稍后能轻易修改全站的设计风格.

图6-2. 以< cite>标记,使用CSS样式的效果

发挥结构的潜力

除了容易使用样式之外,结构化标记也便于服务器端软件进行处理,带来有趣的应用.

举例来说,易用性提倡者Mark pilgrim在他个人网站"Dive into mark"(http://www.diveintomark.com/)里使用了不少< cite>标签,由于在网志内使用< cite>标签标记引用的任何出版物,因此Mark能够撰写程序,解析所有文章建立资料库吗然后根据参考到的引用来源进行分类(http://www.diveintomark.com/archives/citations/)

下图6-3是搜索我自己的结果,在Mark的网志中能找到两篇相关的文章,这全是靠< cite>标注"Dan Cederholm"完成的.

图6-3 Mark Pilgrim在"Dive into mark"制作的"posts by citation"结果(http://www.diveintomark.org/archives/citations/dan_cederholm/)

< abbr>和< acronym>

我还想提出两个短语元素,就是< abbr>(缩写名词)和< acronym>(略称).使用这些标签能够为缩写名词提供定义,让所有使用者看懂内容,提升网页的易用性.

让我们从新看看W3C在HTML4.01规范内定义的< abbr>和< acronym>用途:

< abbr> 代表缩写名词(像WWW,HTTP,URL,Mass.等)
< acronym> 代表略称(像WAC,radar等)

配合适当的title属性是这些元素能帮助不了解特定名词的使用者,举例来说,在标识"XHTML"缩写的时候,我们能这样使用< abbr>标签:

< abbr title="eXtensible HyperText Markup Language">XHTML< /abbr>

在这里使用< abbr>会使屏幕阅读器拼出缩写内容(X-H-T-M-L),而不是念出完整内容,相对的,使用< acronym>的话则会让他念出完整内容,而不是缩写.

使用< acronym>标签的示例如下:

< acronym title="North Atlantic Treaty Organization">NATO< /acronym>

我们也能使用两条听觉CSS规则,再次强调这些差异:

abbr {
speak:spell-out;
}
acronym {
speak:normal;
}

听觉样式让作者能特别为屏幕阅读器指定朗读方式,这能修改页面的听觉表达方式,引导标记结构,改变音调,音色等,让页面朗读的效果与视觉效果更一致.

定义一次

许多人都建议只定义一次在页面内反复出现的缩写,略称,他们认为每次名词出

现时重复定义太浪费空间了,而最好只在首次出现的时候加上title属性,我认为这么做有些道理,虽然当使用者被导引到页面特定段落时,可能因为看不到页首展开缩写,略称,从而无法从定义中获利.

利用你的判断力,决定何时(以及要多频繁)定义放在< abbr>和< acronym>内的名词吧.

显示效果

要在视觉上吸引读者,有些浏览器预设会在< abbr>和< acronym>下面加上1像素的点状底部边线,引诱使用者将鼠标移到缩写名词,略称上面,当鼠标移到上面后,浏览器就会以"工具提示"的方式显示title属性提供的定义内容.

对那些不预设显示点状底部边线的浏览器来说,可以通过定义CSS达到同样的效果.

abbr, acronym {
border-bottom: 1px dotted;
cursor: help;
}

我们也加上额外的规则,把光标转成"求助"(大多数浏览器都会支持),帮助使用者看出这不是可以点选的链接,而是以"工具提示"显示的定义内容(Mark Newhouse,"Real World Style:CSS Help",http://realworldstyle.com/css_help.html).

图6-4就是浏览器的显示效果,将"XHTML"扩展成定义文字,以及点状底部边线,求助光标:

图6-4.一般浏览器显示< abbr>的示例

兼容性问题

值得一提的是,在本书撰写的时候,windows版的Internet Explorer还不支持为< abbr>标签指定样式,显示工具提示. IE/Win支持< acronym>标签,这是为了鼓励某些设计者只使用< acronym>处理缩写名词与略称.

这么做或许很有吸引力,但是为了解决现实问题而使用错误的元素并不是件好事,对这个特定问题来说,我偏好根据规范表示名词,让正确支持的浏览器处理< abbr>标签的样式.让我们很快地看看几个还没提到的短语元素.

< code>

< code>元素的设计目的是在XHTML页面内展示代码示例,举例来说,当你想分享某段CSS时,你可以这样写:

< code>
#content {
width: 80%;
padding: 20px;
background: blue;
}
< /code>

一般来说,可视化浏览器会以定宽serif字体显示< code>标签中的内容.当然,我们也能加上CSS规则,指定我们喜欢的显示方式.

code {
font-family: Courier, serif;
color: red;
}

如此一来,< code>的内容就会变成红色的Courier字体了.

< samp>

< samp>元素是用来标识程序与script的示例输出的,举例来说,如果我想讨论正在编写的Perl script输出结果,我可能会标集成这样:

< p>When the script has executed, at the command line you will see the message < samp>script was successful!< /samp>.< /p>

这边我以< samp>把script的输出示例围起来,同时我们也能以CSS规则为程序输出示例设定独特的样式,就像刚才为< code>做的一样.

< var>

与< samp>相关的,< var>是用来标记程序的变量和引用用的,举例来说,如果我们正在讨论XSLT样式表,那么我能写下:

< p>I'm going to pass the parameter < var>lastUpdated< /var> to my main.xsl file.< /p>

许多浏览器会以斜体显示< var>标签的内容,但是你可以写一条简单的规则去掉预设值,如果你不喜欢斜体的话.我们能用CSS的font-style属性改变显示效果:

var {
font-style: normal;
font-family: Courier, serif;
color: purple;
}

最后让我们看看< kbd>元素,完成短语元素的部分.

< kbd>

< kbd>元素可以用来标记使用者要输入的文字,举例来说,如果我正在解释如何使用刚才指定的accesskey把光标切换到搜索框内,我可能会这样写:

< p>To quickly change focus to the search input field, Mac users type < kbd>Command+9< /kbd>.< /p>

你大概猜得到我接下去要说什么了,没错,只要使用简单的CSS规则,你就能调整所有的< kbd>元素的样式,与其他短语元素一样.

结论

回顾一下在这章中看过的内容,首先探讨< strong>和< em>优于同等显示效果的< b>和< i>的原因,同时也研究了如何单纯设定粗体或斜体显示效果,CSS是正确的方法.

也讨论了其他的短语元素,以< cite>标记人物,出版物开始,并证明了结构化标记语法对显示效果,资料解析的好处.

并示范了如何以适当的元件标记缩写名词,略称,提升网页的易用性,同时以额外的CSS展示,语音规则强化定义内容.最后则看到剩下的短语元素,每个元素都具备一般文字不同的预设样式,但是我们也能快速地为单一页面或者整个网站轻易的设计简单的CSS规则,为这些元素指定想要的显示样式.

WEB前端开发经验总结 Ⅰ

WEB标准是什么？

呵呵，说是WEB标准，不过我这里主要是对XHTML1.1 和 CSS2.1的一些经验总结。因为WEB含盖的内容实在是太多了，“WEB标准”是一系列标准的总称，包括HTML4.0、XHTML1.1、CSS2.1、XML1.0、RSS2.0、ECMAScript1.1、DOM1.0等等。所以这里要跟大家指出来一下，WEB标准不是我们所说的DIV+CSS。

刚刚上面提到了——DIV+CSS，呵呵，这里要说明下，这样说其实是不正确的。DIV+CSS准确的说法（个人的理解）应该是：采用W3C推荐的WEB标准中的XHTML1.1结合CSS2.0样式表制作页面的方法，DIV应该指的是XHTML标签，而CSS显示是指的CSS样式表了。

采用WEB标准开发的好处

那么W3C为什么会推荐这样的页面制作方法呢？下面我们就简单的看看采用WEB标准开发（个人理解的）相对以前TABLE布局的优势有哪些？

1、节约运营成本，省钱啊！

呵呵，能帮你省钱的东西，你会不会有兴趣？当然是十分的有兴趣了。看看我们的WEB标准制作方法是如何做到的？

采用WEB标准制作，我们可以做到表现很形式的分离，我们用XHTML来表现（数据），用CSS来控制（页面元素呈现的）形式。写的好的页面，XHTML代码中基本上都是用户要看的数据，还其他修饰性的东西，全部由我们的CSS来控制。这样一来我们的（XHTML）页面的体积就大大减小了，这样你在带宽上的费用就会大家降低了，这个怎么降低的，你可以想象一下，YAHOO的首页小1K，100W个人一起访问，那么带宽节约了多少？而且可以更充分的利用带宽。

而我们的CSS控制了，所有的页面元素的样式，现在想改网站的整体风格，你只需要花几分钟修改一下一个CSS文件，就可以轻松搞定了。维护的成本也下来了，省了不少钱了吧？还有，你开这个页面的速度会快很多啊，一个让你等半分钟的页面，除非里面的信息对你很有用，不然我们大家基本都没有太多的时间去用来等待的。

2、对用户友好更友好，且有机会获得更多的用户

现在来说说用户友好。首先我想把我们的用户来分下类。

第一类：普通用户（每个访问我们网站的人）；
第二类：搜索引擎；

采用WEB标准开发的页面，结构清晰，页面体积小，浏览器兼容性好。普通用户访问的时候，页面打开速度快，而且不管用户使用那种浏览器，都能够正常访问（显示）页面，且页面的结构清晰，要找的数据可以很方便的浏览到。

而对搜索引擎来说，一个好的采用WEB标准开发的页面，都是做过SEO优化的，它访问起来很友好，很容易理解你的页面中哪里是标题（H1~H6标签），哪里是段落（p标签），哪里是段落里要强调的内容（strong标签）等，它可以很容易的分析出来。而一个SEO好的站点，大家都知道，被搜索引擎收录的机会更多，这个也意味着您的网站会被更多的普通用户访问到，给你的站点带来更多的用户。

一个能帮我们省下大笔费用，提高工作效率。同时又能够提高页面浏览速度，对用户友好，甚至能够不花钱宣传，就能给你带来更多用户的技术。你说你会不会去使用它？呵呵，这个也正式我们的W3C推荐使用WEB标准开放网站的原因啊。而这个技术也得到了我们广大用户的认可，所以您现在需要学习WEB标准啊。^-^!

呵呵，温习完了基础课程，现在正式开始讲XHTML和CSS的技巧了。

合理的布局

有朋友会开始问了，怎么一开始就开始讲合理的布局了呢?呵呵,前面我们提到了一些知识点——“结构清晰、SEO优化、页面体积小、XHTML代码中基本上都是用户要看的数据”。这些东西，都是我们做了合理布局的结果。而且我个人觉得，我们采用WEB标准制作的一切都是从这个知识点开始的，所以我这里就先来说这个话题。

那么大家又会开始问，怎样的一个页面，才算是合理的布局的呢？恩，这个问题问题问得好，也是我们大家刚开始学用WEB标准的问得最多的问题之一，我也曾经常被这个问题所困扰，这里就说说我对合理布局的一些理解。

在开始讲合理布局的页面要达到的要素前，我们还是用个实例来讲解会更直观些。先来看看这个图片：

http://www.yaohaixiao.com/samples/myblog/index.htm

不错，这个是一个文章详细页，没有左右两栏布局，不过这里我重点要讲的是合理的布局，在稍后的文章中我会详细的介绍浮动元素。好，回到刚才的话题，大家看到了这个页面了。

我这里先把代码写给大家看看（省略了部分代码）：

< html xmlns="http://www.w3.org/1999/xhtml">
< head>
< meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
< title>Ajax标签导航实例详解< /title>
< link href="css/article.css" rel="stylesheet" type="text/css" media="all" />

< /head>
< body>

ARTICLES

TOPICS

ABOUT

CONTACT

GESTBOOK

FEED

< h2>Ajax标签导航实例详解< /h2>

作者/程序设计：yaohaixiao 来源：yaohaixiao.com 发布时间：2008年4月28日

< h3>代码篇< /h3>

之前整理发表了《XMLHTTPRequest的属性和方法简介》,它Ajax要使用的核心的技术之一，现在就来实际运用它。这个Ajax标签导航，是我很久前就写的一个脚本，很实用的（还被很多网站收录了哦），现在拿它来做实例讲解吧！当然个人能力有限，有什么不对的地方还请多包含!

演示地址：http://www.yaohaixiao.com/code/ajaxtab/index.htm

效果大家看到了，核心功能有：

1、将当前选中标签以特殊的样式显示

2、将异步加载的页面信息显示到指定的DOM节点中

我们来看看处理脚本的代码吧：

程序代码：ajaxtab.js

id="news" - news就是我们的导航标签的ID；

id="newsCnt" - newsCnt就是我们要写入信息的目标DOM节点；

class="first" - first当前(第一个)标签的样式；

id="news-0" - news-0 通过”-“分开，我们就分别可以得到news(导航标签ID)，0（标签[li]在导航标签中的索引值）

网站重构 - 超链接

- 标签间的分割线

我罗列的这些东西，相信大家开始看出了些头绪了，呵呵，不过别急！在我们看处理的脚本之前，先让我们来看看导航标签的样式，主要是看看我们对分割线的处理(一点CSS处理的技巧)。

本来想偷个懒，让大家看我上边说的那篇文章，想想也就是Ctrl+C&Ctrl+V,都贴出来吧！呵呵！！！

不过还没有完，最后要说的就是innerHTML这个特性，这里我们还要感谢微软啊，innerHTML就是它的专利，我们就是用它来改变指定DOM内的HTML字符串的，而不用刷新页面。详细的信息大家还是google一下吧，我也要休息下啊！！喝口茶先！！^-^！

以上讲了这么多，我们最后来看看，我们这个ajax标签导航都用到了那些技术吧：

XHTML

Javascript

XMLHttpRequest对象

innerHTML

还有XML，我们这个例子没有涉及到。东西虽小，包含的（web前端开发）知识可是都用到了啊，我把我会的点东西都端出来了（要失业了），呵呵！

当然我很喜欢跟大家多交流，以后有时间，我们在来谈谈CSS的HACKS技巧，Javascript DOM编程等等的，今天就收工了，谢谢捧场先！！！

< /body>
< /html>

看出来什么没有？（代码是很多，呵呵！）可能大家已经发现，整个页面里基本上都是用户要看的数据，其中只包含了很少（必要）的布局(XHTML)标签（请允许我这么说）。整个页面基本都是由最基础的h1~h6、p、ul、ol、li、form、div标签来实现的。

说到这里就要讲到我在前面提到的“结构清晰、SEO优化、页面体积小、XHTML代码中基本上都是用户要看的数据”，看看我的这个例子做到了没有？

结构清晰--也就是我们常说的，XHTML标签要结构化（语意化）。

什么叫结构化？

由于个人认为这个知识点是十分重要的，所以请允许我在这里多罗嗦几句，我们采用WEB标准的方法制作页面的优势就体现在页面结构清晰。我们以前用table布局的时候，我们的表现（数据）和形式（布局样式）是混在一起的，有很多冗余的数据混杂在一起，而大家再看看我上面给大家展示的代码，很明显，结构十分清晰。

呵呵，说了半天，还是没有说什么是结构化，什么才是结构清晰啊？不要急。还记得我刚才提到的那几个标签吗？

h1~h6--如果你要显示的数据是作为标题显示的时候，就用这些标签，因为这个标签的意思就是说，这个是一个标题，不仅我们的用户很容易理解h-head的英文字母缩写，我们的另外一个用户搜索引擎也可以很容易理解它。呵呵，看到了吧，一个充分结构化的页面，对用户是十分友好的。
p--Paragraph（段落）
ul--unorglized list(无序的列表)
ol--orglized list(有序的列表)
li--list item(列表项)
form--表单
div--division(区域)

我这么一写，大家估计开始明白了，原来XHTML标签是有着自己的意义的（至于其他的标签的语意义，大家可以自己到W3C看看它的解释，也可以查看语义化你的HTML标签和属性），所以我们讲要语意化的意思，就是用合理的标签来显示数据，比如前面提到的，是标题，就应该用h1~h6标签，如果是一个段落的介绍文字，那么就应该使用p标签，如果是显示的一个没有顺序的列表，就应该用ul标签，如此...

所以看这个例子里

Ajax标签导航实例详解

这么写就是很合理的，h2标签就说明这里是个标题。而这么写：
复制内容到剪贴板代码:
.title{
font-size:18px;
...
}

Ajax标签导航实例详解

虽然你用了strong来强调说明这部分文字，但是还是没有h2标签来的直接明了。

还有这么写

Ajax标签导航实例详解

也不是我们推荐的，可以不用嵌套层的地方，我们尽量不要去过多的嵌套层，减少嵌套会让我们的浏览器解析起来会更容易，速度更快。

所我们使用WEB标准开发页面，绝对不是单纯的把以前的table换成DIV就OK了。而采用标准制作页面，也不意味着我们就不使用table。只要把握我刚才说的原则，使用合理的标签显示相应特征的数据。

其实我们的table标签是一个很好的用来显示二维数据的标签，而table标签也确实是设计出来用来显示数据的，而不是用来布局的，只是我们当时的设计师们都用table标签来布局了。关于table标签的使用，大家也可以去看看上面提供那篇参考文章《语义化你的HTML标签和属性》。

上面，我们讲到了要充分的语意化，其中我们提到了嵌套的问题，这个也是我们做到结构化的一个重要部分。个人认为一个最基本的原则就是尽量减少嵌套。至于为什么这么做，我刚才也给大家做了一个简单的介绍，结构清晰，浏览器解析快。其实结构清晰（够简单，嵌套少），对我们的搜索引擎同样是做起到了SEO的效果。怎么讲？大家想想，嵌套N多层，跟我们以前使用table设计时，table套table的区别就不大了，而那种含有大量冗余信息的页面，搜索引擎解析的时候也很费力啊。所以我们现在有了WEB标准，就不要再去犯以前的错误了。

说到SEO优化，让我们来看看我的例子中对LOGO的处理，XHTML代码如下：

< div id="topbar">
< h1>海啸的地盘--享受生活，享受每一天！< /h1>

< form name="frmsearch" id="frmsearch" action="" method="post">
站内搜索：

< input type="text" name="keyword" id="keyword" value="请输入搜索关键字" maxlength="60" />
< input type="reset" name="btnsearch" id="btnsearch" value="开始搜索" />
< /form>

呵呵，当大家用浏览器浏览时，可能会以为这里是一个标签吧？其实我这里做了一个简单的SEO优化（当然只是我个人比较喜欢这个方法，可能有朋友跟我有不同观点。），做了关键字的优化。

对SEO有些了解的朋友都知道，搜索引擎搜索关键字的时候，是先对XHTML标签里的< meta>标签的keyword部分的文字，然后就是标题里的文字，接着就是正文中的h1~h6标签，然后是strong标签中的文字。而我们网站的名称，毫无疑问的会作为关键字的。

所以我这里用h1标签模拟了< img />标签的效果，将网站名称这个关键字在页面里出现了一次，而且是以正文中搜索引擎分析的优先级最好的h1标签，以说明该内容在页面中的关键性。具体的实现代码这里就直接写出来：

#topbar h1{
float:left;
width:220px;
height:58px;
line-height:58px;
overflow:hidden;
font-size:18px;
color:#060;
text-indent:-999px;
background-image:url(../img/logo.png);
}
#topbar h1 a:link,
#topbar h1 a:visited,
#topbar h1 a:hover{
display:block;
width:220px;
height:58px;
line-height:58px;
overflow:hidden;
background-color:transparent;
}
< h1>海啸的地盘--享受生活，享受每一天！< /h1>

看了代码，我想大家也很明白了，我们这里利用了text-indent、overflow:hidden;属性以及display:block。我们把LOGO图片作为h1标签的背景，然后用text-indent设置一个超大的负值，然后结合overflow:hidden;属性，让h1标签里面的字都超出到它的布局范围内，overflow:hidden后就在h1标签里看不到文字了，而LOGO图片背景显示出来了。

接着一个关键就是将a标签模拟成图片链接的效果。我们首先将a标签display属性设置为block,强制将a标签显示成块级元素（块级元素和行内元素的知识我们下面马上给大家介绍），给它设置布局大小，这样我们a标签里就是一个块了，而这个块刚好是我们背景logo图片的大小，让你点击的时候感觉是点的一个图片链接，而我们的a标签是嵌套在h1标签里的，继承了H1的text-indent属性，里面的文字超出了a标签的布局范围，没有显示出来，而显示了图片（其实是背景图）。呵呵，图片链接就这样被我们模拟出来了，不过为了更像图片链接，我们又给a标签添加了title属性，来模仿img标签的alt属性，呵呵，模拟得够像吧。

上面介绍了，一个技巧，其实主要是利用我们的CSS控制来实现的，不过我这里还不打算介绍CSS的技巧，接着我们的结构化的话题说下去。看看，其实在制作一个结构化充分的页面的时候，我们同时也在做SEO的优化。

结构，结构，刚才我提到了标签有块级元素和行内元素之分的，要是不理解好这两个概念，我们也不会很好的了解怎么合理的结构化页面，现在就来介绍它们：

块级元素

块级元素生成一个元素框，（默认地）它会填充其父级元素的内容，旁边不能有其他元素。换句话说，他在元素框之前和之后生成了“分隔”符。我们最熟悉的HTML元素是p和div.

行内元素

行内元素在一个文本行内生成元素框，而不会打断这行文本。行内元素最好的例子就是XHTML中的a元素。strong和em也属于行内元素。这些元素不会在它本身之前或之后生成“分隔符”，所以可以出现在另一个元素的内容中，而不会破坏其显示。

注意，尽管“块”和“行内”这两个词与HTML和XHTML中的块级和行内元素有很多共同点，但也存在一个重要的差别。在HTML和XHTML中，块级元素不能继承自行内元素（即不能嵌套在行内元素中）。但是CSS中，对于显示角色如何嵌套不存在任何限制。

恩，还是不能把CSS跟XHTML完全的分开谈，没办法。现在大家了解了什么是块级元素和什么是行内元素了吧。还是回过头来接着说我们的结构化吧，以上讲了这么多，我都是在讲XHTML标签要结构化，所以基本跟CSS关系不大，那么我们下面看看我写的这个页面的代码在没有CSS的情况想，是否结构清晰吧：

看看，页面是不是依旧很清晰，很容易看出，哪里是标题，哪里是导航，哪里是搜索表单？呵呵，其实我这么给大家看的页面，跟我们的搜索引擎查看页面的结构很接近了，到这里大家可能体会到一些搜索引擎友好的意思了吧？

其实让我们看看这个页面的DOM数状图，可能我们对一个简洁合理的结构化布局的页面有更直观的了解。

看看，是不是做到了我说的：XHTML标签充分的语意化、尽量少的嵌套、页面里基本只显示用户需要看的数据、对搜索引擎友好（没有CSS支持时，浏览页面时同样清晰，层次分明，十分容易查看的数据。），已做了基本的SEO优化

呵呵，说到这里我才回答了“怎样的一个页面才算是合理的布局的呢？”，做到上面4点，我个人觉得这个页面就已经做到了合理布局。而至于说要通过W3C的XHTML语法验证，只是很基础的开始。一个通过验证的页面和一个合理布局的页面是两码事的。

这里我再罗嗦一下，我一直都在说的是个人认为如何才算是一个合理布局的页面？要达到什么要求才能算合理布局？因为只有理解了这个，之后的CSS的技巧（浏览器的兼容处理等）都是围绕着让XHTML页面布局更合理来进行的。而不是单纯做到各个浏览器下都显示正常（一致）。所以请记住在开发时做到：

XHTML标签充分的语意化
尽量少的嵌套
页面里基本只显示用户需要看的数据（我们用CSS直接控制用户需要看的数据的显示的样式）
页面对搜索引擎友好（没有CSS支持时，浏览页面时同样清晰，层次分明，十分容易查看数据。），已做了基本的SEO优化
今天就谈到这里吧，下面我们会接着讨论CSS的处理技巧。

转自：http://www.cnblogs.com/junzhongxu/archive/2008/07/08/1237993.html

IE6实现min-width

首先我们知道这个效果应该是一个老话题了。
今天整理文件的时候，发现自己以前的一些布局的解决方法躺在文件夹里很长时间了，翻翻老底吧
需要说明的是有幸也见到过CSSPLAY的老工程师站长对这个效果的实现，而且肯定是很早就给出来了。

闲话少说，上源码：

触发并利用IE6-layout的怪异特性，css实现：