In message
<[EMAIL PROTECTED]>, Brian
Suda <[EMAIL PROTECTED]> writes
>--- there currently are parsing rules for singleton instance of
>properties. Both hCalendar and hCard can take a GEO property. The first
>GEO property found after the root property (vcard or vevent) will be
>used as the GEO for
I'm going to reply to a couple of posts:
> Only if that's a user-configurable option, please. Some of use Operator
> for debugging.
I think the debug mode should always show all the available microformat
elements.
> A parser could provide the ability to extract just the top-level elements.
>
>
On 8/28/07, Mike Kaply <[EMAIL PROTECTED]> wrote:
> hCalendars for experience are interesting, but unuseful as hCalendars.
> And hCards for my employment at a past employer aren't terribly interesting
> either.
--- well, that´s the tricky part. It might be un-interesting to you
personally right t
In message
<[EMAIL PROTECTED]>, Andrew
Jaswa <[EMAIL PROTECTED]> writes
Would it be possible in the case of the hResume to ignore the nested
hCards and hCalendars
Only if that's a user-configurable option, please. Some of use Operator
for debugging.
--
Andy Mabbett
___
In message <[EMAIL PROTECTED]>, Michael MD
<[EMAIL PROTECTED]> writes
>> Should there be a way for people to have this information but not make
>> it available
>> as a vcard or vevent?
>
>or a way to tell what kind of thing the vevent or vcard represents?
>(so that a parser can work out how it sho
Michael MD wrote:
Marking up the venue location is probably the most common use of nested
hCard in hCalendar but the other cases are certainly possible.
How would a parser know which it is?
A parser could provide the ability to extract just the top-level elements.
The other elements could be
Should there be a way for people to have this information but not make
it available as a vcard or vevent?
The user-action class or new protocols proposed in the Firefox 3
thread could address this problem (10 hCards in an hResume). Since
these pieces of microformatted content probably would
Should there be a way for people to have this information but not make
it available
as a vcard or vevent?
or a way to tell what kind of thing the vevent or vcard represents?
(so that a parser can work out how it should be displayed based on criteria
chosen by the user)
I think there may be an
On 8/27/07, Mike Kaply <[EMAIL PROTECTED]> wrote:
> And hCards for
> my employment at a past employer aren't terribly interesting either.
I brought this up before[1]. While its the semantic thing to do its
not overly useful.
> Should there be a way for people to have this information but not ma
I wanted Jason to bring this up on the list because it is an
interesting discussion.
We display lots of stop in Operator (especially in hResume) that can't
actually be used.
hCalendars for experience are interesting, but unuseful as hCalendars.
And hCards for
my employment at a past employer aren
I've recently started to look into using some microformats on one of my
projects and have been playing with Operator to get an idea of how they are
being used elsewhere.
Operator is a great way to see what microformats are contained on a page, but
I think it might confuse the average user when
11 matches
Mail list logo
