Re: Proposal: <content> element

John Drinkwater wrote:
> Anne van Kesteren wrote:
>> Looking back at the Web Authoring Statistics
>>
>>   http://code.google.com/webstats/2005-12/classes.html
>>
>> I think the classes that indicated the need for an <article> in fact 
>> indicate the need for another element. Besides having a header and a 
>> footer most pages have some kind of element that indicates where the 
>> main content of the page is. I think that is what the classes "main" 
>> and "content" indicate. WAI-ARIA has a specific role for this purpose 
>> as well, "main". Presumably allowing AT to jump directly to the 
>> content of a page.
>>
>> If you consider a typical blog or news site you have a header, 
>> sidebar, footer, and a content area. The content area is not a single 
>> article, but usually (on the frontpage) consists of the latest ten 
>> articles or so. It seems perfectly logical to have some kind of 
>> grouping element for these just like many pages already do.
>>
>> I think that if you do the study again and also include the values of 
>> id attributes it will become even more clear, but simply studying 
>> templates of some blog engines probably does the trick too.
>>
> 
> I like this proposal. I take it that the element would be identical to 
> <section>, but with the clear difference that it *is* a generic 
> container?

I guess the intent is that it provides content for the current section 
(much like header contains the header for the current section). As such, 
I would expect it to have no effect on the outlining algorithm (unlike 
section, which does have an effect).

> And with only one content element per document?

The same restrictions as header and footer make sense, i.e., none.

-- 
Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

Received on Monday, 17 August 2009 09:23:35 UTC