container-brainstorming: Difference between revisions
(Created container brainstorming. Longrunnining hCalendar idea is compatible with hReview discussion as well. Documenting shared/generic aspects of shared-property-containers with some examples.) |
m (→What's a Container?: Fixed closed code tag) |
||
Line 7: | Line 7: | ||
A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items. | A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items. | ||
Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard<code>s. | Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s. | ||
==Why is this being explored?== | ==Why is this being explored?== |
Revision as of 22:26, 2 June 2009
<entry-title>Containers</entry-title>
This page exists to brainstorm around the concept of ‘containers’ in microformats.
What's a Container?
A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.
Some microformats already define containers: vcalendar
hCalendar is a container for events, the hfeed
container in hAtom contains entries, hAudio has a concept whereby haudio
concepts may be nested, and an hCard vcard
may be a container for agent vcard
s.
Why is this being explored?
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and hReview, where no current container concept exists.
Use cases
Yahoo! TV Listings marks up television programme listings using hCalendar. The location
field of the event is the channel on which the show is broadcast: e.g. <span class='location'>BBC 1</span>.
- ‘BBC 1’ is the heading for that channels listing page. The information is published once in the page.
- Each scheduled programme on the page is a
vevent
- Using current hCalendar semantics, the
location
must be included in every vevent
With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the include-pattern need to be used to invisibly reference the original mention of ‘BBC 1’.
Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.
.e.g.
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>
<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
Here, the location
is promoted to being a property of the vcalendar
, and is the default location for all the contained events.
This could also apply to the organizer
, attendees
, and others. With further explanation and date-time separation, you could event declare the day of the week the the vcalendar
and the time-of-day in the vevent
. The basic principal is illustrated, though.
Uses for this pattern:
- Broadcast listings for a single channel/station
- Concert listings at a single venue
- Concert listings for a single act (e.g. ‘Doves in Concert’ is the event
summary
for multiple events at different locations
)
This of course, extends the use of an existing container.
Multiple reviews of the same item
Many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. hReview's current requirement is that the item
be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.
An alternative method could be to wrap each hReview
in a container (hypothetically, hreview-set
. The item
is a child of the set, and is inherited by each hreview
contained within.
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).
Things that should be consistent and predictable:
- Inheriting an property into a microformat item within the container
- Contained items overriding one or more inherited property