hidden microformats

Hi there

This is my first post here, sorry if I'm not posting in the
right place.
I'm adding uformats support in my application and I have to
say I'm
quite intrigued but I'm facing with 3 problems

1) Sometime I have to change the code of my pages in places
where I
would prefer to have a more clean structure.
2) Sometime I would like to to the uformats on my pages
information
that I have in my application but that are not rendered in
the current
page, and adding/hiding these information in the original
structure to
complete the rendered information, make my page really
dirty.
3) In some cases I would like to add a uformat containing
informations
that are not present at all on the page but that are deeply
connected
with the context of the page.

Now, what I was thinking is to add in the footer of my pages
a sort of
container (let's say a div) with all  the microformats that
I want to
provide to my end user. Basicly this div will be not visible
because
of style setting , it will be just available for parsing
purpouse.

What I'm wondering is if this approach makes any sense since
microformats are more oriented to give semantic/parsability
to the
visible content. I was thinking as an alternative to provide
the
possibility to download directly the vcard or whatever, but
I still
would preferer microformats since they sounds for me a bit
more
discoverable than a link to the vcard or to the final
object.

One last question that I have is about the screen reader for
impaired
user. Is there already a standard/proposal to signal that a
section of
the page is dedicated to microformats, or maybe I should
just use
something to avoid the processing of the container by the
screen
reader.

That's all, thank you for the attention.

Paolo
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

HI Paolo,

In general "hidden" microformats are frowned upon,
as they cause all  
sorts of problems.   Could you give an example of the types
of  
"hidden" information you want/need to provide?

-- Ernie P.

On Sep 27, 2006, at 2:56 PM, Paolo Negri wrote:

> Hi there
>
> This is my first post here, sorry if I'm not posting in
the right  
> place.
> I'm adding uformats support in my application and I
have to say I'm
> quite intrigued but I'm facing with 3 problems
>
> 1) Sometime I have to change the code of my pages in
places where I
> would prefer to have a more clean structure.
> 2) Sometime I would like to to the uformats on my pages
information
> that I have in my application but that are not rendered
in the current
> page, and adding/hiding these information in the
original structure to
> complete the rendered information, make my page really
dirty.
> 3) In some cases I would like to add a uformat
containing informations
> that are not present at all on the page but that are
deeply connected
> with the context of the page.
>
> Now, what I was thinking is to add in the footer of my
pages a sort of
> container (let's say a div) with all  the microformats
that I want to
> provide to my end user. Basicly this div will be not
visible because
> of style setting , it will be just available for
parsing purpouse.
>
> What I'm wondering is if this approach makes any sense
since
> microformats are more oriented to give
semantic/parsability to the
> visible content. I was thinking as an alternative to
provide the
> possibility to download directly the vcard or whatever,
but I still
> would preferer microformats since they sounds for me a
bit more
> discoverable than a link to the vcard or to the final
object.
>
> One last question that I have is about the screen
reader for impaired
> user. Is there already a standard/proposal to signal
that a section of
> the page is dedicated to microformats, or maybe I
should just use
> something to avoid the processing of the container by
the screen
> reader.
>
> That's all, thank you for the attention.
>
> Paolo
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Hi Ernie

Thanks for replying

The application I'm working on is rich in calendar items and
people.

On some pages I have all the infos about these items and I
can produce
very complete uformats. On other pages I render let's say
just the
name and the email of someone and it doesn't make sense to
provide a
less complete hcard than in a different page, and I
absolutely can't
add the extra information (address, role) as visible.

Another problem is that there are a lot of data on the page
and the
bits to build the uformats are well spreaded on it so I have
to put
the main <div> or whatever at a very high level of the
dom which is
not really nice because it tends to group even some items
that are not
really in his context.

Paolo

On 27/09/06, Dr. Ernie Prabhakar <drernieopendarwin.org> wrote:
> HI Paolo,
>
> In general "hidden" microformats are frowned
upon, as they cause all
> sorts of problems.   Could you give an example of the
types of
> "hidden" information you want/need to
provide?
>
> -- Ernie P.
>
> On Sep 27, 2006, at 2:56 PM, Paolo Negri wrote:
>
> > Hi there
> >
> > This is my first post here, sorry if I'm not
posting in the right
> > place.
> > I'm adding uformats support in my application and
I have to say I'm
> > quite intrigued but I'm facing with 3 problems
> >
> > 1) Sometime I have to change the code of my pages
in places where I
> > would prefer to have a more clean structure.
> > 2) Sometime I would like to to the uformats on my
pages information
> > that I have in my application but that are not
rendered in the current
> > page, and adding/hiding these information in the
original structure to
> > complete the rendered information, make my page
really dirty.
> > 3) In some cases I would like to add a uformat
containing informations
> > that are not present at all on the page but that
are deeply connected
> > with the context of the page.
> >
> > Now, what I was thinking is to add in the footer
of my pages a sort of
> > container (let's say a div) with all  the
microformats that I want to
> > provide to my end user. Basicly this div will be
not visible because
> > of style setting , it will be just available for
parsing purpouse.
> >
> > What I'm wondering is if this approach makes any
sense since
> > microformats are more oriented to give
semantic/parsability to the
> > visible content. I was thinking as an alternative
to provide the
> > possibility to download directly the vcard or
whatever, but I still
> > would preferer microformats since they sounds for
me a bit more
> > discoverable than a link to the vcard or to the
final object.
> >
> > One last question that I have is about the screen
reader for impaired
> > user. Is there already a standard/proposal to
signal that a section of
> > the page is dedicated to microformats, or maybe I
should just use
> > something to avoid the processing of the container
by the screen
> > reader.
> >
> > That's all, thank you for the attention.
> >
> > Paolo
> > _______________________________________________
> > microformats-discuss mailing list
> > microformats-discussmicroformats.org
> > http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Hmm.  Might it work for you to have an "Address
Book" or "Calendar"  
page (or subsection) with the full information, and simply
link to  
that from the "mention"?

The reasons is that hidden microformats tend to be (i) be
fragile and  
hard to maintain, plus (ii) susceptible to spam, and this
overlooked  
by search engines.

-- Ernie P.

On Sep 27, 2006, at 5:15 PM, Paolo Negri wrote:

> Hi Ernie
>
> Thanks for replying
>
> The application I'm working on is rich in calendar
items and people.
>
> On some pages I have all the infos about these items
and I can produce
> very complete uformats. On other pages I render let's
say just the
> name and the email of someone and it doesn't make sense
to provide a
> less complete hcard than in a different page, and I
absolutely can't
> add the extra information (address, role) as visible.
>
> Another problem is that there are a lot of data on the
page and the
> bits to build the uformats are well spreaded on it so I
have to put
> the main <div> or whatever at a very high level
of the dom which is
> not really nice because it tends to group even some
items that are not
> really in his context.
>
> Paolo
>
> On 27/09/06, Dr. Ernie Prabhakar <drernieopendarwin.org> wrote:
>> HI Paolo,
>>
>> In general "hidden" microformats are
frowned upon, as they cause all
>> sorts of problems.   Could you give an example of
the types of
>> "hidden" information you want/need to
provide?
>>
>> -- Ernie P.
>>
>> On Sep 27, 2006, at 2:56 PM, Paolo Negri wrote:
>>
>> > Hi there
>> >
>> > This is my first post here, sorry if I'm not
posting in the right
>> > place.
>> > I'm adding uformats support in my application
and I have to say I'm
>> > quite intrigued but I'm facing with 3 problems
>> >
>> > 1) Sometime I have to change the code of my
pages in places where I
>> > would prefer to have a more clean structure.
>> > 2) Sometime I would like to to the uformats on
my pages information
>> > that I have in my application but that are not
rendered in the  
>> current
>> > page, and adding/hiding these information in
the original  
>> structure to
>> > complete the rendered information, make my
page really dirty.
>> > 3) In some cases I would like to add a uformat
containing  
>> informations
>> > that are not present at all on the page but
that are deeply  
>> connected
>> > with the context of the page.
>> >
>> > Now, what I was thinking is to add in the
footer of my pages a  
>> sort of
>> > container (let's say a div) with all  the
microformats that I  
>> want to
>> > provide to my end user. Basicly this div will
be not visible  
>> because
>> > of style setting , it will be just available
for parsing purpouse.
>> >
>> > What I'm wondering is if this approach makes
any sense since
>> > microformats are more oriented to give
semantic/parsability to the
>> > visible content. I was thinking as an
alternative to provide the
>> > possibility to download directly the vcard or
whatever, but I still
>> > would preferer microformats since they sounds
for me a bit more
>> > discoverable than a link to the vcard or to
the final object.
>> >
>> > One last question that I have is about the
screen reader for  
>> impaired
>> > user. Is there already a standard/proposal to
signal that a  
>> section of
>> > the page is dedicated to microformats, or
maybe I should just use
>> > something to avoid the processing of the
container by the screen
>> > reader.
>> >
>> > That's all, thank you for the attention.
>> >
>> > Paolo
>> >
_______________________________________________
>> > microformats-discuss mailing list
>> > microformats-discussmicroformats.org
>> > http://microformats.org/mailman/listinfo/microforma
ts-discuss
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discussmicroformats.org
>> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 9/27/06, Paolo Negri <hungrylistgmail.com> wrote:
> On some pages I have all the infos about these items
and I can produce
> very complete uformats. On other pages I render let's
say just the
> name and the email of someone and it doesn't make sense
to provide a
> less complete hcard than in a different page, and I
absolutely can't
> add the extra information (address, role) as visible.

You might be able to link to the more complete information
from the
simple content.  There's also nothing wrong with marking up
the
simpler content with microformats; it's still contact
information,
even if some of it is missing.

> Another problem is that there are a lot of data on the
page and the
> bits to build the uformats are well spreaded on it so I
have to put
> the main <div> or whatever at a very high level
of the dom which is
> not really nice because it tends to group even some
items that are not
> really in his context.

I have a vague feeling that there's a more basic problem
with what
you're trying to do.  Could you give a link to an example of
one or a
couple of these pages?  You can fill them in with bogus data
if
there's any confidentiality, and you can use a pastebin if
you don't
have a place to host them.

- David
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 28 Sep 2006, at 01:15, Paolo Negri wrote:
> On some pages I have all the infos about these items
and I can produce
> very complete uformats. On other pages I render let's
say just the
> name and the email of someone and it doesn't make sense
to provide a
> less complete hcard than in a different page, and I
absolutely can't
> add the extra information (address, role) as visible.

Perhaps the better solution for this would be to revive (and
perhaps  
conclude) the ‘linking to a definitive microformat’ idea
which has  
popped up every so often. In short, provide a rel value to
contain  
within an hCard or hEvent which links to the page with the
full  
information. Parsers are then instructed to follow that link
where  
appropriate to get complete information.

That's still a work-in-progress though, so my advice for now
is that  
as Ernie Prabhaker says, there's nothing wrong with having
smaller,  
less complete hEvents, they're still valid microformats. For
now,  
just make sure you're linking to the full page from them and
if in  
the near future a suitable rel value is designed to parse
those  
links, you can add it in with no destruction or reworking
required in  
your application.

Ben
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 28/9/2006, "Ben Ward" <listsben-ward.co.uk> wrote:

>Perhaps the better solution for this would be to revive
(and perhaps  
>conclude) the ‘linking to a definitive microformat’
idea which has  
>popped up every so often. In short, provide a rel value
to contain  
>within an hCard or hEvent which links to the page with
the full  
>information. Parsers are then instructed to follow that
link where  
>appropriate to get complete information.

That rather depends on whether the objective is to publish
discoverable
information, or to make published information discoverable.
My primary
goal is always the latter, with the former a noble secondary
objective.

>That's still a work-in-progress though, so my advice for
now is that  
>as Ernie Prabhaker says, there's nothing wrong with
having smaller,  
>less complete hEvents, they're still valid microformats.
For now,  
>just make sure you're linking to the full page from them
and if in  
>the near future a suitable rel value is designed to
parse those  
>links, you can add it in with no destruction or
reworking required in  
>your application.

More than nothing wrong with - there's everything right with
publishing
smaller, less complete hEvents.

If it's an event then it should be marked up as an event in
the best way
possible, regardless of the fact that more comprehensive
information is
available elsewhere. If I were to publish a list of some of
Shakespere's plays, I'd still mark it up as a list even
though
Wikipedia has a more comprehensive list than mine.

In the first instance we must be concerned with adding the
correct
semantics to the data we're publishing, not with how it may
or may not
be used.

drew.

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Hi all

Sorry for late reply

I can just tell how I sorted out my stuff. For the tricky
structure of
the divs I've just reviewed with the smallest possibile set
of change
the structure of the page to have the content to build the
uformat
included in a div which is really semantic now.
I wasted some hours doing this but now I can sleep at night.

I decided to provide uformats just where the most complete
infos are
available. It makes sense for the user to expect complete
infos where
they actually are.
My idea is "uformats will probably be where you would
look to take
physical notes" Now you'll say that I can't tell where
the users would
look, and this is a good point...

I won't provide partial uformats because I'm afraid of that
the user
can be confused by different versions of the data for the
same
event/person. I agree on that even a partial information is
semantic,
but since now the usage of uformats is more like a
transformation/download of vcards/icalendar (and my
application is
likely to encourage this type of usage) than an highlighting
of the
semantic of the page, I just want to provide one version of
these
objects.
I'll be happy to change this approach when I'll see more
clearly how
uformats are going to be used and how the users will be
helped by
browsers/apps in using them. I'll just keep an eye to have a
sort of
uformats aware page design, just to be ready, even if I have
to say,
excluded 2 tricky cases adding microformats to my content
was pretty
natural.
I don't think I'm going to add link to uformats because I
like the
idea to have them as a rich collateral presence of data on
the page
more than a sort of resource that need to be pointed.
Obviously this
is just my opinion and is related to this specific
application
perspective.

Well, and in the end I have to thank you all for this really
interesting discussion.

Paolo


On 28/09/06, Drew McLellan <listsallinthehead.com> wrote:
> On 28/9/2006, "Ben Ward" <listsben-ward.co.uk> wrote:
>
> >Perhaps the better solution for this would be to
revive (and perhaps
> >conclude) the 'linking to a definitive microformat'
idea which has
> >popped up every so often. In short, provide a rel
value to contain
> >within an hCard or hEvent which links to the page
with the full
> >information. Parsers are then instructed to follow
that link where
> >appropriate to get complete information.
>
> That rather depends on whether the objective is to
publish discoverable
> information, or to make published information
discoverable. My primary
> goal is always the latter, with the former a noble
secondary objective.
>
> >That's still a work-in-progress though, so my
advice for now is that
> >as Ernie Prabhaker says, there's nothing wrong with
having smaller,
> >less complete hEvents, they're still valid
microformats. For now,
> >just make sure you're linking to the full page from
them and if in
> >the near future a suitable rel value is designed to
parse those
> >links, you can add it in with no destruction or
reworking required in
> >your application.
>
> More than nothing wrong with - there's everything right
with publishing
> smaller, less complete hEvents.
>
> If it's an event then it should be marked up as an
event in the best way
> possible, regardless of the fact that more
comprehensive information is
> available elsewhere. If I were to publish a list of
some of
> Shakespere's plays, I'd still mark it up as a list even
though
> Wikipedia has a more comprehensive list than mine.
>
> In the first instance we must be concerned with adding
the correct
> semantics to the data we're publishing, not with how it
may or may not
> be used.
>
> drew.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 28/09/06, Paolo Negri <hungrylistgmail.com> wrote:
> I won't provide partial uformats because I'm afraid of
that the user
> can be confused by different versions of the data for
the same
> event/person. I agree on that even a partial
information is semantic,
> but since now the usage of uformats is more like a
> transformation/download of vcards/icalendar (and my
application is
> likely to encourage this type of usage) than an
highlighting of the
> semantic of the page, I just want to provide one
version of these
> objects.

I don't think you should really focus on what the *current*
use of
uformats is - let's face it, most web users aren't even
aware of them
right now. I don't think users are confused by different
versions of
data - for instance, on the "home page" of one
site I've worked on, we
have some succinct descriptions of events; when you click
through the
page, you have the fuller description. Both should be marked
up as
microformatted data, imho. However, it's only the "full
description"
that we submit to pingerati, for instance.

But there are still reasons for putting the ufs onto the
limited
version, on the front-page - it provides a very simple
scrapi to
upcoming events, for instance.

That said: if you've got multiple representations of the
same data on
the same page (which I don't think you do, but wanted to
check), then
it's probably confusing for a user from a visual/usability
perspective, let alone a uf one. That's the "design for
humans first"
mantra... once that's sorted, it's not too hard to design
for the
"machines second".

Usage vs purpose is chicken-and-egg, and I don't think you
should
limit implementation based on current usage patterns.

> I don't think I'm going to add link to uformats because
I like the
> idea to have them as a rich collateral presence of data
on the page
> more than a sort of resource that need to be pointed.
Obviously this
> is just my opinion and is related to this specific
application
> perspective.

No, that sounds about right to me!
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss