- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 07 Mar 2007 19:13:08 -0500
Elliotte Harold wrote: > fantasai wrote: > >> This element would be extremely useful to someone with a screen reader. >> It would create an implied UA hook for "skip to main content", for one. >> With multiple postings within a page, it would create a reliable way of >> "skimming" the main sections (by reading the first bit of content on each >> posting), even when there are no headers or when the postings themselves >> have internal sectioning and headers (especially if those are >> inconsistent). > > But how would it do this when <section> or <section role='article'> > would not? I find that anything I use that resembles the semantics of an <article> usually has a class name attached to it for styling purposes, especially in relation to fixed headers, footers and navigational bars, so <section> alone wouldn't do. Would <section role="article"> do? Well, first of all, what would it do that a predefined class name wouldn't, since from a markup point of view, the only difference is the name of the attribute? Namespaces? Nope, in XHTML you have to use |xmlns| to define those, so implementing |role| with namespaces means creating a namespacing standard for HTML. Good luck on that. Are semantics the difference? Well, |role| was designed to be purely semantic. However, when you're styling an element, are you seriously going to include a |class| on each element with a particular role, or are you going to use selectors to style all elements with that |role|? In the latter scenario, the selector may be just slightly more complicated, but you only need to write it once and you save on markup. Therefore, roles end up being functionally the same as predefined class names, with the only difference being the entirely theoretical purity of their semantics. Let's say, however, that we prefer |role| to |class| anyway. Why would we want to do <section role="article"> when <article> is shorter: | <section role="article"></section> | <article></article> And you can't argue fallback, because <section> and <article> are being defined in the same spec. What's more is that an article is more important semantically than a section, and articles (marked up or not) actually occur with more frequency, so why would we want to demote it two levels in markup? "What demotion?", you might ask. The first level of demotion is to make it an attribute: | <section article></section> This, however, would annoy the XHTML folk who can't use attribute minimization, so it's demoted once again to a mere attribute value: | <section role="article"></section> Part of the problem with this kind of markup demotion is that new attributes that would have gone on an <article> suddenly need to apply globally to every element, which is cumbersome. (Think <li rel=""> without the |href| attribute and you only begin to understand.) Another problem is that the more roles that apply to specific elements like <section>, the more broad the semantics of the element have to be to accommodate all these roles. In other words, global attribute values broaden the semantics of elements rather than making them more specific, and thus water them down until they loose their specificity. In the case of <section>, it could eventually become the semantic equivalent of a <div> with better heading support. Now, consider what would happen if you made it so that <section> could only be contained in an <article>. That makes all <section> elements sections of an article and reinforces the concept that <article> represents the primary element for content. > If the authors can't make the internal sectioning consistent, > do you expect them to make the internal "articling" consistent? It's a matter of subjectivity. You can usually objectively determine what an article is because it as a distinct topic an author and frequently encompasses all meaningful content in the page. Sections are more subjective because there may not be distinct divisions in topic between paragraphs.
Received on Wednesday, 7 March 2007 16:13:08 UTC