Re: [uf-discuss] input microformats for auto-filling forms
On Tue, 22 Feb 2011 08:26:13 - Glenn Jones glenn.jo...@madgex.com 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 mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] input microformats for auto-filling forms
-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 http://singpolyma.net 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
On Tue, 15 Feb 2011 15:49:11 -0500 Stephen Paul Weber singpol...@singpolyma.net wrote: input type=vcard 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 mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] input microformats for auto-filling forms
On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber singpol...@singpolyma.net 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 input elements specially: http://microformats.org/wiki/hcard-parsing-brainstorming#input_element_handling input type=vcard 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Somebody claiming to be Tantek Çelik wrote: On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber singpol...@singpolyma.net 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 http://singpolyma.net 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
On Fri, Feb 18, 2011 at 13:28, Stephen Paul Weber singpol...@singpolyma.net 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 singpol...@singpolyma.net 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
RE: [uf-discuss] input microformats for auto-filling forms
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 div class=vevent input class=dtstart type=datetime / ... /div 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 article h1Small tasks/h1 footerPublished time pubdate datetime=2009-08-30today/time./footer pI put a bike bell on his bike./p /article 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
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
Re: [uf-discuss] input microformats for auto-filling forms
-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. input type=vcard Interesting, but invalid and does not have a good fallback mechanism. - -- Stephen Paul Weber, @singpolyma See http://singpolyma.net 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
