IRC Log for #microformats on 2006-01-01
Timestamps are in UTC.
- [00:06:20] * factoryjoe (n=cmessina@h-67-103-44-6.snfccasy.covad.net) has joined #microformats
- [00:06:21] <jibot>
factoryjoe is Chris Messina, works for Flock, Bar Camp and Rhyzomatic and is working towards open source world domination
- [00:08:42] <megasquid>
Tantek: that makes sense, thanks
- [00:09:10] <KevinMarks>
hi chris
- [00:09:19] <KevinMarks>
you seen the CEScamp thing?
- [00:09:26] <factoryjoe>
um?
- [00:09:28] <factoryjoe>
link?
- [00:10:16] <KevinMarks>
http://ces.bubbleshare.com/index.php?wiki=CesCamp
- [00:11:57] <factoryjoe>
mm
- [00:12:45] <factoryjoe>
wow
- [00:12:50] <KevinMarks>
they likely need a bit of help to get it coing
- [00:12:51] <factoryjoe>
man, we sure started something
- [00:12:56] <factoryjoe>
seems like it
- [00:12:58] <factoryjoe>
who's in chrage?
- [00:13:02] <factoryjoe>
charge even?
- [00:13:30] <KevinMarks>
er, nto sure
- [00:13:35] <factoryjoe>
k
- [00:13:39] <KevinMarks>
Jeneane pointed me at it
- [00:14:02] <KevinMarks>
I think Albert Lai set up the wiki
- [00:14:14] <factoryjoe>
ah, i don't know them
- [00:14:40] <KevinMarks>
?def jeneane
- [00:14:41] <jibot>
jeneane is THE Jeneane, and blogs to http://allied.blogspot.com/ and from Venus
- [00:17:11] <factoryjoe>
from venus?
- [00:31:56] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [00:32:42] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) Quit ("via the nearest exit")
- [00:34:47] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [00:42:54] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [00:44:05] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [00:54:31] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [00:56:33] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [00:57:17] * factoryjoe (n=cmessina@h-67-103-44-6.snfccasy.covad.net) Quit ()
- [01:06:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [01:08:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [01:19:40] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [01:21:07] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [01:34:06] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [01:35:09] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [01:36:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Remote closed the connection)
- [01:52:08] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [01:52:09] <jibot>
Atamido is Paul Bryson, http://orangeman.commo.de/
- [02:38:22] * edsu (n=esummers@66.187.134.52) has joined #microformats
- [03:10:17] * jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) has joined #microformats
- [03:12:59] <Hixie>
hey does anyone have any links to people who have written blogs about what class attribute values people use? or who can remember who wrote that blog entry about who uses xhtml?
- [03:13:10] <Hixie>
(other than the one by john allsopp than tantek mentioned earlier)
- [03:48:26] <KevinMarks>
I know a blog search engine you coudl try, Hixie
- [03:49:00] <Hixie>
hah
- [03:49:04] <Hixie>
yeah well tried that
- [03:49:08] <KevinMarks>
hm
- [03:49:11] <Hixie>
i did find a couple of sites
- [03:49:15] <Hixie>
http://www.goer.org/Journal/2003/Apr/index.html
- [03:49:18] <Hixie>
http://www.markokarppinen.com/20020222.html
- [03:49:20] <Hixie>
http://phnk.com/design/survey/
- [03:49:31] <Hixie>
and http://westciv.typepad.com/dog_or_higher/2005/11/real_world_sema.html
- [03:49:34] <Hixie>
but i was hoping for more
- [03:51:09] <KevinMarks>
have a loook a zen garden and the link trail fromthat fro the hard-core CSSies
- [03:52:08] <Hixie>
yeah, didn't find anything in the blogosphere other than those four
- [03:52:14] <Hixie>
lots of people _talking_ about those
- [03:52:16] <Hixie>
or linking to them
- [03:52:31] <Hixie>
or generally waffling on about xhtml being good or bad or semantics being hard or whatever
- [03:52:38] <Hixie>
but very little genuine research
- [03:53:02] <KevinMarks>
we need to get Pilgrim blogging again
- [03:53:26] <Hixie>
oh hey i met mark the other day actually
- [03:53:43] <Hixie>
he was at some mozilla shingdig, had lunch with him at google
- [03:53:55] <KevinMarks>
I dind't know he was up this way
- [03:53:55] <Hixie>
apparently he's all busy at ibm
- [03:54:20] <KevinMarks>
I need to get on with microformats in feedparser wiht him
- [03:55:23] <jcgregorio>
I'm pretty sure mark won't blog again
- [03:56:52] <KevinMarks>
well, get him a syndicated newspaper column or something
- [03:58:45] * edsu (n=esummers@66.187.134.52) Quit ("leaving")
- [04:17:09] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) has joined #microformats
- [04:47:14] <Tantek>
good evening
- [04:58:09] <jcgregorio>
hello and happy new year!
- [04:58:24] <jcgregorio>
at least in two minutes for me
- [05:01:46] <Tantek>
happy new year joe!
- [05:02:11] <Tantek>
and to everybody else in Eastern Standard Time!
- [05:10:16] <jcgregorio>
thanks!
- [05:45:36] * jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) Quit ("Chatzilla 0.9.68.5.1 [Firefox 1.0.7/20051010]")
- [06:24:30] <Frederic>
Happy new year
- [06:52:08] <Tantek>
Happy New Year Frederic!
- [07:09:06] <Frederic>
Happy new year Tantek
- [07:09:38] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) Quit (Remote closed the connection)
- [07:46:06] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) has joined #microformats
- [08:00:47] <KevinMarks>
happy new year chaps
- [08:29:24] <Tantek>
happy new year everyone!
- [08:29:42] * bkdelong (n=bkdelong@h-67-102-164-116.cmbrmaor.covad.net) Quit (Read error: 110 (Connection timed out))
- [09:10:54] <Frederic>
happy *.*
- [13:32:32] * megasquid (n=megasqui@cpe-66-27-237-225.bak.res.rr.com) Quit ()
- [14:26:18] * fuzzyBSc (n=fuzzy@c210-49-73-138.rochd2.qld.optusnet.com.au) has joined #microformats
- [14:26:19] <jibot>
fuzzyBSc is Benjamin Carlyle, http://soundadvice.id.au/blog/
- [14:28:47] * ichigo (n=ichigo@M2660P022.adsl.highway.telekom.at) has joined #microformats
- [14:28:57] * ichigo (n=ichigo@M2660P022.adsl.highway.telekom.at) Quit (Client Quit)
- [14:33:36] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3652 * FuzzyBSc * (+45) Clarify current suggestion
- [15:13:51] <fuzzyBSc>
I have obliquely summarised some of the discussions had on the channel to microformats-discuss, and have described my nomenclature suggestion for atom:title/atom:summary/atom:content = hAtom summary/description/content
- [15:14:09] <fuzzyBSc>
Does the channel have any immediate feedback? :)
- [15:15:34] * AndreasHaugstrup (i=usenet@D40A9676.rev.stofanet.dk) has joined #microformats
- [15:19:26] * AndreasHaugstrup (i=usenet@D40A9676.rev.stofanet.dk) has left #microformats
- [15:21:58] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3653 * FuzzyBSc * (+503) Add hReview and date-time question
- [15:27:25] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3654 * FuzzyBSc * (+33) Add subject as alternative to atom:title
- [15:30:20] <fuzzyBSc>
An alternative to content might be body, actually.
- [15:30:35] <fuzzyBSc>
It wouldn't work too well in html though, I guess. Not with the established <body> element :)
- [15:49:11] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3655 * FuzzyBSc * (+172) Add subject-based alternative
- [15:50:04] <fuzzyBSc>
I currently have two alternatives in play that may or may not be compatible with existing precedent:
- [15:50:08] <fuzzyBSc>
summary (atom:title) -> description (atom:summary) -> content (atom:content)
- [15:50:19] <fuzzyBSc>
subject (atom:title) -> summary (atom:summary) -> content (atom:content)
- [15:52:01] * RobertBachmann (n=RobertBa@M2500P001.adsl.highway.telekom.at) has joined #microformats
- [16:07:17] <RobertBachmann>
greetings.
- [16:22:28] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) Quit (Remote closed the connection)
- [16:27:51] <fuzzyBSc>
Morning, Robert :)
- [16:28:18] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) has joined #microformats
- [16:34:16] <fuzzyBSc>
Hrrm.
- [16:34:55] <fuzzyBSc>
rfc2445: "When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" property, which contains the text to be used as the message body, a "SUMMARY" property, which contains the text to be used as the message subject, and one or more "ATTENDEE" properties, which contain the email address of attendees to receive the message."
- [16:36:52] <fuzzyBSc>
That may indicate that description is meant to be equivalent to a full message body, and summary equivalent to message subject. VJournal description, atom:content, and atom:summary may overlap. VJournal summary, atom:title, and atom:summary may also overlap.
- [16:37:46] <fuzzyBSc>
I have been struggling to find a clear definition of what summary has meant in earlier standards. Is it exclusively atom:title, it exclusively atom:summary, or could it be either?
- [16:39:16] <fuzzyBSc>
The requirement that summary be used as an email subject line implies to me that it is meant to be a single line title rather than a single paragraph teaser.
- [16:42:02] <fuzzyBSc>
rfc2445: This property [description] is used in the "VJOURNAL" calendar component to capture one more textual journal entries.
- [16:42:31] <fuzzyBSc>
This makes it sound like atom:content. In which case, what do you call atom:summary?
- [16:42:58] <mfbot>
[[hresume]] MN http://microformats.org/wiki/hresume * Tantek * (+222)
- [16:43:33] <fuzzyBSc>
rfc2445: "Purpose: This property [description] provides a more complete description of the calendar component, than that provided by the "SUMMARY" property."
- [16:43:59] <fuzzyBSc>
You could take this to mean it is still the description of some content like atom:summary is, rather than content in and of itself.
- [17:10:40] <mfbot>
[[recipe-examples]] N http://microformats.org/wiki/recipe-examples * Tantek * (+1592) recipe-examples first draft
- [17:11:36] <Tantek>
hi Fuzzy
- [17:11:47] <Tantek>
you are correct that description = full content
- [17:12:36] <Tantek>
BTW, using the name "content" anywhere in a schema is not really a good idea. It implies that the rest of the data is not content - which is clearly a matter of perspective.
- [17:13:08] <Tantek>
Same problem with the "meta-data" distinction. In practice it is not very useful.
- [17:13:36] <Tantek>
From a user's perspective, there is the information they care about and the information they don't care about.
- [17:14:05] <Tantek>
The former includes what theoreticians distinguish as data vs. meta-data, but the end user doesn't care about such a distinction.
- [17:14:18] <Tantek>
Headings are the perfect example.
- [17:14:32] <Tantek>
Some would say they are part of the "content", some would say they are not.
- [17:15:31] <Tantek>
The other evidence for "content" being a bad name to use in a schema is the existence in the wild of such evolved terms as "main-content", which implies that there was a "content" at one level, but someone else came along that wanted something more specific that *they* thought was *really* the content, so they made up their own term.
- [17:16:42] <Tantek>
BTW, consider how people discuss RSS/Atom feeds
- [17:16:56] <Tantek>
They don't say "summary feed" vs. "content feed"
- [17:17:35] <Tantek>
They say "partial-text" vs. "full-text" feeds
- [17:23:27] * fuzzyBSc nods
- [17:25:09] <fuzzyBSc>
I have already raised one issue about opacity of hAtom content regarding update time. Content in the atom sense really means "what the feed reader user sees in the main panel for a full-conent feed". That usually includes some information about updates, particularly the text of the update itself.
- [17:26:06] <fuzzyBSc>
It seems the publisher should be able to define this box of what is inside and out, but the box may not be opaque and it may be useful sometimes to say <div class="entry content">...</div> and have everything appear in the box.
- [17:26:51] <fuzzyBSc>
Atom is about separating the human- from the machine- readable, but hAtom should not be.
- [17:29:40] <fuzzyBSc>
I think there is still value in allowing a feed with both summary and content selections for "read more" blogs. That I think was the determination of the atom committee when they created two elements rather than just allowing one with a "is-full" attribute. The question still remains as to what to call them, though. All prior existing terms seem heavily overloaded.
- [17:30:11] <fuzzyBSc>
(or at least are not compatible with the three-tier level of detail atom provides)
- [17:32:26] <fuzzyBSc>
The thing that is bugging me at the moment is that I am not sure a title is always a summary. The title of the CD in front of me is "Breathing Tornados", rather than "Ben Lee sings about life in the nineties".
- [17:33:33] <Tantek>
fuzzy, you said: "Atom is about separating the human- from the machine- readable, but hAtom should not be."
- [17:33:37] <Tantek>
That is precisely correct!
- [17:33:52] <Tantek>
You have captured one of the key essences of microformats in that short statement.
- [17:34:00] <fuzzyBSc>
The summary concept as extracted from iCalendar is a descriptive title. It is a short summary of the event that is being described or listed. Summary might say "U2 Concert", but it might still be legitimate to use "Elevation" as the title.
- [17:34:41] <Tantek>
I just realized that atom's use of "summary" as name for partial content is actually semantically incorrect.
- [17:34:44] <fuzzyBSc>
Tantek: Yes, I know :) Sometimes I state the obvious for effect ;)
- [17:34:55] <Tantek>
Rarely is the "summary" an actual *summary*
- [17:35:06] <Tantek>
It is more often just the first part of the description
- [17:35:10] <Tantek>
It is an abbreviation
- [17:35:14] <Tantek>
It is partial
- [17:35:18] <Tantek>
It is NOT a summary
- [17:36:04] <Tantek>
Perhaps we should consider a term that reflects actual usage
- [17:36:08] <Tantek>
and actual discussion
- [17:36:17] <Tantek>
hence why I raised the point about "partial-text"
- [17:36:31] <Tantek>
Since we have "description" already to mean "full text"
- [17:36:47] <Tantek>
Perhaps we could consider "partial-description"
- [17:37:46] <Tantek>
(side-note: yes, the term "content" is both way too ambiguous and overloaded to be of any practical use in a data format schema)
- [17:38:12] <fuzzyBSc>
Oh, I don't know. Let's take the rss feed from http://xml.coverpages.org/covernews.xml as an example. As a semi-serious news site it summarses each entry dilligently in the feed. It is very similar to the introductary paragraph of the story by not identical.
- [17:38:24] <Tantek>
fuzzy, you are right that in practice, a title is not always a summary, but, in blog posts, it often is
- [17:38:35] <Tantek>
perhaps even >50% of the time
- [17:39:04] <Tantek>
(you gave an example of CD, let's side-table the media info discussion for now)
- [17:39:19] <fuzzyBSc>
Tantek: I think that most of the time title could accurately be described as a "heading".
- [17:39:21] * Tantek goes to xml.coverpages....
- [17:39:56] <Tantek>
fuzzy, yes
- [17:40:13] * Tantek wonders if http://xml.coverpages.org/covernews.xml is a 20% case rather than an 80% case.
- [17:40:39] <Tantek>
the relationship between title and heading is a subset/subclass
- [17:40:46] <Tantek>
i.e. most titles are headings
- [17:40:52] <Tantek>
but most headings are not titles
- [17:41:00] <Tantek>
titles could be said to be a specific type of heading
- [17:41:08] <fuzzyBSc>
Tantek: For blogging I think it would be a 20% case. I'm not sure whether it would be or not for syndicated journalism. My blogroll is wide, but not that wide ;)
- [17:41:11] <Tantek>
which is exactly what you see in practice on blogs!
- [17:41:12] <Tantek>
e.g.
- [17:41:18] <Tantek>
<h3 class="title">...</h3>
- [17:41:58] <Tantek>
fuzzy, if it is the 20% case, then it *certainly* shouldn't be used to steer a naming discussion
- [17:41:59] <fuzzyBSc>
So is title = summary or not? :)
- [17:43:04] <fuzzyBSc>
Tantek: Well, I suppose we could always use summary (atom:title) -> shortdescription (atom:summary) -> description (atom:content)
- [17:43:23] <Tantek>
I think we need a different term for what Atom calls "summary", since in practice, the 80/20 case is that people don't actually use it for a "summary"
- [17:43:34] <Tantek>
right, something like that
- [17:43:47] <Tantek>
except even then, why not use what people call these things?
- [17:44:09] <Tantek>
What else do people call them besides "partial" ?
- [17:44:16] <Tantek>
(in actual discussions)
- [17:44:18] <fuzzyBSc>
In all honesty, I think that the use of summary itself is in the 20%... but it is growing as publishers want users to visit their site and click on their ads.
- [17:45:07] <fuzzyBSc>
Tantek: Partial is the word I have heard used. Perhaps more reasearch would be useful.
- [17:45:29] <Tantek>
precisely
- [17:45:31] <Tantek>
here is a URL
- [17:45:32] <Tantek>
http://scobleizer.wordpress.com/2005/11/28/the-fullpartial-debate-roars-on/
- [17:45:52] <Tantek>
So let's ask this question: why didn't Atom use the term "partial" ?
- [17:46:10] <fuzzyBSc>
In fact, partialdescription is semantically neat. It exists to tell you that it is not the whole description. A short description could be complete, but a partial one is always accompanied by a full description.
- [17:46:40] <fuzzyBSc>
s/accompanied/matched/
- [17:48:06] <Tantek>
right
- [17:48:09] <fuzzyBSc>
Are you wedded to summary = atom:title at this stage, then?
- [17:48:32] <Tantek>
of course, using microformat property naming rules, we would use a hyphen rather than omit the space when converting "partial description" to a property name
- [17:48:53] <fuzzyBSc>
:)
- [17:48:53] <fuzzyBSc>
Ok. I'm still new in this game.
- [17:49:03] <Tantek>
No, I'm trying to solve the problem of what better name to use for Atom's ill-named concept of "summary"
- [17:49:35] <Tantek>
Even if/when we solve that problem, it is still unclear whether we should use the property name "summary" to refer to "atom:title"
- [17:50:02] <Tantek>
We may want to not use "summary" at all in hAtom, due to fact that it will confuse either or both microformat or Atom developers.
- [17:50:15] <fuzzyBSc>
So there is still room for movement on each of the three axis, and any proposal should set forth all three.
- [17:50:23] <Tantek>
Not necessarily.
- [17:50:29] <Tantek>
It may be easier to solve one problem at a time.
- [17:50:42] <fuzzyBSc>
Perhaps
- [17:50:59] <Tantek>
In untangling this dependency mess, it appeared to me that solving the what to call "atom:summary" problem was one we could address independently of the others.
- [17:51:24] <Tantek>
So let's make that a concrete proposal then.
- [17:51:34] <Tantek>
"partial-description"
- [17:52:04] <fuzzyBSc>
I'll write it up.
- [17:52:36] <Tantek>
Another term I have heard:
- [17:52:39] <Tantek>
"excerpt"
- [17:53:20] * Tantek just read down to comment #15 on Scoble's post: http://scobleizer.wordpress.com/2005/11/28/the-fullpartial-debate-roars-on/#comment-5201
- [17:53:47] <Tantek>
I like it because it is short and to the point
- [17:54:31] <Tantek>
Though it may be too specific, as "excerpt" implies a proper subset, whereas a "partial-description" sounds like it allows for different content than in the "description".
- [17:57:52] <fuzzyBSc>
I'll put both in. There is presumably no harm in having a bit of brainstorming... or should this iteration be moved back to blog-post-brainstorming at some point?
- [17:58:27] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3656 * FuzzyBSc * (+249) Add partial-description and excerpt as options for atom:summary
- [18:00:27] <fuzzyBSc>
In a typical "read more" situation the summary is likely to be a proper excerpt. Although it isn't supported by current opacity rules I imagine a nesting such as <div class="content"><div class="summary">...</div>...</div>
- [18:02:43] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3657 * FuzzyBSc * (+201) Add "read more" summary nested in content example for opaqueness
- [18:05:18] <Tantek>
yes, i agree, in typical (one might even say >80%) situations, these will be proper excerpts with "read more" links.
- [18:05:35] <Tantek>
this feels much better. we are designing based on actual behavior.
- [18:06:25] * RobertBachmann (n=RobertBa@M2500P001.adsl.highway.telekom.at) Quit (Read error: 104 (Connection reset by peer))
- [18:09:56] <fuzzyBSc>
It does seem unlikely that a summary rather than an excerpt will be commonly used in hAtom. It could still be done, but to make it work visually you may have to hide the summary at the same time as you exposed the content.
- [18:10:17] <Tantek>
right
- [18:10:45] <Tantek>
in addition for the title vs. summary debate, I have a feeling we will have to not use "summary" in hAtom to mean anything, just to avoid confusion.
- [18:10:57] <fuzzyBSc>
Interestingly, hAtom could handle summary-only feeds well also. A publisher could simply enter the full content but only mark up a portion as summary. No markup would be provided for content, except perhaps a permalink.
- [18:11:10] <Tantek>
oh wow, that would totally work
- [18:11:29] <Tantek>
you should *definitely* add that observation to the brainstorming page
- [18:11:40] <fuzzyBSc>
:)
- [18:11:51] <Tantek>
excerpt-only feeds :)
- [18:12:06] <Tantek>
just by marking up the excerpt in the blog, and *not* the description
- [18:23:30] <mfbot>
[[blog-post-brainstorming]] http://microformats.org/wiki?title=blog-post-brainstorming&diff=0&oldid=3658 * FuzzyBSc * (+381) Add partial-content blog use case
- [18:31:10] <fuzzyBSc>
Some of the possible shifts in hAtom going forwards may start to depend on mfo directly. If atom:content elements are no longer considered opaque in the search for metadata such as atom:updated or atom:summary information mfo may have to be provided to avoid tripping over other microformats.
- [18:34:12] <fuzzyBSc>
Hrmm.. on the other hand, if there are no conflicting definitions the problem dropps off significantly. The only reason I have seen it in practice is because of hCard title and hCalendar summary elements.
- [18:36:34] <_fil_>
fuzzyBSc: I currently embed <a relTag> in my RSS "content" part, and process it accordingly, and it's magic
- [18:37:26] <Tantek>
fuzzy, you don't need to worry about hCard and hCalendar and opaqueness, because by defintion when a parser encounters an hCard or hCalendar, it shouldn't look inside for any of its own properties
- [18:38:08] <fuzzyBSc>
_fil_: I'm not sure I follow. Is this for partial feeds?
- [18:38:47] <fuzzyBSc>
Tantek: So a hAtom parser should explicitly drop out when it sees those? That isn't currently codified in standard or xsl, but makes sense.
- [18:43:37] <Tantek>
right
- [18:44:20] <Tantek>
the reason I brought up mfo is because of exactly that -- it's not documented which other microformats, e.g. root class names, should act as opaque layers that other microformat parsers shouldn't parse "into"
- [18:44:52] <Tantek>
thus for now, an hAtom parser has to look for an know that when it finds a class="vcard" or class="vcalendar" or class="vevent", that it should not look inside
- [18:44:52] <fuzzyBSc>
... and it isn't possible to future-proof parsers against new microformats.
- [18:44:57] <Tantek>
precisely
- [18:45:06] <Tantek>
and that's why i proposed the mfo-examples
- [18:45:33] <Tantek>
if each such opaque microformatted chunk also included a class name to indicate the opacity, e.g. class="mfo vcard"
- [18:46:05] <_fil_>
fuzzyBSc: I thought it was relevant to the discussion you're having now. My RSS parser does seek the relTags inside the "atom:content" part of the text, to extract tags-links
- [18:46:08] <Tantek>
then an hAtom parser (and any other new microformat parser), could simply look for any element with class name of "mfo" and know not to parse inside it
- [18:46:24] <Tantek>
yes, sometimes you *want* transparency
- [18:46:26] <Tantek>
that's my point
- [18:46:34] <Tantek>
you need to be able to control it
- [18:46:42] <Tantek>
this is future proof
- [18:46:54] <Tantek>
in that a parser can just look for "mfo" (or whatever name we come up with)
- [18:47:10] <fuzzyBSc>
_fil_: Ahh, ok!
- [18:47:13] <Tantek>
and that any new microformats which are supposed to be opaque, can also add the "mfo" class name to the root element of the data
- [18:47:30] <Tantek>
and presto, you have forward/backward compatibility
- [18:47:48] <Tantek>
and you avoid having to list a specific set of microformat root classes as "opaque"
- [18:48:38] <jibot>
WildFox is Mr. KDOM. Co-author of kdom, ksvg and kcanvas.
- [18:48:49] * RobertBachmann (n=RobertBa@N137P031.adsl.highway.telekom.at) has joined #microformats
- [18:50:32] <fuzzyBSc>
Tantek: It'd be interesting to think how this would interact with uf html classes becoming mainstream elements in a future html. If vcard was an element, would you still need to say <vcard class="mfo">...</vcard>, or would you prefer to say <mfo class="vcard">...</mfo>?
- [18:50:34] <_fil_>
it's not clear if you should define opaque-ness OR transparency
- [18:51:18] <fuzzyBSc>
_fil_: I think ideally what is defined is context. You have your vcard and its content... now what does it apply to?
- [18:51:44] <fuzzyBSc>
Hrrm... or maybe that is you have your author and its vcard content.
- [18:52:02] <fuzzyBSc>
Now what (which microformat) is it the author of?
- [18:52:36] <mfbot>
[[media-info-examples]] N http://microformats.org/wiki/media-info-examples * Tantek * (+2263) first attempt at a simplified media info examples page
- [18:52:47] <_fil_>
right now it would be the first mf that embeds this vcard
- [18:53:01] <Tantek>
fuzzy, element names are overrated
- [18:53:05] <Tantek>
you can only have one of them per element
- [18:53:07] <Tantek>
so limiting. ;)
- [18:53:18] <Tantek>
whereas (X)HTML classes you can have as many as you want per element
- [18:53:19] <fuzzyBSc>
:)
- [18:53:29] <Tantek>
I've often wondered if this is a fundamental flaw of XML.
- [18:53:37] <Tantek>
the whole "only one element name" problem
- [18:53:55] <Tantek>
which then forces people into very strange hierarchical contortions that often don't map very well to the actual underlying data models
- [18:54:20] <_fil_>
Too many ppl think too ordered
- [18:54:25] <_fil_>
actual data is fuzzy
- [18:54:30] <Tantek>
and too hierarchical
- [18:54:38] <Tantek>
sometimes the data is fuzzy
- [18:54:39] <fuzzyBSc>
Well good xml practice usually teaches that the hierarchy of types that make up the element semantics are not part of the document. The parser should be reading "valid" XML.
- [18:54:47] <fuzzyBSc>
It doesn't quite fit with good web practice :)
- [18:54:49] <Tantek>
but by focusing on what people actually publish on *the Web*
- [18:54:59] <Tantek>
we are able to find patterns of structure
- [18:55:26] <Tantek>
this is why we emphasize real-world web publishing behavior so much
- [18:57:33] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3659 * FuzzyBSc * (+157) Add _fil_'s rel-tag-in-content usage
- [18:58:06] <fuzzyBSc>
I don't know if I can build an opacity test case for hAtom.
- [18:58:42] <fuzzyBSc>
I can put a vcard where one is not expected, but none of the class names line up, so it is already invisible.
- [18:59:15] <fuzzyBSc>
Oh. Title would, and hcalendar's summary would.. but these will soon be excluded from hAtom.
- [18:59:28] <_fil_>
fuzzyBSc: you can point to www.spip.net for the usage you just described
- [18:59:39] <fuzzyBSc>
_fil_: ok.
- [19:00:02] <fuzzyBSc>
_fil_: Any particular page?
- [19:00:27] <_fil_>
not yet :)
- [19:00:43] <_fil_>
but i just created a login so i can do it myself
- [19:00:57] <fuzzyBSc>
_fil_: I'll leave it to you, then ;)
- [19:01:04] <mfbot>
[[media-info-examples]] M http://microformats.org/wiki?title=media-info-examples&diff=0&oldid=3660 * Tantek * (+156)
- [19:09:47] <RobertBachmann>
I think I've found a bug.
- [19:10:15] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3661 * FuzzyBSc * (+148) Add abstract as option for summary
- [19:12:04] <RobertBachmann>
When we extract emails from a hcard like this: <a href="mailto:joe@example.com" class="email">joe's email</a> we should use the value of mailto:
- [19:12:34] <fuzzyBSc>
To turn the whole atom:content issue on its head... you could consider the entire entry element atom:content. Perhaps it should all be made available for viewing in the feed reader box.
- [19:12:58] <Tantek>
Robert, the attribute is still "href"
- [19:13:23] <Tantek>
I believe hcard-parsing covers the email/mailto detail
- [19:13:28] <Tantek>
Take a look
- [19:13:46] <RobertBachmann>
will do. I'm a little bit slow today ;-)
- [19:14:15] <fuzzyBSc>
The current implementation is always taking the visible text rather than the href.
- [19:14:33] <fuzzyBSc>
If it is an anchor it should use the href instead, yes.
- [19:14:35] <Tantek>
Robert, yes, it is right here: http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_values
- [19:14:44] * fuzzyBSc writes up a test case
- [19:14:52] <Tantek>
Anyone writing hCard parsing code MUST read that page thoroughly.
- [19:15:12] <Tantek>
fuzzy, you wrote: "To turn the whole atom:content issue on its head... you could consider the entire entry element atom:content. Perhaps it should all be made available for viewing in the feed reader box."
- [19:15:16] <Tantek>
precisely!
- [19:15:26] <Tantek>
"available for viewing" is the key piece here
- [19:15:36] <Tantek>
the user doesn't care about some programmer's abstraction about metadata
- [19:15:45] <Tantek>
the user just cares about *viewing* the *information*
- [19:16:05] <Tantek>
whether it is the title, summary, description, entry data, when published etc.
- [19:17:22] <fuzzyBSc>
Tantek: My feed reader displays the entry title in a list, separate to the content. That is also where it displays the date. Any metadata it knows how to extract gets thrown down the bottom, and content is placed in a scrollable panel.
- [19:17:54] <fuzzyBSc>
Making the whole entry content would put all those things back into the panel. Good or bad, I don't know :)
- [19:20:28] * RobertBachman1 (n=RobertBa@M2455P005.adsl.highway.telekom.at) has joined #microformats
- [19:22:20] <RobertBachman1>
fuzzryBSc: I'm already writting one.
- [19:22:58] * RobertBachmann (n=RobertBa@N137P031.adsl.highway.telekom.at) Quit (Nick collision from services.)
- [19:23:01] <fuzzyBSc>
Robert: Ok.
- [19:23:31] * RobertBachman1 is now known as robertbachmann
- [19:32:32] <mfbot>
[[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=3662 * Tantek * (+323) need to write naming-principles document
- [19:58:01] * robertbachmann (n=RobertBa@M2455P005.adsl.highway.telekom.at) Quit (Read error: 110 (Connection timed out))
- [19:58:11] * RobertBachman1 (n=RobertBa@M2470P023.adsl.highway.telekom.at) has joined #microformats
- [20:17:51] <Tantek>
fuzzy, your feed reader could still extract the entry title, date etc. if that's the view you want. but by default it makes sense to display it all.
- [20:18:11] <Tantek>
where they are displayed is merely a styling / presentational issue, not a structural / data format issue
- [20:18:12] <Tantek>
that's the key
- [20:19:15] <KevinMarks>
I dislike 'description' - that is legacy usage from the origins of RSS
- [20:19:22] <Tantek>
it predates RSS
- [20:19:32] <KevinMarks>
yes
- [20:20:13] <Tantek>
already extremely well established with vCalendar, iCalendar, and RSS.
- [20:20:19] <Tantek>
not going to change something that consistent now.
- [20:20:33] <KevinMarks>
in those cases it makes sense
- [20:20:39] <KevinMarks>
well, not rss so much
- [20:20:50] <KevinMarks>
becasue in there it is describing something else
- [20:21:09] <KevinMarks>
in classic rss it was describing the link being referred to for clickthrough
- [20:21:27] <KevinMarks>
however, for blogs it is nto a description fo the blog post but the post itself
- [20:21:53] <KevinMarks>
atom:content, that is
- [20:22:29] <KevinMarks>
with atom you can have tite/summary/content for progressive revelation of more
- [20:23:08] <KevinMarks>
but most feedreaders are built with the RSS ambiguity about whetehr there is more at the permalink or not
- [20:23:52] <KevinMarks>
so we have a problem in mapping the 2-level model used in hCalendar and hReview to the 3-level model in Atom
- [20:25:49] <Tantek>
Kevin, see IRC archives, there's already been a lot of discussion of that, including the very poor choice of "summary" as a name, since it is rarely used for that.
- [20:26:17] <KevinMarks>
yes, I read scrollback
- [20:27:23] <KevinMarks>
summary is also a poor name for the title
- [20:27:28] <KevinMarks>
headline, maybe
- [20:28:49] <KevinMarks>
MT and wordpress have long had separate entry boxes for summaries, or partials, but they are less-used
- [20:29:10] <KevinMarks>
the other thing MT does is the 'show the beginning, and have a 'read more' link
- [20:29:39] <KevinMarks>
which would imply you could have a 'partial' and a 'full' that overlap
- [20:31:24] <mfbot>
[[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3663 * FuzzyBSc * (+549) Why not use whole atom:entry as content?
- [20:32:32] * KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) Quit (Read error: 104 (Connection reset by peer))
- [20:32:32] <fuzzyBSc>
Kevin: The suggestion is that this might be the common case for any explicit atom:summary... that it is really an extract rather than an abstract.
- [20:34:36] * KevinMarks (n=Snak@h-68-164-81-209.snvacaid.dynamic.covad.net) has joined #microformats
- [20:36:31] <fuzzyBSc>
Kevin: The suggestion is that this might be the common case for any explicit atom:summary... that it is really an extract rather than an abstract.
- [20:36:42] <KevinMarks>
great time for a powercut
- [20:36:46] <KevinMarks>
what was the last you got from me?
- [20:36:51] <fuzzyBSc>
Atom allows for either, perhaps with good reason.
- [20:37:03] <fuzzyBSc>
Kevin: "which would imply you could have a 'partial' and a 'full' that overlap"
- [20:38:59] <KevinMarks>
my thought is that if we have semantic overlap we should add clarification
- [20:39:15] <KevinMarks>
distingush extract and abstract
- [20:41:28] <KevinMarks>
I got no responses after tantek saying 'see archives'
- [20:41:36] <KevinMarks>
so if I missed a slice, my apologies
- [20:42:14] <fuzzyBSc>
So a hAtom entry conceptually looks like this: <atom:entry><atom:title>...</atom:title>[<atom:summary-abstract>...</atom:summary-abstract>]<atom:content>...[<atom:summary-extract>...</atom:summary-extract>]...</atom:content></atom:entry>, with metadata spread liberally throughout?
- [20:43:00] <_fil_>
t's what I do in fact
- [20:43:57] <KevinMarks>
well, that will break the mapping back to Atom unless you amke it clear that you can have only one of abstract/partial
- [20:44:19] <KevinMarks>
or that abstract trumps partial in coonverting to atom
- [20:44:55] * fuzzyBSc nods
- [20:47:09] <KevinMarks>
http://intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct2 is what I recall
- [20:47:13] <KevinMarks>
let me check the RFC
- [20:48:25] <KevinMarks>
"The "atom:summary" element is a Text construct that conveys a short
- [20:48:25] <KevinMarks>
summary, abstract, or excerpt of an entry.
- [20:48:25] <KevinMarks>
"
- [20:49:09] <KevinMarks>
not sure what the semntic distinction between 'sumamry' and 'abstract' is in that context
- [20:49:28] <fuzzyBSc>
My current thinking would write that as <div class="entry"><h3 class="summary">...</h3>[<div class="abstract">...</div>]<div class="description">...[<div class="extract">...</div>]...</div></div>, but summary is confusing to atom developers as tantek has pointed out and description is confusing to rss developers as you pointed out.
- [20:50:18] <KevinMarks>
rss2 says
- [20:50:32] <KevinMarks>
description: ithe item synopsis
- [20:51:17] <fuzzyBSc>
:)
- [20:51:30] <fuzzyBSc>
That rss 2.0 doesn't go into a whole lot of detail, does it?
- [20:51:32] <Tantek>
RSS2 is more about practice than what is specified though.
- [20:51:34] <KevinMarks>
nope
- [20:51:38] <KevinMarks>
indeed
- [20:51:47] <Tantek>
thus description = full content in practice
- [20:51:58] <KevinMarks>
so my point is that Atom clears up one semantic confusion
- [20:52:02] <Tantek>
which is the same practice as found in vCalendar/iCalendar
- [20:52:11] <KevinMarks>
distinguishing full/partial
- [20:52:23] <Tantek>
Kevin, no one is arguing that we shouldn't make that distinction.
- [20:52:26] <KevinMarks>
but not distingusging abstract and extract
- [20:52:37] <Tantek>
well that on the otherhand is totally not 80% ;)
- [20:53:20] <KevinMarks>
no, I'm reflecting back your point
- [20:53:28] <Tantek>
in addition, the goal here is NOT to try to redo/improve Atom's semantics
- [20:53:52] <Tantek>
however, the process Atom went thru for naming elements/properties was insufficient for microformats
- [20:54:06] <Tantek>
(and scroll-back is insufficient, unless you scrollback about 2-3 days worth ;)
- [20:54:13] <KevinMarks>
I did
- [20:54:20] <KevinMarks>
and read the email threads
- [20:54:24] <Tantek>
cool
- [20:54:30] <fuzzyBSc>
Interestingly, that page uses excerpt as well.
- [20:55:01] <Tantek>
currently, fuzzy and I are considering both "partial-description" and "excerpt" as alternatives to "atom:summary" as far as a name
- [20:55:02] <Tantek>
fuzzy has documented this on the wiki
- [20:58:05] <KevinMarks>
http://www.imc.org/atom-syntax/mail-archive/msg01153.html
- [20:58:18] <KevinMarks>
which failed...
- [20:58:34] <KevinMarks>
http://www.intertwingly.net/wiki/pie/ContentMustHaveRel
- [21:01:36] <KevinMarks>
the mapping is interesting here in the blog
- [21:02:02] <KevinMarks>
because if you have an extract, the natural markup is to use a span round it
- [21:02:12] <KevinMarks>
as it is a subset fo the post
- [21:02:39] <KevinMarks>
but if you do have an abstract, it appears at the top of the post, and is a distinct piece of text
- [21:02:50] <_fil_>
remember the user will generally not want to edit a summary by hand
- [21:03:20] <KevinMarks>
in Atom, duplicating the extract in another element is an outcome of the hierarchical thinking XML mindset
- [21:03:41] <_fil_>
it's also good for reducing bandwidth, don't forget
- [21:03:53] <KevinMarks>
and doing that in HTML would be odd, and require you to explicitly hide it
- [21:03:58] <_fil_>
(but this can be done otherwise)
- [21:04:26] <fuzzyBSc>
A wysiwyg editor could allow someone to simply select some text and click "excerpt".
- [21:05:07] <fuzzyBSc>
_fil_: That is something hAtom won't be able to do on its own. If you want a partial-text feed to reduce bandwidth you'll have to publish as two separate html pages.
- [21:05:40] <KevinMarks>
it's genreally nto about reducing bandwidth, it's about getting ad impressions from the full page
- [21:07:24] <_fil_>
when you get 800.000 hits a day on your feed, you want to reduce bandwidth :)
- [21:07:27] <fuzzyBSc>
An interesting follow-through on the excerpt bizzo is that you might start seeing them added to blocks around the main content in larger fonts, magazine-style. You would have to be careful that the two concepts of excerpts don't get confused.
- [21:07:37] <_fil_>
otherwise, you're right, no worry
- [21:08:16] <fuzzyBSc>
_fil_: With that much attention you are probably still worried about your ad-words ;)
- [21:08:17] <KevinMarks>
right, but the explanations I've seen for partials have been to do with funding
- [21:09:04] <_fil_>
that's not the way I use them myself. My issue is that I usually deal with very long (magazine) articles
- [21:09:06] <fuzzyBSc>
A site that big has to make money somehow or will go off the air no matter how summarised the content is.
- [21:09:37] <_fil_>
fuzzyBSc: it's not really attention I get, but blind hits
- [21:09:52] <KevinMarks>
eg http://www.janegalt.net/blog/archives/005113.html
- [21:10:07] <_fil_>
my rss feed has been included in the standard Mac OS X list of RSS feeds when you install the French version of Tiger/Safari
- [21:10:27] <_fil_>
maybe 0.1% of these hits actualy result in "visits" (by humans)
- [21:10:39] <_fil_>
I have yet to find the time to analyse the data
- [21:11:55] <fuzzyBSc>
_fil_: Ouch.
- [21:12:01] <mfbot>
[[hatom-issues]] M http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3664 * Tantek * (+1782) Added some feedback and clarifications.
- [21:13:48] <_fil_>
it's kind of a free advertising, but not *that* free given the time I spent fortifying the server :)
- [21:14:42] <KevinMarks>
hm
- [21:29:54] <RobertBachman1>
fuzzyBSc: I've commited a new version with better handling for email addresses.
- [21:47:25] <fuzzyBSc>
Robert: Cool. Should that check for img be looking at @title instead? I thought the result of recent microformats-discussion emails was that alt should be reserved for graphic-impaired humans.
- [21:48:13] <fuzzyBSc>
Also, the value-of template doesn't yet support img in this way. Should it?
- [21:51:07] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [21:54:56] <RobertBachman1>
According to http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_values the check is correct.
- [21:55:38] <RobertBachman1>
AFAIK the recent discussion about @alt vs. @title lead to no change.
- [21:55:51] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [21:55:53] <fuzzyBSc>
Hrmm.. ok.
- [21:55:59] <Tantek>
Robert, Fuzzy, that's correctt
- [21:56:23] <Tantek>
because the alt is *supposed to be* the *user-visible* text description of what is in the image graphic
- [21:57:35] <Tantek>
so far, the *only* use of the 'title' attribute in microformats is specifically with <abbr>, and there, *only* when the human and machine readable versions of the information cannot be reconciled
- [21:58:46] <fuzzyBSc>
Tantek: Is there no general interpretation of img at this stage, or is it always interpreted to @alt for existing microformats?
- [21:59:40] <Tantek>
There is.
- [22:01:01] <Tantek>
'alt' attribute by default for a property value
- [22:01:38] <RobertBachman1>
Tantek: http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_values says "For all properties, when the element for a property is: <abbr>: use the value of the 'title' attribute."
- [22:01:44] <Tantek>
for properties which take a value of type URL/URI, then use the 'src' attribute
- [22:01:53] <Tantek>
Robert, correct
- [22:01:56] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [22:02:13] <fuzzyBSc>
Ok, committed.
- [22:02:16] <Tantek>
but we seek to minimize use of <abbr> in that way
- [22:02:31] <Tantek>
fuzzy, the use of img alt vs. src is documented in hcard-parsing
- [22:02:39] <Tantek>
like I said, definitely read that doc thoroughly :)
- [22:02:49] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [22:03:32] <Tantek>
Kevin Marks wrote: MT and wordpress have long had separate entry boxes for summaries, or partials, but they are less-used
- [22:03:36] <Tantek>
indeed
- [22:03:51] <Tantek>
those separate entry boxes are DEFINITELY not 80/20
- [22:04:02] <Tantek>
hardly anyone I know uses them ever
- [22:04:15] <Tantek>
heck, I'd prefer if they were hidden/concealed in the UI by default
- [22:05:10] <Tantek>
IMHO that kind of feature / user interface addition is the kind of thing you start seeing more and more of in "bloated" applications/interfaces.
- [22:05:35] <Tantek>
exactly the kind of thing we explicitly seek to avoid in microformats
- [22:13:00] <fuzzyBSc>
Tantek: I'm not 100% clear. If we want an email address and are not on an <a href> element, do we fall back to URI handling and also cut off the mailto: or do we give up?
- [22:13:16] <fuzzyBSc>
(or do we fall back to regular property handling?
- [22:13:21] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [22:14:15] <fuzzyBSc>
Oh. Fall back to regular property handling I think.
- [22:15:34] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [22:22:19] <Tantek>
fuzzy, right
- [22:24:53] <fuzzyBSc>
tantek: "if the element for a property has one or more children with a class name of "value"..." does that mean direct children as per xpath, or descendant as per xpath?
- [22:25:37] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [22:26:52] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [22:30:04] <mfbot>
[[hatom-issues]] M http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3665 * Tantek * (+2333) more feedback edits/corrections
- [22:31:20] <Tantek>
fuzzy, in practice it has been only direct children
- [22:31:31] <Tantek>
but we could consider making it descendant
- [22:31:49] <Tantek>
i would ask you to find a real world example that appears to require descendant first ;)
- [22:31:56] <mburns>
can i have a <a href="" rel="licenese nofollow"></a> to indicate that 1. it links to my license and 2. spiders should not give it weight for my linking?
- [22:32:23] <mburns>
put another way, can I stack rel tags and have them both be honored
- [22:33:03] <fuzzyBSc>
tantek: :) I'm happy to leave it as child.
- [22:33:12] <Tantek>
mburns, please see definition of rel in HTML4
- [22:33:17] <Tantek>
and linktypes for that matter
- [22:33:23] <Tantek>
this is an RTFM FAQ. thanks.
- [22:33:31] <Tantek>
fuzzy, ok
- [22:33:54] <Tantek>
fuzzy, and yes, i deliberately made it children to make it more restrictive for now, until someone finds a real world use case and raises an issue with it
- [22:38:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [22:39:49] <KevinMarks>
mburns: the answer is 'yes, you can'
- [22:39:50] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [22:41:27] * KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) Quit ("bye")
- [22:52:53] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
- [22:53:06] <fuzzyBSc>
Tantek: In addition to the hCard-parsing instructions I am currently doing normalise-space on any input. Tools like tidy tend to introduce newlines at inopportune places, and they aren't always ignored by atom parsers.
- [22:53:34] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [22:56:28] <mburns>
thank you.
- [22:59:54] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Read error: 104 (Connection reset by peer))
- [23:00:29] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
- [23:00:30] <jibot>
WildFox is Mr. KDOM. Co-author of kdom, ksvg and kcanvas.
- [23:10:15] <RobertBachman1>
http://microformat.org? Does anybody know this site?
- [23:10:20] * t1m (n=t1m@pool-151-199-47-177.bos.east.verizon.net) Quit (Read error: 110 (Connection timed out))
- [23:10:34] * RobertBachman1 is now known as RobertBachmann
- [23:19:57] <Tantek>
Robert, oh wow, they used to be an another attempt to define their own microformats, but now they appear to be pointing to microformats.org for the formats, and have morphed into a tool.
- [23:21:40] <Tantek>
Please visit Microformats.org to learn more about Microformatting.
- [23:21:40] <Tantek>
Microformat.org runs a template engine service to make it easier to blog with microformats. (Coming Soon)
- [23:21:43] <Tantek>
"
- [23:37:23] * factoryjoe (n=cmessina@adsl-71-139-210-182.dsl.snfc21.pacbell.net) has joined #microformats
- [23:37:23] <jibot>
factoryjoe is Chris Messina, works for Flock, Bar Camp and Rhyzomatic and is working towards open source world domination
- [23:57:37] <RobertBachmann>
Tantek: Hit this site accidently. However seems like there's not much going on there.
These logs were automatically created by mflogbot on
chat.freenode.net
using a modified version of the Java IRC LogBot.
See http://microformats.org/wiki/mflogbot for more information.