- From: <bugzilla@jessica.w3.org>
- Date: Sun, 13 Mar 2011 01:48:08 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12292 Summary: Use of <teaser> or similar construct for a reference to an external article. Product: HTML WG Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: kurt.cagle@gmail.com QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Sunday, 13 March 2011 01:48:11 UTC