Re: [uf-discuss] input microformats for auto-filling forms

2011-02-24 Thread Toby Inkster
On Tue, 22 Feb 2011 08:26:13 -
"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



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


RE: [uf-discuss] input microformats for auto-filling forms

2011-02-22 Thread Glenn Jones
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


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-21 Thread Stephen Paul Weber
-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-
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-21 Thread Toby Inkster
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



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


RE: [uf-discuss] input microformats for auto-filling forms

2011-02-21 Thread Glenn Jones
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:



Work
Home
Mobile   
Afghanistan (+93)
...


It could be marked-up


Work
Home
Mobile   
Afghanistan (+93) 
...
  

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-19 Thread Toby Inkster
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



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-18 Thread Stephen Paul Weber
-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-
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-18 Thread Tantek Çelik
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

Re: [uf-discuss] input microformats for auto-filling forms

2011-02-18 Thread Stephen Paul Weber
-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-
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-18 Thread Tantek Çelik
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

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


RE: [uf-discuss] input microformats for auto-filling forms

2011-02-17 Thread Glenn Jones
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
 Published today.
 I put a bike bell on his bike.



Thanks 
Glenn


-Original Message-
From: microformats-discuss-boun...@microformats.org 
[mailto:microformats-discuss-boun...@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

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-15 Thread Stephen Paul Weber
-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-
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] input microformats for auto-filling forms

2011-02-15 Thread Charl van Niekerk
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