RE: [uf-discuss] Microformats and Firefox 3
2. Microformats are in page, and there needs to be some way
to indicate the microformats are available on the page that
doesn't offend page authors. How can we accomplish this?
I second the opinion that this is a design issue and therefore should be
handled by css in some way. This would fit into the web design paradigm
of markup for data, css for design. My slightly different css approach;
create custom css property:value pairs, such as that of
-moz-border-radius.
So some poor examples that give an idea (and would warrant derivation
from someone better than I):
#hcard1 {
-moz-uf-hcard-display: block bottom; //instructs FF3 that the author
wishes ff3 to show an hcard icon after the hcard
-moz-uf-hcard-margin: 5px;
}
#hcard2 {
-moz-uf-hcard-display: block top; //author wants this icon to be at the
top to fit in with page design a little better
-moz-uf-map-display: block top; //author wants a view address map icon
as well
}
#hcard3 {
-moz-uf-hcard-display: none; //author wants this icon hidden
}
.hcard {
-moz-uf-hcard-icon: icon(thenicesmallgreenicon); //all hcards have the
small green icon
}
.hcard:hover {
-moz-uf-hcard-menu: dropdown; //hovering the icon shows an action drop
down menu
}
Tony
+ The Forestry Commission's computer systems may be monitored and
communications carried out on them recorded, to secure the effective operation
of the system and for other lawful purposes. +
The original of this email was scanned for viruses by the Government Secure
Intranet (GSi) virus scanning service supplied exclusively by Cable Wireless
in partnership with MessageLabs.
On leaving the GSi this email was certified virus-free
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Farndon, Tony skrev:
2. Microformats are in page, and there needs to be some way
to indicate the microformats are available on the page that
doesn't offend page authors. How can we accomplish this?
I second the opinion that this is a design issue and therefore should be
handled by css in some way. This would fit into the web design paradigm
of markup for data, css for design. My slightly different css approach;
create custom css property:value pairs, such as that of
-moz-border-radius.
If something should add anything it should be added by a javascript
which the Firefox people may very well supply. To have CSS instructing
Firefox to add something into the HTML-data seems wrong, it doesn't
really separate the data and content from the design. If something
should instruct anything to add new HTML-data to a document it has to be
either the HTML itself or JavaScripts. CSS can be used to style what's
added, but should do nothing more than that in my opinion because it's
only purpose is to add a deisgn and if it's removed the page should work
equally well - only not as beutiful as with the CSS added.
Let's just have a javascript like the one here below. If Firefox
supplies a microformats object by default then all webpages can rely on
that in Firefox it can easily be extended to add support for newer
microformats like Prototype and other javascript frameworks today
extends basic DOM-objects and such. If someone would like they could
even code their own implementation of such a solution which can be used
in other browsers than Firefox until those browsers adds support
themselves either directly or indirectly through extensions.
script type=text/javascript
if (typeof microformats.hcard == 'object') {
// Add some actions to the page in any way, like this simple and
bad way
document.write('a href=#
onclick=microfrmats.hcard.add(this.parentNode);Add to addressbook/a');
}
/style
There are probably better arguments for choosing a solution like this
over a CSS and/or HTML based solution, I hope someone more experienced
than me can tell us some of them.
/ Pelle W
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats and Firefox 3
If something should add anything it should be added by a javascript... CSS is frequently used to *add* and place onto a page, be it a background image, a border, etc What I am saying is rather than add say, a background image, you use CSS to add/place a microformat icon. How this icon behaves when you click on it is designed by FF, what you are saying to the web designer is where do you want this dropdown/menu/action/whatever container to appear, if at all. If something should instruct anything to add new HTML-data to a document it has to be either the HTML itself or JavaScripts. This is where I have got confused over what this whole topic is this about: the UI or adding actions (hence my reply was to point 2 from Mike). My impression is that it is a UI issue of how you notify the user that there is uf present, where it is on the page and what actions are available, without stepping on the toes of the designer and the users browsing experience. This is a *design* issue which to me implies a css solution. There are probably better arguments for choosing a solution like this over a CSS and/or HTML based solution, I hope someone more experienced than me can tell us some of them. There are of coarse many valid reasons for a non-js approach. How many turn off, or control js with extensions compared to turning off/controlling css?? I would wager less for the latter. Tony + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Hello everyone.
Great work thus far.. just want to drop my 2cents.
1) I don't think Dimitri's text was very clear on this aspect in
particular, but I believe it would improve the UXP and still give
control to the publisher.
Why not mixing the suggestion of dimitry (which seems like a very
well-thought solution) with the CSS one:
- when the user hovers on the margin-mark, the user-agent should
'target' to the (root?) element (like what's done with the #anchor in
urls) and that would allow the publishers to specify the
looks/highlight accordingly. Like:
.vcard:target {
border:1px solid red;
}
or even
.vcard:target .actions{
visibility: visible;
}
(without constraining the publisher to a specific class name or element)
2) Also, should there be only ONE way of displaying uf content? or
should the user have an option? I believe the operator's default way
(toolbar) is also pretty darn good and should not be ignored or would
it go against/collide with the work Michael has been doing?
Cheers,
André Luís
On 9/5/07, Pelle W [EMAIL PROTECTED] wrote:
Farndon, Tony skrev:
2. Microformats are in page, and there needs to be some way
to indicate the microformats are available on the page that
doesn't offend page authors. How can we accomplish this?
I second the opinion that this is a design issue and therefore should be
handled by css in some way. This would fit into the web design paradigm
of markup for data, css for design. My slightly different css approach;
create custom css property:value pairs, such as that of
-moz-border-radius.
If something should add anything it should be added by a javascript
which the Firefox people may very well supply. To have CSS instructing
Firefox to add something into the HTML-data seems wrong, it doesn't
really separate the data and content from the design. If something
should instruct anything to add new HTML-data to a document it has to be
either the HTML itself or JavaScripts. CSS can be used to style what's
added, but should do nothing more than that in my opinion because it's
only purpose is to add a deisgn and if it's removed the page should work
equally well - only not as beutiful as with the CSS added.
Let's just have a javascript like the one here below. If Firefox
supplies a microformats object by default then all webpages can rely on
that in Firefox it can easily be extended to add support for newer
microformats like Prototype and other javascript frameworks today
extends basic DOM-objects and such. If someone would like they could
even code their own implementation of such a solution which can be used
in other browsers than Firefox until those browsers adds support
themselves either directly or indirectly through extensions.
script type=text/javascript
if (typeof microformats.hcard == 'object') {
// Add some actions to the page in any way, like this simple and
bad way
document.write('a href=#
onclick=microfrmats.hcard.add(this.parentNode);Add to addressbook/a');
}
/style
There are probably better arguments for choosing a solution like this
over a CSS and/or HTML based solution, I hope someone more experienced
than me can tell us some of them.
/ Pelle W
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats and Firefox 3
To try and give where I am coming from some context, this is how I see
it all working in my head:
FF3 has a set of (3?) methods for alerting/displaying/provding actions
for uF
1) An Operator style toolbar
2) An Operator Style status icon
3) Within the content of the page (+1 and then some for dimitrys margins
approach, best I've seen yet, visible yet unobtrusive whilst still
provding some sort of location on the page display - aside: default next
to scrollbar, statisically more content on lefthand side of page)
Users can choose any or all of the three options. However, option 3
might well place something on a webpage that the designer feels strongly
against (for example a left navigation pane that keeps getting hidden by
the margin marker approach for people that prefer margin markers on the
left).
This is where you turn to css and a designer can simply declare
.vcard {
-moz-uf-display: none;
}
This tells FF3 NOT to display the margin markers for that page
regardless of whether the user has it on. This then allows the designer
to add his own uF icons.
Now onto actions. And this is where I like the protocol approach. As a
designer, you can turn off all the option 3 page uF icons as above, add
you own div/a/img etc eg a href=uf://export.hcardAdd to Address
Book/a
In 4 simple lines, you have told FF3 to stop adding stuff over your
page, given the control of the action to yourself and where it appears.
T.
+ The Forestry Commission's computer systems may be monitored and
communications carried out on them recorded, to secure the effective operation
of the system and for other lawful purposes. +
The original of this email was scanned for viruses by the Government Secure
Intranet (GSi) virus scanning service supplied exclusively by Cable Wireless
in partnership with MessageLabs.
On leaving the GSi this email was certified virus-free
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
On 9/5/07, André Luís [EMAIL PROTECTED] wrote:
Hello everyone.
- when the user hovers on the margin-mark, the user-agent should
'target' to the (root?) element (like what's done with the #anchor in
urls) and that would allow the publishers to specify the
looks/highlight accordingly. Like:
.vcard:target {
border:1px solid red;
}
or even
.vcard:target .actions{
visibility: visible;
}
(without constraining the publisher to a specific class name or element)
I agree with many of the previous sentiments. Dimitri's mockups are
an excellent idea and I also think it would be great to style the uf
targets via CSS :target as suggested by André. I would just like to
suggest we keep in mind the way Tails Export displays the available
microformats on a page. As opposed to Operator (which is an
invaluable tool) which uses perhaps too much menu nesting, I feel the
sidebar is the perfect place to organize this type of content.
Coupled with Dimitri's margin-marks, we could have a winner.
Jason
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Thanks for the comments on the margin-marks concept. I sincerely appreciate that. I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. Can :focus be used somehow instead? This would require an element to accept keyboard or mouse focus, though... :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats and Firefox 3
Thanks for the comments on the margin-marks concept. I sincerely appreciate that. Credit where credit is due! I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. I have no interpretation of this I'm afraid. I would say that no solution should break css specs, even ever so slightly. Does *adding* to css break spec compliance Eg .vcard:uftarget or -moz-whatever ?? (if so, scrap everything I said in my previous posts!) Tony + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Dimitri, That was exactly why I suggested :target instead of :focus. I think ufs shouldn't _require_ links or other focus-eable elements. And I'm with you with the worries on pushing the meaning of the spec... is there a more meaningful alternative I don't know about? And I'm with Tony (and others) on the protocol approach. My concern is: how do we keep the actions standard? The user-agent must be able to recognize it so we can't have some of us publishing export.hcard and others save.hcard. An API would be nice. Also, don't forget about languages. If it's up to the user agent to insert action buttons it's imperative that all languages are supported. It would be so not-cool to have a page in mandarin sporting action-buttons in english, don't you think? Cheers, André Luís On 9/5/07, Dimitri Glazkov [EMAIL PROTECTED] wrote: Thanks for the comments on the margin-marks concept. I sincerely appreciate that. I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. Can :focus be used somehow instead? This would require an element to accept keyboard or mouse focus, though... :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Firefox 3 Javascript Semantic Data UI Control (was: Microformats and Firefox 3)
Dimitri Glazkov wrote: I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. There is another option available. Songbird has released a specification for a Javascript object that can be used to control some of the functionality in the browser. http://developer.songbirdnest.com/documentation/trunk/webpageapi/files/sbIRemotePlayer-idl.html Operator/Firefox could provide something along the same lines to allow publishers to disable the browser UI and provide their own via CSS. Here's how it could work: The SemanticDataUI object would be accessible, from Javascript, using the “semanticDataUI” global variable attached to the currently loaded document. A publisher could disable the semantic data UI in any browser by running the following line of Javascript: semanticDataUI.disableUI(); Users could control whether or not they allow web pages to disable the Semantic Data UI. Most would probably allow web pages to disable the semantic data UI. Publishers could manually disable the Semantic Data UI and use CSS to mark up their hCards, hCalendars, and hAudios. This would give cross-browser UI control to both the users and the publishers without having to do any CSS magic. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Firefox 3 Javascript Semantic Data UI Control
Manu Sporny wrote: Dimitri Glazkov wrote: I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. The SemanticDataUI object would be accessible, from Javascript, using the “semanticDataUI” global variable attached to the currently loaded document. A publisher could disable the semantic data UI in any browser by running the following line of Javascript: semanticDataUI.disableUI(); Users could control whether or not they allow web pages to disable the Semantic Data UI. Most would probably allow web pages to disable the semantic data UI. Publishers could manually disable the Semantic Data UI and use CSS to mark up their hCards, hCalendars, and hAudios. This would give cross-browser UI control to both the users and the publishers without having to do any CSS magic. Interesting! Perhaps semanticData.ui.disable() instead and have functions like semanticData.getDataById and other DOM-like functions and when you have some data you have fooDataObject.action() or something and fooDataObject.dataType just like nodeType exists in DOM etc. Something like a SDOM (SemanticDataObjectModel) standard? / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats and Firefox 3
And I'm with Tony (and others) on the protocol approach. I should, however, add that I do have one concern about the protocol approach; it does not degrade gracefully. Users of FF2, or IE7 or Safari etc will just get a big old unknown protocol error. This is easily countered by the designer checking for the navigator with js or using !--[if IE] and hiding the protocol actions element, but this of course requires extra work on their part. T. + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Farndon, Tony wrote: And I'm with Tony (and others) on the protocol approach. I should, however, add that I do have one concern about the protocol approach; it does not degrade gracefully. Users of FF2, or IE7 or Safari etc will just get a big old unknown protocol error. This is easily countered by the designer checking for the navigator with js or using !--[if IE] and hiding the protocol actions element, but this of course requires extra work on their part. T. That issue could perhaps be solved by either browser extensions or separate programs with similar roles as feed readers has for RSS. It would perhaps not be too mad of an idea to have Thunderbird or something taking care of the microformats for such browsers since Thunderbird and such programs have greater use of the data contained in the microformats. Like the hCard into Thunderbirds addressbook and the hCalendars into the Lightning extension. Alex Faaborg wrote a clever mail about this earlier and presented a few issues and a few possibilites related to protocols. It was then discussed that perhaps there should be one protocl for each microformat? That would if so enable different programs to easily take care of different microformats. You'll find Faaborg's mail here (is this the usual way to share an older mail on a mailing list or how is more common?): http://microformats.org/discuss/mail/microformats-discuss/2007-August/010536.html / Pelle W ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats and Firefox 3
Alex Faaborg wrote a clever mail about this earlier and presented a few issues and a few possibilites related to protocols. It was then discussed that perhaps there should be one protocl for each microformat? That would if so enable different programs to easily take care of different microformats. You'll find Faaborg's mail here (is this the usual way to share an older mail on a mailing list or how is more common?): http://microformats.org/discuss/mail/microformats-discuss/2007 -August/010536.html Yes, apologies, I do lurk on this list, but sometimes it is just too overwhelming so sit back and watch. Am up for posting today, so probably repeating whats been said before. Just browsed the archives a bit and quite like Scott's approach of ul class=user-actionslia href=http://mozilla.org/add_to_address_book;... Instead of a protocol, FF could intercept this url. Rather than opening up a webpage, it carries out the action. It degrades better so that FF2/IE/Safari users are directed to an actual page describing microformats in Firefox 3 rather than receiving an unknown protocol error. Easy to add plugins/extensions to these other browsers to intercept the url as well. One might want to use a browser agnostic url though. So FF3 intercepts the url click of an href of http://actions.microformats.org?q=add-to-address-book, stops the propogation if appropriate, grabs the q param, looks for the parent container and adds it to the addressbook. Other browsers will be directed and get to read a nice page describing hcards and how you can add them to an address book as vcards using FF3/IE with this plugin/FF2 with Operator 0.9/Safari with that plugin if ever Apple create a decent plugin architecture etc. If not in the parent hcard container, add another param for the hcard id, this would allow you to put actions anywhere on your page and FF can assess the url to say, ok, this is a uF action, you want to add to the address book, and it is that hcard, ok. http://actions.microformats.org?q=add-to-address-bookid=hcard-id http://actions.microformats.org?q=map-addressid=hcard-id http://actions.microformats.org?q=add-to-calendarid=hcal-id Similar to the way RSS feeds are handled in FF2/3 by choosing live boookmark, google reader, bloglines etc, a pref pane decides what happens, is it added to thunderbird contacts, some address book website etc That's enough repeating from me today. T. + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Need for plain-language intros for each microformat
Tantek =?ISO-8859-1?B?xw==?=elik wrote: Syntactically the URI would still work, however, semantically it would have been broken, that is, it is bad to not only change URIs so that they 404 and just plain don't work, but it is also bad to change the *meaning* of that URI. As long as there is a clear link to the specification from the explanation, then I disagree that it's really changed the meaning of the link target. If I were to add a link today like: pYou can read the a href=http://microformats.org/wiki/hCard; hCard specification/a for more information./p and tomorrow that page were replaced by an introductory page, I doubt I'd want to change the link. People visiting my page could still click on the link and would find the specification, albeit indirectly. The real danger is with #fragment identifiers. :-( -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 1 day, 7:59.] TrivialEncoder/0.2 http://tobyinkster.co.uk/blog/2007/08/19/trivial-encoder/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Need for plain-language intros for each microformat
On 5 Sep 2007, at 20:18, Toby A Inkster wrote: Syntactically the URI would still work, however, semantically it would have been broken, that is, it is bad to not only change URIs so that they 404 and just plain don't work, but it is also bad to change the *meaning* of that URI. As long as there is a clear link to the specification from the explanation, then I disagree that it's really changed the meaning of the link target. Whilst the ‘meaning’ in terms of microformats.org/wiki/hcard being a page about hCard would still be valid, the context in which that URL is used by publishers on the internet. Tutorials may link to the entire page accompanied by the text ‘read the hCard specification’, whilst other pieces could be linking to fragment identifiers within the page to reference a specific part of the spec. As such, I also oppose that the specifications be moved from the current root locations. Potentially we could agree that future specifications include ‘-spec’ in the URL, but current URLs and content IDs need to remain the same. I would move that plain text ‘-info’ pieces be written for each spec and an introductory paragraph from each be placed at the top of each spec to more accessibly introduce the document, with a link to the ‘All about hCard’ page. Regards, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Need for plain-language intros for each microformat
On Sep 5, 2007, at 2:34 PM, Ben Ward wrote: Syntactically the URI would still work, however, semantically it would have been broken, that is, it is bad to not only change URIs so that they 404 and just plain don't work, but it is also bad to change the *meaning* of that URI. As long as there is a clear link to the specification from the explanation, then I disagree that it's really changed the meaning of the link target. Whilst the ‘meaning’ in terms of microformats.org/wiki/hcard being a page about hCard would still be valid, the context in which that URL is used by publishers on the internet. Tutorials may link to the entire page accompanied by the text ‘read the hCard specification’, whilst other pieces could be linking to fragment identifiers within the page to reference a specific part of the spec. I think if we all take a step back we'll find this tangent is rather pointless. Two proposals have been made: 1) change the current root pages to be intros and create new -spec pages or 2) leave the specs where they are and create new -intro pages. I've seen a few people object to #1 and no one object to #2. So why not just do #2? Does anyone actually think creating -intro pages is a bad idea? It seems like we're just debating #1 for the sake of debating. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Need for plain-language intros for each microformat
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes or 2) leave the specs where they are and create new -intro pages. I've seen [...] no one object to #2. Then you haven't been paying full attention. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
