Kevin,
On Sat, 2005-12-31 at 15:48 -0800, Kevin Marks wrote:
On Dec 27, 2005, at 3:43 PM, Tantek Çelik wrote:
This means working deliberately to avoid the two cardinal sins that
namespaces typical both enable and encourage:
1. The same term is used to mean two different things
2. Two
Ryan,
On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote:
...I believe that context and specific rules on opacity are
sufficient for making thing unambiguous. Admittedly, with
microformats we tend to walk a fine line here, but its not without
reason- we're trying to optimize for
On 12/31/05 1:58 AM, Benjamin Carlyle [EMAIL PROTECTED]
wrote:
Ryan,
On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote:
...I believe that context and specific rules on opacity are
sufficient for making thing unambiguous. Admittedly, with
microformats we tend to walk a fine line here, but
On Dec 27, 2005, at 3:43 PM, Tantek Çelik wrote:
This means working deliberately to avoid the two cardinal sins that
namespaces typical both enable and encourage:
1. The same term is used to mean two different things
2. Two terms are used to mean the same things
Indeed. In fact this is one
Kevin Marks wrote:
On Dec 27, 2005, at 3:43 PM, Tantek Çelik wrote:
This means working deliberately to avoid the two cardinal sins that
namespaces typical both enable and encourage:
1. The same term is used to mean two different things
2. Two terms are used to mean the same things
Indeed.
On Thu, 2005-12-29 at 08:06 -0500, David Janes -- BlogMatrix wrote:
I'm fairly happy with the way things are named in hAtom right now:
anyone familiar with weblogs and/or Atom will immediately recognize all
the elements. The one (so far) variance is rel=bookmark, which is
defined in HTML so
On Dec 29, 2005, at 7:06 AM, David Janes -- BlogMatrix wrote:
I'm waiting for someone to express a stronger opinion or principle
on how elements should be named, preferably with a reference to a
Wiki page listing it. At this point, there's serious proposals to
rename 75%+ of the elements in
Paul Bryson wrote...
I'm just looking for extra confirmation of this little problem before
touching the wiki. It appears that hAtom uses the class attribute title
for it's title, such as what would go in a heading hn However, the
hCard also uses title, but in a completely different
Paul Bryson wrote:
David Janes -- BlogMatrix wrote...
Nice. I just discovered a bug in my parser that screwed up the title
nesting. Here's [1] the new and improved version.
Does your parser fill the Author from the hCard's FN/NICKNAME field? I am
curious if it would, given that the hCard
Paul Bryson wrote:
You'll want to move class=logo from the li down to the img where it
belongs though.
Done. Is it required to be in an IMG only, or can the IMG act as another
element's value (as I had it previously).
You should be able to now convert the Date Posted into a nice
published
David Janes -- BlogMatrix wrote ...
The author is opaque in that hAtom is not looking for further hAtom
elements within that element. However, hAtom does know that this element
is a hCard and parses it as a hCard.
Ah, that explains a lot. Thanks.
Atamido
David Janes -- BlogMatrix wrote...
You should be able to now convert the Date Posted into a nice published
element.
It isn't already? Honestly, in production I'm not sure that I will have
access to the date in an ISO format. I will include it though for the
example. I'm not a fan of how
12 matches
Mail list logo
