W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: Proposal: <content> element

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 28 Aug 2009 00:56:41 +0000 (UTC)
To: Anne van Kesteren <annevk@opera.com>, Maciej Stachowiak <mjs@apple.com>, John Drinkwater <john@nextraweb.com>, Geoffrey Sneddon <gsneddon@opera.com>, James Graham <jgraham@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Steven Faulkner <faulkner.steve@gmail.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0908280030330.13789@hixie.dreamhostps.com>
On Mon, 17 Aug 2009, 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.

We already have a way to mark up the content that isn't the header, 
footer, sidebars, or navigation: it's the markup that isn't the <header>, 
<footer>, <aside>, or <nav>.


On Mon, 17 Aug 2009, Maciej Stachowiak wrote:
> 
> I agree that an element for the main content would be useful. It seems 
> that if you have <nav>, <header>, <footer> and <aside> sections inside 
> your body, then it would be better to put the main content in some kind 
> of specific element. If that content is not an article (as in the case 
> of a web application or a multi-article page such as a blog), then it 
> seems a little weak to put the main content in a generic <div> or 
> <section>.

<div> is what I would recommend, if you need to style it. Otherwise, if 
styling is not a concern, then <body> is the relevant element.

<article> is appropriate if you would syndicate the content; this could be 
the case for a Web app, e.g. a widget could be in an <article>.


On Mon, 17 Aug 2009, James Graham wrote:
> 
> Hmm, that doesn't seem right; presumably the point of such an element 
> would be to allow UAs to implement a "skip to main content" feature 
> implying that there would be a single element per page.

You can already skip to main content by skipping everything that isn't hte 
main content.


On Mon, 17 Aug 2009, Tab Atkins Jr. wrote:
> 
> So it looks like the main problem here is determining whether we're 
> asking for a counterpart to <header>/<footer>/<aside> and such (without 
> the implicit sectioning), or if we're asking for a language-blessed 
> replacement for #main.
> 
> I'm not sure if the former is useful.  For the latter, I basically treat 
> <article> as being that element.  It's not always going to be such (you 
> can have multiple <article>s on a page), but if an AT is trying to skip 
> down to something useful, skipping to the first <article> would be a 
> good start.

If the goal is just to have a styling hook, <div> seems to do the job 
right. The semantic of the proposed element here really seems to be the 
same as the semantic of not having an element at all.


On Mon, 17 Aug 2009, Lachlan Hunt wrote:
> 
> I'm not sure why <div> isn't sufficient for this, and it's what I've 
> recommended for people to use when I've been asked about this.  The main 
> content of a section should just be considered to be whatever content 
> follows its header.

Agreed.


> But in this case, to help prevent the misuse of other elements like 
> <section> and <article> for this purpose, which people seem tempted to 
> do, it might be better to meet authors expectations on this and provide 
> an explicit element for it.
> 
> But I agree with gsnedders about how we should do this, if we do it at 
> all. We should allow one content element per section, so a typical 
> section could look like this:
> 
> <section> (or other sectioning element)
>   <header/>
>   <content/>
>   <footer/>
> </section>

Purely to prevent other elements from being abused, I could buy doing 
this... I dunno, though, it seems a bit silly. I'd rather wait to see if 
we can evangelise the right markup some more before giving up.


> And the main content could be considered to be the first content element 
> that is a descendant of the body element (not necessarily a child of 
> body), but which isn't a descendant of another sectioning element, if 
> there is one, or otherwise simply the content after the body's header.

It wouldn't have any effect on this; the semantics to do this are already 
present.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 28 August 2009 00:55:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC