HTML5 发展中的命名约定和微格式

  2004年5月29日,在我退休的博客和所有的大线个设计师的网站,看看他们为公共页面元素使用的约定,如标题和横幅,导航,内容和页脚(那时候的结果 )。

  这几乎不是科学研究,但在那年6月,我跟进了Eric Meyer的一些意见 ,并出版了一套命名约定。当我发现一个网站已经通过了这些命名约定时,我总是很高兴,我任然每一天都在用,甚至超过4年后的每一天。

  id和class属性名称必须反映元素的功能或内容,而不是反映了介绍。 所以出了header并再来branding; 出了footer并再取而代之的是site-info。

  这些约定为我服务的很好,我所做的,几乎没有改变他们的核心。毫无疑问,他们都使我的工作速度更快,更一致和更有益。 他们使建立产品更容易,以及更容易用我的思维方式培养与我共事的人 。命名约定起作用。

  让我们面对它,微格式,如hCard,hCalendar,hAtom和其他草案带来了如此多的属性值,以至于常常没有必要考虑哪一个构建文件或提供了哪一个约束CSS模式的挂钩这些更多的属性值。现在我使用微格式达到这种程度,以至于我甚至不使用class属性(微格式伴随的class属性除外)发展整个页面。

  在难得的场合,我需要添加一个新元素(假设布局目的的一个划分)我首先想到的是延伸微格式中已经存在的。我将给您举个使用hAtom模式的例子:

  如果您正在保持微格式的优势,你已经注意到, entry-related不是 hAtom 模式的一部分,但在这种的情况下,我绝对地,明确地不得不有一个额外的因素,如何组成一个像related-sidelinks这样的属性值呢?

  在这个章节的开始,我应该坦率的说,此时此刻,我对HTML5的关注不能较少。不过,这不是问题的关键。HTML5引入了一些潜在的非常有用的新元素,例如:

  由内容组成的页面的一部分,与aside 元素相关的内容无关,并可以被认为是从内容中分离出来的。 这些部分,经常表现为印刷排版侧边栏。

  但现在我可以使用id和class属性值来帮助我熟悉的HTML5,带着我的文档朝它更进一步。

  我觉得对我来说是一个合乎逻辑的下一步。因此,看看这个示范文件,我已经采取了HTML5元素为我的命名约定的基础。除了我刚才提到的,留意,我已经确定了分类和导航的方式(nav ),用colgroup和col构建字段 ,把一个无序列表转换为网格,用datagrid。

  如果今天我可以实现一个愿望,这个愿望将是所有的CSS框架的开发将采取相同的命名约定(而且也广泛地嵌入微格式),以便初学意义丰富的标记和CSS的人们有个正确的出发点,使用的更有意义,更合逻辑,而不是表象的id和class属性。

相关阅读