This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I am working on a book on HTML5 web graphics - primarily CSS, SVG and Canvas at this stage, for O'Reilly Publishing, and am focusing at the moment on the various new elements being added for their impact upon both HTML structure and CSS. In doing so, it occurred to me that there's a conceptual element that's missing in the model that could prove very useful to add. I was looking specifically at the <article> element; the HTML5 specification implies that an article is much like an Atom <entry> , yet realistically an <article> is a complete narrative node while an entry is rather a bundle of metadata that may possibly provide narrative content but is most important for its linkages. Put another way, let's say you had a "front page" on a site that contained teasers to complete articles within the site. I'd argue that these entries would by the definition of sectional elements be contained within a <nav> structure, and that rather than being given as articles a new element, perhaps <teaser>, would be better here. In this way, a news site would have a general structure that might look like: <body> <header> <h1>My News Site</h1> </header> <nav> <teaser> <header> <h1><a href="url1">Cool Article 1</a></h1> </header> <p>Lorem Ipsum ...</p> </teaser> <teaser> <header> <h1><a href="url1">Cool Article 2</a></h1> </header> <p>Lorem Ipsum ...</p> </teaser> <teaser> <header> <h1><a href="url1">Cool Article 3</a></h1> </header> <p>Lorem Ipsum ...</p> </teaser> </nav> <footer> <p>Copyright 2011 me</p> </footer> </body> This would hold regardless of whether this was rendered as a search results page, a front page, or similar kind of entity, and implies that the entry in question is in fact a reference to an external article rather than the article itself. This even makes sense in the context of a page with existing article content. The existing listing implies that you could nest articles, where subordinate nested articles are links, but again this really doesn't square with the concept of the article as being a narrative whole. Rather, if you treat a list of related links to an article as a set of teasers in a nav within an article, then the structure begins to make sense: <body> <header> <h1>My News Site</h1> </header> <article> <header> <h1>Cool Article</h1> </header> <p>Lorem Ispum ...</p> <nav> <header> <h1>Related articles:</h1> </header> <teaser> <header> <h1><a href="url1">Cool Article 2</a></h1> </header> <p>Lorem Ipsum ...</p> </teaser> <teaser> <header> <h1><a href="url1">Cool Article 3</a></h1> </header> <p>Lorem Ipsum ...</p> </teaser> </nav> </article> <footer> <p>Copyright 2011 me</p> </footer> </body> Not only is it conceptually clearer, but it also makes CSS constructs more legible: article h1 {font-family:Times New Roman; font-size:18pt;} article teaser h1 {font-size:12pt;} rather than the potentially problematic: article article h1 {font-size:12pt;} I would recommend teaser or something similar over section because sections 1) are recursive, and 2) similarly imply narrative cohesiveness rather than relational linkages. Moreover, while teasers are analogous to list items (li), I'd argue that li is typically used for lists of teasers or similar constructs because there is no analog in HTML for a teaser, and lists in turn have expected default markup that teasers may not necessarily have.
It seems to me that <blockquote cite="uri"> could be used to mark teasers.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: When we looked at common authoring practices, it didn't seem that this was a hugely common one, so I don't think we need to add a feature to support it yet. Maybe one day. In the meantime, I recommend using either <blockquote> (if you're actually quoting the article), or just <p>, possible with a class name, all inside <nav> as you suggest.
mass-move component to LC1