今天完成的事:

修改了几个布局没对齐的元素，完成了任务8、9，开始任务10的制作，学习CSS制作流程图。

明天计划的事：

制作头部之后的流程图，制作主体表单，用css+div模拟原生表单并保证元素功能完好。

遇到的问题：

对Web语义化不太理解，命名布局不够规范，没有让自己代码增加易读性。

收获：

对语义化了解了一下

关于语义

语义是对标记与符号之间的关系，以及它们的含义的研究。在语言学中，这主要是对语言中的符号（如单词，短语，或声音）意义的研究。在前端web开发的上下文中，语义大多是与元素，属性，和属性值（包括像Microdata之类的扩展）的一致认同意义相关。这些认同意义通常在规范中被定义概念，它们可以帮助程序员（也就是人类）更好的理解网站中信息的不同方面。但是，即使是规范化以后，元素，属性，和属性值的语义还是受制于开发者对其的适应与吸收。这可能会导致后续对正式认同语义的修改（这也是一个HTML 设计原则）

区别不同类型的HTML语义

编写“语义HTML”原则是现代专业前端开发的基础之一。大部分语义关于存在的本质属性或是期望的内容（例如h1element,langattribute,emailvalue of thetypeattribute, Microdata）。

然而，不是所有的语义都要源于内容。Class名不能是“非语义”（unsemantic）的。无论使用什么名字，都要有意义、有目的。Class名的语义可以和那些HTML元素不一样。 我们可以统一利用“全局”的语义命名HTML元素、某些HTML属性、微数据等等，以免和“本地”的网站/应用专属的常常包含在属性值内的语义相混淆，比如theclassattribute。

• 内容层语义已经担任HTML元素和其他属性。
• 类名很少或根本没有赋予语义有用的信息给计算机或浏览，除非它的一小部分（计算机可读）约定的名字 - 微格式的部分。
• 类名称的主要目的是为CSS和JavaScript设置钩子。 如果你不需要给你的web文档添加演示和行为，那么你可能不需要在你的HTML文件中使用classes。 
• 类名应该提供有用的信息给开发商。当你读一个DOM代码段的时候，有助于了解一个特定的类的名字是要干什么，特别是在前期与多个开发团队，包括非HTML组件工作的人。

内容无关的类名

另一种可选的方法是在设计中从重复结构和功能模式中派生类名的语义。大多数可重用的组件都带有与内容无关的类名。

我们不应该害怕在清晰明确的层级间建立联系，而不是让类名严格地反映特定的内容。这样做不会让类变得“没有语义”，它仅仅意味着它们的语义不是从内容中派生出来的。如果附加的HTML元素帮助创建鲁棒性强，柔软度大，可重用的组件，我们就不要害怕把这些元素包含进来。这样做也不会让HTML变得没有语义，它仅仅意味着你使用了刚好超过标记内容最小所需的元素。