[uf-discuss] Chat microformat/podcast transcript
brian.suda at gmail.com
Wed Apr 19 17:08:42 PDT 2006
You should also be aware of the proposed OBJECT include pattern.
With this you could do something like:
<span class="vcard" id="Person1">
<!-- hcard stuff here for Person1 -->
<li><cite><object data="#Person1" class="include"/></cite><q>Quoted
The object tag says "get the data at #Person1 and use it here.
 - http://microformats.org/wiki/include-pattern
On 4/19/06, Ben Ward <lists at ben-ward.co.uk> wrote:
> On 4/19/06, Paul Bryson <paul at msn.com> wrote:
> > One thing though, I use at least one chat program that has an option to
> > condense all contiguous messages from a single author together so that it
> > just displays the author once, but the timestamp of each message.
> A couple of responses come to mind:
> Firstly, that it could be acceptable to have multiple time+q pairs
> within each list item, such that you might have:
> <abbr title="">12:38am</abbr> <q>First statement</q>
> <abbr title="">12:39am</abbr> <q>Additional Comment</q>
> <abbr title="">12:40am</abbr> <q>Response</q>
> A generator application could then append ABBR+Q to the previous li
> content as appropriate, thus the restriction would come out as 'one
> CITE per LI with all other LI content attributable to that person'.
> Which makes a certain amount of sense.
> The alternative would be to say that you could potentially handle the
> condensed rendering at render-time. What you're effectively
> determining is the display: property of each LI > CITE. However, since
> that would be dependent on the innerText of a predecessor's child,
> which is well out of range of current CSS2 and proposed level 3
> Selectors. Therefore such rendering would require scripting for this
> kind of presentation on the web.
> That's drifting off topic I think, I'm not sure how much of a
> consideration that would be at this stage. With respect to
> presentation though, I think flexibility (such as multiple abbr+cite)
> is useful.
> On a different tack (and this is not a suggestion that I especially
> advocate, but I think it's valid to raise it for sake of clear
> dismissal): It could be argued that each message is actually an event
> in the conversation. Therefore, should there be reuse of hCalendar
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss