From glenn.jones at madgex.com Wed Feb 2 07:04:04 2011
From: glenn.jones at madgex.com (Glenn Jones)
Date: Wed Feb 2 07:05:34 2011
Subject: [uf-discuss] Draggables code and demos live
Message-ID: <36A319113CF910438942741C4727ADFF0553BFCF@MOBY.Clarence.local>
Hi Everyone
I have just put up the draggables code and demos. For those who have not
heard draggables before, it's a javascript library that allows users to
exchange data between unrelated web sites using drag and drop. It uses
microformats behind the scenes.
http://draggables.com/
Glenn
From glenn.jones at madgex.com Tue Feb 15 11:08:47 2011
From: glenn.jones at madgex.com (Glenn Jones)
Date: Tue Feb 15 11:08:58 2011
Subject: [uf-discuss] input microformats for auto-filling forms
Message-ID: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
Hi All
I am interested in the use of microformats to mark-up forms. The
discussion of building better auto-fill applications and browser
extensions using microformats has been going on for a couple of years.
Currently, I am starting a couple of projects with interfaces where
users can link, drag or copy contacts. Input microformats would be an
important addition to these projects. This concept would also be useful
for any project using the W3C Contacts API. Hopefully, the
draggables.com idea gives some insight into how this could mature.
I have spent a couple of days putting together a brainstorm/proposal of
how this could work. If you're interested in this idea, could you
feedback your thoughts. The wiki is the best place to do this, just vote
up or down any ideas and add comments wherever possible. Wish it could
of been done in a workshop, but the wiki will do.
http://microformats.org/wiki/hcard-input-brainstorming
If there is enough interest and feedback from the community, I will
build the unit tests and a reference application based on the js parser
Micorformats Shiv. The final aim been to create extensions for Firefox,
Chrome and Safari
Thanks
Glenn
From charlvn at charlvn.com Tue Feb 15 11:44:36 2011
From: charlvn at charlvn.com (Charl van Niekerk)
Date: Tue Feb 15 11:44:46 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
Message-ID: <1297799076.16700.5.camel@starlight>
Hi Glenn,
Excellent work so far! I think this has great potential.
I see you mentioned HTML5 in the document (now technically just called
"HTML" I guess) but I was wondering why not make more use of the new
input types in the other examples? I see most of them are still
input="text".
For easy reference (cause I had it open anyway):
http://is.gd/qA1gFW
Thanks,
Charl
From singpolyma at singpolyma.net Tue Feb 15 12:49:11 2011
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Tue Feb 15 12:49:17 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
Message-ID: <20110215204911.GB1632@singpolyma-svelti>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Somebody claiming to be Glenn Jones wrote:
>http://microformats.org/wiki/hcard-input-brainstorming
>> We should confine the definitions of microformat to classname and rel
>> attributes.
Strongly disagree. As I understand it, ?formats are about defining
vocabularies and how those vocabularies can be best encoded using existing
HTML semantics. Restricting to class and rel is short-sighted.
For example, in this case, while having class="fn" may be beneficial (if you
want to parse the form as a microformat) using name="fn" is more
semantically correct if what you want to do is autofill or similar.
name="fn" also has the advantage of already doing a lot for you in terms of
autofill in most major browsers (who key off the name attribute for their
autofill).
In fact, using class if you are not going to have a meaningful value="" will
just *confuse* existing parsers, leading them to get a blank object.
>> Where a microformat property such as street-address in hCard can contain
>> an array of values, these values will be added in order into the
>> collection of form fields with the same classname.
Sure. I again think using name here may be more correct, depeding on what
you're doing. I believe most implementations allow multiple inputs of the
name same to mean an array, though for safety one ought to append [] (IIRC
pioneered by PHP, picked up by others due to the popularity of PHP)
>> There are a number of plural properties in mircoformats that allow
>> multiple values. In hCard the commonly used ones are tel, email and urls.
>> To allow a form to extend to receive an unknown number of values
>> auto-fill applications need to support a repeating pattern. This can be
>> achieved with a new classname ?repeat? which can be used in conjunction
>> with a microformat property. The author needs to add an instructional
>> classname to inform the application when to perform a repeat.
I do not understand the use case here at all. How does this differ from the
array value use case above? You seem to be defining behaviour here, which
seems outside the scope of ?formats.
>> There are a number of circumstances where concatenating a plural
>> microfromats property into a single string is required. The most common
>> string concatenations involve a combination of spaces and/or comma?s.
>> Auto-fill applications should concatenate three different patterns;
>> comma-space-delimited, comma-delimited and space-delimited. These format
>> operators have to be placed in the same classname attribute as the
>> microformat property name. The concatenated string should be trimmed and
>> there should be no trailing spaces or commas at the end of the string.
Again, this seems very behaviour driven instead of data driven.
>> There are number of circumstances where an ?or? operator would be useful.
>> If a classname attribute with more than one microformat property and the
>> ?or ? operator the auto fill application will make a selection between
>> the properties. The first non-null value will be used. Where the
>> microformat property is a multiple value all the values of the first
>> property are used before any subsequent properties.
This is straight-up a programming language / behaviour / scripting feature.
Not data.
>>
Interesting, but invalid and does not have a good fallback mechanism.
- --
Stephen Paul Weber, @singpolyma
See for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNWubGAAoJENEcKRHOUZzeKCMP/23BuSumemZZO4jwOcFd8GbA
mvjwSXQVjYogQyXriv1GrfSZIe78B4NN7ew54MulaPeEX00Iv/v5fyjzt4x1HTxD
VQHLZERIaGtvrVQQ/g94+I+Bmrr6rA31t42ZWVJ7ytG8BnQ8QFjbK17vXgRP/bMg
jjvqvMSzza/q1eWbAHzSYT3oQUVvH9yk3hB0zrBYEc6dpYJmu6ha7VbBqa2FNRrB
fwsNzhAPJs/gn+6u1uT5Sp66TWXPzJkN8Lnw3Nz2Z9gaIl69Tc6rieatXT+cHoro
XiVujlvRsb5sunrXiXWengjtjK2v1yOlQbolEL2W/wDYtoy09W/r4LE1OVJZXgN8
jQSCPsaQVu9p3yWL6k5L3rSlIn+mpqJHbnKyR2ueES+NcRfsuXbBJgjTeADqCHY2
KFaAB1qFWmLyZYv3guImkccOBUGLz+NIwjfdXAo061YHV6dQMJoa58KPqUHT1AFV
fpXRyfBkxrfobX4OC4+qUWEHl+T3QbRkFkbduerbRDKEG8j2/0otLqDhe/RKfxSP
6XjTcbiuZ0UVSOTDRTFvLem45ADOIDp9IbipvFdB0rxDQES3NGI5tScfmyZLp6tm
7fNPqLMPzhEythJZ/IwhOwQOJnQdae50yTWLlYRYDRoXMOLX5Xv6h0/HiBYOnkyF
Jc85+xMiMx4xI7DPxr8Z
=Vbwz
-----END PGP SIGNATURE-----
From glenn.jones at madgex.com Thu Feb 17 03:54:44 2011
From: glenn.jones at madgex.com (Glenn Jones)
Date: Thu Feb 17 03:54:50 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <1297799076.16700.5.camel@starlight>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<1297799076.16700.5.camel@starlight>
Message-ID: <36A319113CF910438942741C4727ADFF05601E1C@MOBY.Clarence.local>
Hi Charl
When I started to look at this I was hoping that the new HTML input types would be more useful. Although the new inputs describe data types they do not describe the context of data use. The example I used in the wiki page really shows this
...
We may know that the input in the example above is a date by its datetime type, but we only know that it is a start date of an event by the use of the classname attribute dtstart. As such, the semantic value is limited. Do not get me wrong, the new inputs are an important step forward, but they cannot replace the schema properties of microformats.
If you can think of any way we could use these input types without a schema reference i.e. dtstart, that would be great.
Although not an input the only exception to the above I have found so far is the pubdate attribute on the new time element which could possibly be used to replace "published" property for a hEntry . It does seem to be an exception to the rule.
Example of pubdate use from W3 spec - http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element
Small tasks
I put a bike bell on his bike.
Thanks
Glenn
-----Original Message-----
From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Charl van Niekerk
Sent: 15 February 2011 19:45
To: Microformats Discuss
Subject: Re: [uf-discuss] input microformats for auto-filling forms
Hi Glenn,
Excellent work so far! I think this has great potential.
I see you mentioned HTML5 in the document (now technically just called
"HTML" I guess) but I was wondering why not make more use of the new
input types in the other examples? I see most of them are still
input="text".
For easy reference (cause I had it open anyway):
http://is.gd/qA1gFW
Thanks,
Charl
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
From tantek at cs.stanford.edu Fri Feb 18 12:25:14 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Fri Feb 18 12:26:08 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <20110215204911.GB1632@singpolyma-svelti>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
Message-ID:
On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Somebody claiming to be Glenn Jones wrote:
>>http://microformats.org/wiki/hcard-input-brainstorming
>
>>> We should confine the definitions of microformat to classname and rel
>>> attributes.
>
> Strongly disagree. ?As I understand it, ?formats are about defining
> vocabularies and how those vocabularies can be best encoded using existing
> HTML semantics. ?Restricting to class and rel is short-sighted.
microformats are both about a scientific process for researching and
defining vocabularies,
AND the simplest/easiest/most-robust syntax for using those vocabularies.
To date experience has shown that class and rel microformats make the
most sense.
In the early days there were thoughts about also using "id" attributes
for vocabulary but those have been discarded as impractical.
> For example, in this case, while having class="fn" may be beneficial (if you
> want to parse the form as a microformat) using name="fn" is more
> semantically correct if what you want to do is autofill or similar.
> name="fn" also has the advantage of already doing a lot for you in terms of
> autofill in most major browsers (who key off the name attribute for their
> autofill).
Of course web authors should use the name attribute when it is
semantically correct to do so.
However, the challenge is that the name attribute can only accept a
*single* value (similar to "id").
Whereas one of the aspects of class and rel that made them work so
well with existing web pages and their markup is that both class and
rel contain a space separated *set* of values.
Thus it makes sense to prefer (restrict if you will) our use and
recommendation of microformats to "class" and "rel", rather than
forcing authors to pick one value for "name".
This is probably worthy of writing up as an FAQ as I've seen this
question arise before and I also *did* consider (and reject without
bothering to write it down) using the "name" attribute like this.
Here is the existing parsing brainstorming regarding treating
elements specially:
http://microformats.org/wiki/hcard-parsing-brainstorming#input_element_handling
>>>
>
> Interesting, but invalid and does not have a good fallback mechanism.
It might make more sense to have something more abstract and connected
to the user interface of the platform, e.g.
input type="contact" -- brings up a contact/addressbook application picker
and then under the hood, define the API for accessing that data in
terms of the hCard microformat vocabulary.
Tantek
--
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
From singpolyma at singpolyma.net Fri Feb 18 13:28:58 2011
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Fri Feb 18 13:29:04 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To:
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
Message-ID: <20110218212858.GB1761@singpolyma-svelti>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Somebody claiming to be Tantek ?elik wrote:
>On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber
> wrote:
>> Somebody claiming to be Glenn Jones wrote:
>>>http://microformats.org/wiki/hcard-input-brainstorming
>>
>> As I understand it, ?formats are about defining
>> vocabularies and how those vocabularies can be best encoded using existing
>> HTML semantics. ?Restricting to class and rel is short-sighted.
>
>microformats are both about a scientific process for researching and
>defining vocabularies, AND the simplest/easiest/most-robust syntax for
>using those vocabularies.
>
>To date experience has shown that class and rel microformats make the
>most sense.
In general I would agree that is true. class and rel have very nice
semantics that fit with most of what has been attempted with ?formats so
far. I'm just saying there's a difference between "most-robust syntax" and
"never anything but class and rel"
For example, XOXO is a ?format (albeit a very simple one) that does not make
extensive use of class or rel, also XMDP
>> using name="fn" is more
>> semantically correct if what you want to do is autofill or similar.
>> name="fn" also has the advantage of already doing a lot for you in terms of
>> autofill in most major browsers (who key off the name attribute for their
>> autofill).
>
>However, the challenge is that the name attribute can only accept a
>*single* value (similar to "id").
That's a good point. Are there common cases where a form input is usefully
multiple attributes? (A real question, I honestly don't know if that's
common).
>Thus it makes sense to prefer (restrict if you will) our use and
>recommendation of microformats to "class" and "rel", rather than
>forcing authors to pick one value for "name".
While this seems somewhat reasonable, as suggested on the wiki page we are
discussin there are still 2 problems with the suggested use of classnames:
1) Does nothing useful under existing UAs (whereas name would make good
autocomplete work).
2) Breaks parser expectations (a parser will see the hCard classes, for
example, and try to parse an hCard. So parsers will get blank or
filled-with-placeholder hCards from form pages).
- --
Stephen Paul Weber, @singpolyma
See for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNXuSaAAoJENEcKRHOUZze3s4P+wZDmfHBJcaeRc4a70Wkk1ww
tCL/zq/rO0Ia4QIrNE24F4LAXEHkyoKqQcp90/HggozRNDHabW2sUZGhQj1jypA/
jrTAGp5f9T2eCIf1nX1Cp3Rh6vBjg9kM6Eedvt3v46MKKfm0bEed4/fV5QmxdytD
TNT+N/yduUWxCD3DY0ff4fgwzoxY53IYeFVNcKqSTj5Ut722sjjCRKXjq5SjFvIL
4wRVu4iT6xJjLMIzVmF2G0u0pdmxnzVbSls/ZaQsUucpILF8RK1h4s+Sl/6sIBXa
kw89LXDBUZjHZSoEciNhKp9NWfCWonvRr3wc0ONwv1hLL++ViGIy/hoevhU6wv7o
fJ6B9uZkInV7L1vu9NDfGqXwurCUAYPy/KaajUxUhrgeN57EfoKhr8hudU5boNy4
SdPqbPYqkOqf5KhxBQ7hpZG4K+BFnXl8IjVMEd3bnf9EDREZCvEzt64bMCEZzpxj
/Km6Ar2gX2ANQNaRQQ97PO6kEbMCb2MiW0sNWU0004x8hhO1GfFOFVIIFDnrjEWi
ktPDiz7bs2MMxGrR/SUUflG3rzMrwNkaQ/9jiUyPd+4451PS299tzr+Oz3R/4s6t
EJ4H/giEgzOeQp4v9uOaRjP16mHW/Njq6OAXYdQ1s31VxcHWKqjEJVMMmSFFFx+n
xRXc/ucJdYkPA7bFGJPE
=91Jp
-----END PGP SIGNATURE-----
From tantek at cs.stanford.edu Fri Feb 18 16:55:45 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Fri Feb 18 16:56:31 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <20110218212858.GB1761@singpolyma-svelti>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
<20110218212858.GB1761@singpolyma-svelti>
Message-ID:
On Fri, Feb 18, 2011 at 13:28, Stephen Paul Weber
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Somebody claiming to be Tantek ?elik wrote:
>>On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber
>> wrote:
>>> Somebody claiming to be Glenn Jones wrote:
>>>>http://microformats.org/wiki/hcard-input-brainstorming
>>>
>>> As I understand it, ?formats are about defining
>>> vocabularies and how those vocabularies can be best encoded using existing
>>> HTML semantics. ?Restricting to class and rel is short-sighted.
>>
>>microformats are both about a scientific process for researching and
>>defining vocabularies, AND the simplest/easiest/most-robust syntax for
>>using those vocabularies.
>>
>>To date experience has shown that class and rel microformats make the
>>most sense.
>
> In general I would agree that is true. ?class and rel have very nice
> semantics that fit with most of what has been attempted with ?formats so
> far. ?I'm just saying there's a difference between "most-robust syntax" and
> "never anything but class and rel"
Agreed. I think the point is that for practical purposes it makes
sense to just stick to class/rel discussions, unless there is a
specific significant advantage to using something else (more than just
"what if" - which is a theoretical discussion not worth the time).
> For example, XOXO is a ?format (albeit a very simple one) that does not make
> extensive use of class or rel,
XOXO is certainly an odd one out of the bunch. I'm not sure how much
explicit (vs. implicit) use it is getting in practice, what (if any)
applications have been built that consume and do anything interesting
with it.
If you know of any specific sites that explicitly publish it for a
particular end-user benefit, or specific sites that explicitly consume
XOXO for some end-user feature, please document them:
http://microformats.org/wiki/xoxo-examples-in-wild
http://microformats.org/wiki/xoxo-implementations
> also XMDP
XMDP is not really a microformat - rather, it's more like supporting
technology for adding machine referencable definitions and URLs for
vocabulary terms.
No one publishes actual content (what microformats are really for)
marked up with XMDP.
I designed XMDP purely to provide a way to map newly created XFN rel
values to precise URIs that a system based on URIs (e.g. RDF) could
reason with. In practice I'm not sure how much URI-based reasoning is
happening on the public web (applications I've seen all just treat the
XFN rel values as tokens).
For more on this see:
http://microformats.org/wiki/xmdp-origins
>>> using name="fn" is more
>>> semantically correct if what you want to do is autofill or similar.
>>> name="fn" also has the advantage of already doing a lot for you in terms of
>>> autofill in most major browsers (who key off the name attribute for their
>>> autofill).
>>
>>However, the challenge is that the name attribute can only accept a
>>*single* value (similar to "id").
>
> That's a good point. ?Are there common cases where a form input is usefully
> multiple attributes? ?(A real question, I honestly don't know if that's
> common).
Yes, specifically the web developers is *already using a name* in
their web form implementation, and then if we ask them to add
*another* name for microformats purposes. But this is not possible
since inputs can only take one name value. Same problem as "id".
It makes them both not particularly practical for microformats vocabularies.
>>Thus it makes sense to prefer (restrict if you will) our use and
>>recommendation of microformats to "class" and "rel", rather than
>>forcing authors to pick one value for "name".
>
> While this seems somewhat reasonable, as suggested on the wiki page we are
> discussin there are still 2 problems with the suggested use of classnames:
>
> 1) Does nothing useful under existing UAs
The "does nothing useful under existing UAs" is just stop energy and
not a valid argument. Of course technology that hasn't been developed
yet does nothing in existing UAs. It would be odd if it did.
> (whereas name would make good
> ? ? ? ?autocomplete work).
Citation needed. If you want to research existing input/name "formats"
that implementations might be using, please document them on the wiki
so we can understand what might "work". Perhaps on a page like:
http://microformats.org/wiki/input-name-formats
> 2) Breaks parser expectations (a parser will see the hCard classes, for
> ? ? ? ?example, and try to parse an hCard. ?So parsers will get blank or
> ? ? ? ?filled-with-placeholder hCards from form pages).
In practice this is not a problem, we iterate on microformats parsing,
and parsers update. E.g. with the very successful (and necessary)
value-class-pattern.
Unless you can provide a specific scenario (what page, what parser,
what specific bad user experience), I'm calling theoretical on this
(thus undeserving of further discussion).
If you know of specific real-world issues with parsing input elements
for microformats, especially in the context of hCard, please note them
here under the brainstorm for input parsing:
http://microformats.org/wiki/hcard-parsing-brainstorming#input_element_handling
Thanks,
Tantek
--
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
From singpolyma at singpolyma.net Fri Feb 18 17:08:17 2011
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Fri Feb 18 17:08:23 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To:
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
<20110218212858.GB1761@singpolyma-svelti>
Message-ID: <20110219010817.GC1761@singpolyma-svelti>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Somebody claiming to be Tantek ?elik wrote:
>On Fri, Feb 18, 2011 at 13:28, Stephen Paul Weber
> wrote:
>>>However, the challenge is that the name attribute can only accept a
>>>*single* value (similar to "id").
>>
>> That's a good point. ?Are there common cases where a form input is usefully
>> multiple attributes? ?(A real question, I honestly don't know if that's
>> common).
>
>Yes, specifically the web developers is *already using a name* in
>their web form implementation, and then if we ask them to add
>*another* name for microformats purposes.
Ah, if that's still something that needs to be considered in the
autocomplete case then that makes sense.
>> (whereas name would make good
>> ? ? ? ?autocomplete work).
>
>Citation needed. If you want to research existing input/name "formats"
>that implementations might be using, please document them on the wiki
>so we can understand what might "work".
I'm just saying existing autocomplete (that browsers actually have) keys off
of the name attribute. That's why (for example) my OpenID autocompletes on
many OpenID-enabled sites, because the spec had a reccomended name attribute
for the form field.
Obviously, if this functionality is not considered useful then it doesn't
need to be a consideration :)
>If you know of specific real-world issues with parsing input elements
>for microformats, especially in the context of hCard, please note them
>here under the brainstorm for input parsing:
Sorry, really not trying to extend a theoretical discussion here, just
wanting to clarify: are we both clear that the proposal is about
autocomplete, which means that the forms will for sure be devoid of actual
content? I'm not trying to say that there are issues with parsing input
elements in general, but with empty ones (that is, ones that need to be
autocompleted).
Ok, enough from me.
- --
Stephen Paul Weber, @singpolyma
See for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNXxgBAAoJENEcKRHOUZzeE6EP/26+ysE31Koudyw0AAOQ1Ijo
28IXfGhvrQDncJW75It4BUIPfMZsHpVWDWJSOOJIQItcX6qa/6aJsuYelJ48A0Hg
HfC7AF2eUq4C7hV6U1s4VrZGAV2mirYRcjJFk5qlEe7VAlpAb0Urq7jWlPUg8tus
Oav0y0gRgrT+wJQZz7gq3LA9fqGQ1pt3uWhYhy93Jm4yDSdbIKiLFL41vdlvUTIf
2ERm7VxQdwSxzzPouSuXlgbo/R1oX9brXXYiJ6R92fEK+jGbQJcDaggcUS0vL6Id
yw37rV85ZyMO8uBQFC4lN2hJ86TC2H+y2tTwyKoDKjcn4rqANeMGeSZhtDrpUnl3
7YfOVegCDJOaIufq2Yz0i9mRJZiF5IPf2aI18tZygXNcJG82QD1obHceZj42C7UY
ebSTuOBNRXZj9aEw+E20uEN4PbVM4e8tKMNjgISrKu0EJdlqzH/fJUxzpQrzasXh
U24MBWogarJk+muFzySrdBcqi6Z7vtDRFBvRpHLwvGPaRI+IpqpG9bPBtFHOgC6j
qSz4XAUIuz1D1Qrb+RkATG7YrlYSEX4MCQaDsz99tN2F0XcIykTjUAC9G+isP9rA
pdRYvb79mmkdOmUZJG8QLyRnpRZ9qHQxXLW0hPXQt3oBFa/epb4DeT100M9356JR
vYMSJ7Q04RvPMvyP5Zj4
=1qMb
-----END PGP SIGNATURE-----
From tantek at cs.stanford.edu Fri Feb 18 19:04:03 2011
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Fri Feb 18 19:04:51 2011
Subject: [uf-discuss] moving drafts forward - process-brainstorming: draft,
specification, standard
Message-ID:
It's been noted[1][2] that no drafts are making it to specification,
and in short there are two reasons for this:
1. Lack of steps in the process[3] for how a draft should proceed to
specification and what each of those mean (other than the summary on
the Main Page[4]), including lack of documentation of implicit
assumptions such as that all outstanding issues must be resolved on a
draft (and any patterns it depends on) before we can in good
conscience make it a specification. As the editor/maintainer of the
process, I accept full personal responsibility for this.
2. Blocking issues. During the development of various drafts we
encountered a few blocker cross-microformat issues (e.g.
accessibility, internationalization) which were potentially doing
harm. Since then, those cross-microformat issues have been
resolved[5], and we've been incorporating those resolutions into the
specifications (e.g. hCard, hCalendar) as well as into resolutions of
spec-specific issues.
I've been working the past few weeks on addressing #1 above.
Having had the experience of confronting and overcoming these
cross-microformat issues, as well as close experience with the
document stages in W3C and IETF (and what works / is pragmatically
useful vs what is mostly just bureaucratic), I've developed the
following minimal process brainstorm:
http://microformats.org/wiki/process-brainstorming
Summary: three defined document stages:
* draft: consensus among brainstorm proposals, experimental, it's
ready for trial on the public web.
* specification: all outstanding issues resolved, stable, 1+ real
world publisher(s)+consumer(s), it's ready to depend on.
* standard: (new) test suite and 2+ interoperable real world
publisher(s)+consumer(s) for each feature, errata only, what the
market has accepted.
These are strictly summaries - please see
http://microformats.org/wiki/process-brainstorming for more precise
preconditions, actions, definitions, stability, and example steps to
take.
Please raise any *major* problems you note directly in an "Issues"
section on the process brainstorming page.
Assuming no major problems are found (minor are ok to fix in
iterations) in the next few days, I plan on incorporating this
brainstorm into the process itself[3] and starting to take various
current/mature specifications and drafts forward to exercise these new
steps / definitions to see how well they work in practice.
In short: I believe we can quickly get many specifications to the new
level of "standard" (e.g. hCard, hCalendar) after perhaps some
trimming of unused properties, as well as several drafts to
"specification" (e.g. hReview, hAtom) with an iteration that
incorporates issue resolutions having especially to do with the
cross-microformat issues noted above.
Thanks,
Tantek
[1] http://en.wikipedia.org/wiki/Microformat#Evaluation_of_microformats
[2] http://lists.w3.org/Archives/Public/public-html/2010Dec/0089.html
[3] http://microformats.org/wiki/process
[4] http://microformats.org/wiki/Main_Page#Specifications
[5] http://microformats.org/wiki/value-class-pattern
--
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
From mail at tobyinkster.co.uk Sat Feb 19 13:30:17 2011
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Sat Feb 19 13:29:48 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <20110215204911.GB1632@singpolyma-svelti>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
Message-ID: <20110219213017.0333ed80@miranda.g5n.co.uk>
On Tue, 15 Feb 2011 15:49:11 -0500
Stephen Paul Weber wrote:
>>
>
> Interesting, but invalid and does not have a good fallback mechanism.
Most things are invalid when they're first proposed. Unknown input
types are generally treated as type="text" by browsers, which is not
a great fallback, but perhaps usable.
Sites adopting type="vcard" early would just need to be prepared to
accept free-form contact data occasionally - but only from clients with
scripting disabled, as type="vcard" can be implemented in Javascript...
http://buzzword.org.uk/2011/input-type-vcard/test.html
--
Toby A Inkster
From glenn.jones at madgex.com Mon Feb 21 01:26:04 2011
From: glenn.jones at madgex.com (Glenn Jones)
Date: Mon Feb 21 01:34:22 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <20110219010817.GC1761@singpolyma-svelti>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local><20110215204911.GB1632@singpolyma-svelti><20110218212858.GB1761@singpolyma-svelti>
<20110219010817.GC1761@singpolyma-svelti>
Message-ID: <36A319113CF910438942741C4727ADFF05660412@MOBY.Clarence.local>
Stephen thanks for the feedback, I have tried to reply to the major points:
>> Strongly disagree. As I understand it, ?formats are about defining
>> vocabularies and how those vocabularies can be best encoded using
>> existing HTML semantics. Restricting to class and rel is short-sighted.
I agree with Tantek's point; "names" being only single values like "id" makes them hard to use as attributes for adding additional semantic information. I also think we should not force the web page author to change the presentation of the form or the server side logic.
>> In fact, using class if you are not going to have a meaningful
>> value="" will just *confuse* existing parsers, leading them to get a blank object.
When parsers such as Operator test for required fields they disregard any microformats which are left blank. By adding an additional "input" classname with the microformat root name i.e. class="vcard input" the current parsers could be upgraded to disregard blank mircoformats.
The repeat pattern
Stephen, from your questions it looks like I may not have explained the repeat pattern clearly or given good use case examples. Below is a real word example. The hCard data for my work address stored as JSON would look like this:
adr[ {
"extended-address": ["Suite 1"]
"street-address": [ "Clarence House", "30-31 North Street"],
"locality": "Brighton",
"region": "East Sussex
"postal-code": "BN1 1EB
"country-name": "United Kingdom,
"type": "work"
}]
If we look at the Argos (Large UK retail store chain) delivery form as an example http://www.flickr.com/photos/glennjonesnet/5415535821/ you will see a three line address structure. This is a common pattern; although the use of the extended address elements can differ.
This would be marked up with the microformat classes below:
The auto-fill would apply the following values. The street-address repeats into the two form fields with the street-address class.
houseNumber = Suite 1
address1 = Clarence House
address2 = 30-31 North Street
Repeating microformat properties
There are quite a few examples of this interface pattern, the Facebook contact form telephone field is any interesting example http://www.flickr.com/photos/glennjonesnet/5416146406/. Every time you add a telephone number the form updates client side and adds another field group. The code for this part of the form looks like this:
It could be marked-up
For each phone number the auto-fill application would clone the whole div structure and add this into the page. It would replicate how the interface currently works with user interaction.
>> though for safety one ought to append [] (IIRC pioneered by PHP,
>> picked up by others due to the popularity of PHP)
Stephen, this is an interesting point, we need to research how different technologies use the name attribute if we are to take on the "repeat" pattern.
Thanks Glenn
From mail at tobyinkster.co.uk Mon Feb 21 12:40:31 2011
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Mon Feb 21 12:40:15 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <20110215204911.GB1632@singpolyma-svelti>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
Message-ID: <20110221204031.0ffa9d28@miranda.g5n.co.uk>
On Tue, 15 Feb 2011 15:49:11 -0500
Stephen Paul Weber wrote:
> For example, in this case, while having class="fn" may be beneficial
> (if you want to parse the form as a microformat) using name="fn" is
> more semantically correct if what you want to do is autofill or
> similar.
For what it's worth, you might want to instead of using
elements just with name="fn", use names matching the following pattern:
/^([^\.]+\.)?fn$/
This would allow, say:
you.fn
you.email
friend.fn
friend.email
for cases where the contact details of multiple people are being
requested in the same form. Also useful when two sets of contact
details are being requested for the same person:
delivery.adr
billing.adr
The dot syntax is inspired by the grouping syntax in RFC 2425 and the
current vCard 4.0 drafts.
--
Toby A Inkster
From singpolyma at singpolyma.net Mon Feb 21 16:42:05 2011
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Mon Feb 21 16:42:15 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <36A319113CF910438942741C4727ADFF05660412@MOBY.Clarence.local>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
<20110218212858.GB1761@singpolyma-svelti>
<20110219010817.GC1761@singpolyma-svelti>
<36A319113CF910438942741C4727ADFF05660412@MOBY.Clarence.local>
Message-ID: <20110222004205.GA1606@singpolyma-svelti>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Somebody claiming to be Glenn Jones wrote:
>Stephen thanks for the feedback, I have tried to reply to the major points:
> By adding an additional "input"
> classname with the microformat root name i.e. class="vcard input" the
> current parsers could be upgraded to disregard blank mircoformats.
Right. I was talking about existing parsers. Maybe we don't need to care
about those?
>> In fact, using class if you are not going to have a meaningful value=""
>> will just *confuse* existing parsers, leading them to get a blank object.
> When parsers such as Operator test for required fields they disregard any
> microformats which are left blank.
So, the idea is that any parser returning blank objects either shouldn't or
is easy to work around? Maybe.
What about the (used to be fairly common in the real world, maybe has
dropped out of use?) pattern of setting value="placeholder" and clearing
onblur with JavaScript. These would not parse as blank but as placeholder
garbage.
Anyway, if this is not a concern then it's not a concern. I just brought it
up because it would certainly affect code I have in production and so I need
to at least be thinking about it.
[...snip rest due to name="" not considered viable...]
- --
Stephen Paul Weber, @singpolyma
See for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNYwZcAAoJENEcKRHOUZze86AP/iUe+7OyUsjV08Un76oHp2PD
gfWy8pqHoRWgoKh7Z3l3ov0oUuaUZBop0nxrVBUUyLWA/Jfa7D2TNCeZnT1XRbIJ
EYVY3KQnFiLcxEqBQEWyj2scfzL7GdfX9CsEsNphQAhrNynVidaBGxRtwRr4GEpP
jiee/1fQEcWk5KM9/cI6QL+Y18bgScQTZuRu26XtvNK0bbHSmLJwoUQqxd2IroyF
sTirdp9L9M8e2j8+A9RJDE5Hl0oXc1qt6lExFTqYuSwXf5CDOseJBdbzbt9MUUzQ
GX0FD3OYSr+j8ibae3WrV8YIVvTTIrFkeTkS5Kar422/EkAa0GpkZHIDcQsKP7b8
aDRICCu6wjQKPMLonpgfF44zhLfhikfIw/1DqFJcTp+4KMY77a9c0gCII7GnLG6T
5OnEqgEb+vF8WEt9VJ9W1UPz5hoGbnbRG3T9I5W/HFa83UGjcte3yLrUug7k3JKg
qCAg8lRENdWYJfJFDbJLWMZUaWOhNtdObZRLuPKfNF4amWX/hMPPQu8uWmvATS8r
eDMpu0FilqFpk3AqZL+Jwz4xfFjwvLo1QvHZWcBNu5iYWss+Z8YIClJYi6HECP7E
3n1MlQmbhqDg7BPe1EELqgoQMEkKpzZSjKvKwGRL0TiMgTkMuXg3QHlN83cALRQS
ZE+ZOqTbGf5fA869wro4
=+ejP
-----END PGP SIGNATURE-----
From glenn.jones at madgex.com Tue Feb 22 00:26:13 2011
From: glenn.jones at madgex.com (Glenn Jones)
Date: Tue Feb 22 00:26:20 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <20110221204031.0ffa9d28@miranda.g5n.co.uk>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local><20110215204911.GB1632@singpolyma-svelti>
<20110221204031.0ffa9d28@miranda.g5n.co.uk>
Message-ID: <36A319113CF910438942741C4727ADFF05660730@MOBY.Clarence.local>
Hi Toby
The dot syntax looks interesting, it reminds me a little of the
Microsoft VCARD_NAME documented on
http://microformats.org/wiki/hcard-input-formats.
Could you point me to the documentation for grouping syntax in RFC 2425,
Google it with not much luck.
Thanks
Glenn
Toby A Inkster wrote:
>> For what it's worth, you might want to instead of using
>> elements just with name="fn", use names matching the following
pattern:
>> /^([^\.]+\.)?fn$/
>> This would allow, say:
>> you.fn
>> you.email
>> friend.fn
>> friend.email
>> for cases where the contact details of multiple people are being
>> requested in the same form. Also useful when two sets of contact
>> details are being requested for the same person:
>> delivery.adr
>> billing.adr
>> The dot syntax is inspired by the grouping syntax in RFC 2425 and the
>> current vCard 4.0 drafts.
From glenn.jones at madgex.com Tue Feb 22 00:46:08 2011
From: glenn.jones at madgex.com (Glenn Jones)
Date: Tue Feb 22 00:46:17 2011
Subject: [uf-discuss] Meetup to workshop/brainstorm input microformat ideas
Message-ID: <36A319113CF910438942741C4727ADFF05660749@MOBY.Clarence.local>
Hi All
If there is a enough interested I would like to setup a UK meet-up to
workshop/brainstorm the input microformat ideas. The week of 10-17 April
looks good as Tantek is in the UK and most people are back from SXSWi.
Jeremy Keith said he would be interested. I could arrange a small event
in London or Brighton.
What about everyone else? It's been a while since we had a UK
microformats meetup.
Glenn
From laurentwalter.goix at telecomitalia.it Tue Feb 22 01:28:21 2011
From: laurentwalter.goix at telecomitalia.it (Goix Laurent Walter)
Date: Tue Feb 22 01:29:28 2011
Subject: R: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <36A319113CF910438942741C4727ADFF05660730@MOBY.Clarence.local>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local><20110215204911.GB1632@singpolyma-svelti>
<20110221204031.0ffa9d28@miranda.g5n.co.uk>
<36A319113CF910438942741C4727ADFF05660730@MOBY.Clarence.local>
Message-ID:
Hello all,
The concept of referencing the user social sphere ("you","me","user" we name it, and its 'relationships') to access their attributes through a dotted notation is indeed valuable.
Would it be reasonable to use it in the value= instead of the name= as indeed it intends to provides a placeholder to the value itself? Maybe through a dedicated prefix to ensure correct parsing instead of pure text. The prefix should be generic enough to encompass a variety of such references through dotted notations.
Cheers
walter
-----Messaggio originale-----
Da: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] Per conto di Glenn Jones
Inviato: marted? 22 febbraio 2011 9.26
A: Microformats Discuss
Oggetto: RE: [uf-discuss] input microformats for auto-filling forms
Hi Toby
The dot syntax looks interesting, it reminds me a little of the
Microsoft VCARD_NAME documented on
http://microformats.org/wiki/hcard-input-formats.
Could you point me to the documentation for grouping syntax in RFC 2425,
Google it with not much luck.
Thanks
Glenn
Toby A Inkster wrote:
>> For what it's worth, you might want to instead of using
>> elements just with name="fn", use names matching the following
pattern:
>> /^([^\.]+\.)?fn$/
>> This would allow, say:
>> you.fn
>> you.email
>> friend.fn
>> friend.email
>> for cases where the contact details of multiple people are being
>> requested in the same form. Also useful when two sets of contact
>> details are being requested for the same person:
>> delivery.adr
>> billing.adr
>> The dot syntax is inspired by the grouping syntax in RFC 2425 and the
>> current vCard 4.0 drafts.
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
From fberriman at gmail.com Wed Feb 23 07:52:36 2011
From: fberriman at gmail.com (Frances Berriman)
Date: Wed Feb 23 07:54:08 2011
Subject: [uf-discuss] Meetup to workshop/brainstorm input microformat ideas
In-Reply-To: <36A319113CF910438942741C4727ADFF05660749@MOBY.Clarence.local>
References:
<36A319113CF910438942741C4727ADFF05660749@MOBY.Clarence.local>
Message-ID:
On 22 February 2011 08:46, Glenn Jones wrote:
> Hi All
>
> If there is a enough interested I would like to setup a UK meet-up to
> workshop/brainstorm the input microformat ideas. The week of 10-17 April
> looks good as Tantek is in the UK and most people are back from SXSWi.
> Jeremy Keith said he would be interested. I could arrange a small event
> in London or Brighton.
I'd be up for that - possibly more-so if it was in London, but I'm
flexible. Perhaps put together an event page for it on the wiki and
get a consensus on preferences there?
> What about everyone else? It's been a while since we had a UK
> microformats meetup.
It has been a while :D A bit of input work and a bit of a social would be nice.
- F
From spike at tenbus.co.uk Wed Feb 23 12:02:19 2011
From: spike at tenbus.co.uk (Chris Foote (Spike))
Date: Wed Feb 23 12:02:01 2011
Subject: [uf-discuss] Meetup to workshop/brainstorm input microformat ideas
In-Reply-To:
References: <36A319113CF910438942741C4727ADFF05660749@MOBY.Clarence.local>
Message-ID: <4D6567CB.80604@tenbus.co.uk>
Frances Berriman wrote:
> On 22 February 2011 08:46, Glenn Jones wrote:
>
>> Hi All
>>
>> If there is a enough interested I would like to setup a UK meet-up to
>> workshop/brainstorm the input microformat ideas. The week of 10-17 April
>> looks good as Tantek is in the UK and most people are back from SXSWi.
>> Jeremy Keith said he would be interested. I could arrange a small event
>> in London or Brighton.
>>
>
> I'd be up for that - possibly more-so if it was in London, but I'm
> flexible. Perhaps put together an event page for it on the wiki and
> get a consensus on preferences there?
>
>
>> What about everyone else? It's been a while since we had a UK
>> microformats meetup.
>>
>
> It has been a while :D A bit of input work and a bit of a social would be nice.
>
> - F
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>
I'm a non-contributing lucrker but would try to attend if poss. London
or Brighton would be good for me.
Spike
From mail at tobyinkster.co.uk Thu Feb 24 02:05:03 2011
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Thu Feb 24 02:04:39 2011
Subject: [uf-discuss] input microformats for auto-filling forms
In-Reply-To: <36A319113CF910438942741C4727ADFF05660730@MOBY.Clarence.local>
References: <36A319113CF910438942741C4727ADFF056019C9@MOBY.Clarence.local>
<20110215204911.GB1632@singpolyma-svelti>
<20110221204031.0ffa9d28@miranda.g5n.co.uk>
<36A319113CF910438942741C4727ADFF05660730@MOBY.Clarence.local>
Message-ID: <20110224100503.5ab7ecd9@miranda.g5n.co.uk>
On Tue, 22 Feb 2011 08:26:13 -0000
"Glenn Jones" wrote:
> Could you point me to the documentation for grouping syntax in RFC
> 2425, Google it with not much luck.
http://tools.ietf.org/html/rfc2425#section-5.8.2
See the ABNF production for 'contentline'.
The grouping construct allows you to say that certain lines within a
vCard (or indeed any text/directory-based format) belong together. e.g.
BEGIN:VCARD
VERSION:3.0
FN:Prince Charles
N:Windsor;Charles;Philip,Arthur,George;Prince;KG,KT,GCB,OM,AK,QSO,CD,SOM,
GCL,PC,AdC(P),FRS
CON.TITLE=Duke of Cornwall
CON.NOTE=The prince has been Duke of Cornwall since 6 February 1952.
WAL.TITLE=Prince of Wales
WAL.NOTE=The prince has been Prince of Wales since 26 July 1958.
END:VCARD
vCard 3.0 (RFC 2426) uses text/directory syntax, thus this is allowed.
However, as none of the examples in RFC 2426 use it, it's not
especially well-supported in vCard 3.0 implementations. vCard 4.0
mentions the construct explicitly; some drafts have included examples
of it in use, but the latest does not; consumers that don't care about
grouping are just advised to strip /^([^\.\:]*\.)/ off the front of
each property.
--
Toby A Inkster
From mail at tobyinkster.co.uk Thu Feb 24 02:07:00 2011
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Thu Feb 24 02:06:31 2011
Subject: [uf-discuss] Meetup to workshop/brainstorm input microformat ideas
In-Reply-To: <36A319113CF910438942741C4727ADFF05660749@MOBY.Clarence.local>
References: <36A319113CF910438942741C4727ADFF05660749@MOBY.Clarence.local>
Message-ID: <20110224100700.0f36ca8b@miranda.g5n.co.uk>
On Tue, 22 Feb 2011 08:46:08 -0000
"Glenn Jones" wrote:
> What about everyone else? It's been a while since we had a UK
> microformats meetup.
You can put me down as tentative.
London or Brighton would be fine - prefer Brighton.
--
Toby A Inkster
From andyhume at gmail.com Thu Feb 24 07:10:11 2011
From: andyhume at gmail.com (Andy Hume)
Date: Thu Feb 24 07:11:27 2011
Subject: [uf-discuss] Meetup to workshop/brainstorm input microformat ideas
In-Reply-To: <20110224100700.0f36ca8b@miranda.g5n.co.uk>
References: <36A319113CF910438942741C4727ADFF05660749@MOBY.Clarence.local>
<20110224100700.0f36ca8b@miranda.g5n.co.uk>
Message-ID:
> On Tue, 22 Feb 2011 08:46:08 -0000
> "Glenn Jones" wrote:
>
>> What about everyone else? It's been a while since we had a UK
>> microformats meetup.
Yep, you can count me in. Have vague thoughts on some input patterns it would be fun to brainstorm.
Andy.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
From michael at digital.com.au Thu Feb 24 21:15:09 2011
From: michael at digital.com.au (Michael Elliot)
Date: Thu Feb 24 21:15:27 2011
Subject: [uf-discuss] Images not displaying during mailing list registration
Message-ID:
Hello,
When registering with a mailing list, most of the images are forbidden
(e.g. http://microformats.org/images/mailman/PythonPowered.png) and
thus not displaying correctly.
Regards,
Michael Elliot
Network Digital
From fberriman at gmail.com Fri Feb 25 03:48:52 2011
From: fberriman at gmail.com (Frances Berriman)
Date: Fri Feb 25 03:49:27 2011
Subject: [uf-discuss] Images not displaying during mailing list
registration
In-Reply-To:
References:
Message-ID:
On 25 February 2011 05:15, Michael Elliot wrote:
> Hello,
>
> When registering with a mailing list, most of the images are forbidden
> (e.g. http://microformats.org/images/mailman/PythonPowered.png) and
> thus not displaying correctly.
>
Thanks Michael, I'll take a look when I get a mo'. :)
- F
From glenn.jones at madgex.com Sun Feb 27 03:53:12 2011
From: glenn.jones at madgex.com (Glenn Jones)
Date: Sun Feb 27 03:53:17 2011
Subject: [uf-discuss] UK Meetup in April
Message-ID: <36A319113CF910438942741C4727ADFF0576F053@MOBY.Clarence.local>
Hi All
As suggested by Frances I have created an page for UK meet-up to get a
consensus on preferences when and where. If you're interested please
take a minute to add yourself to the attendee list and not your
preferences.
http://microformats.org/wiki/events/2011-04-uk
Thanks
Glenn Jones
From spike at tenbus.co.uk Sun Feb 27 05:08:35 2011
From: spike at tenbus.co.uk (Chris Foote (Spike))
Date: Sun Feb 27 05:08:44 2011
Subject: [uf-discuss] UK Meetup in April
In-Reply-To: <36A319113CF910438942741C4727ADFF0576F053@MOBY.Clarence.local>
References: <36A319113CF910438942741C4727ADFF0576F053@MOBY.Clarence.local>
Message-ID: <4D6A4CD3.6050803@tenbus.co.uk>
Glenn Jones wrote:
> Hi All
>
> As suggested by Frances I have created an page for UK meet-up to get a
> consensus on preferences when and where. If you're interested please
> take a minute to add yourself to the attendee list and not your
> preferences.
>
> http://microformats.org/wiki/events/2011-04-uk
>
> Thanks
> Glenn Jones
>
>
Thanks Glenn! I have no preference for date or venue so have just added
myself to list of people interested in attending.
Spike