Re: [uf-discuss] Re: Possible alternative methods for include
On Fri, 2008-02-08 at 15:21 +, Martin McEvoy wrote: eg: we could use class data as a container for what we want to include. span class=vcard span class=data span class=fnFoo/span /span a class=email href=mailto:[EMAIL PROTECTED]email [EMAIL PROTECTED]/a /span The above example was not very clear was it?, so a proposal can be found here: http://microformats.org/wiki/include-pattern-strawman#Use_a_Class_Create_method Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
Hello Toby On Fri, 2008-02-08 at 10:58 +, Toby A Inkster wrote: Such that this: p class=#foo bar #baz x /p is considered equivalent to the following using current existing include- pattern: p class=bar a class=include href=#foo/a x a class=include href=#baz/a /p you know instead of trying to mimic the current include pattern or stuffing a class try something new and a bit more microformaty... eg: we could use class data as a container for what we want to include. span class=vcard span class=data span class=fnFoo/span /span a class=email href=mailto:[EMAIL PROTECTED]email [EMAIL PROTECTED]/a /span then use an empty span with the class include data anywhere you would like the data to appear span class=vcard span class=include data/span a class=email href=mailto:[EMAIL PROTECTED]email [EMAIL PROTECTED]/a /span the result could turn out much like this: span class=vcard span class=fnFoo/span a class=email href=mailto:[EMAIL PROTECTED]email [EMAIL PROTECTED]/a /span Pretty easy on the mind I would say. Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On Feb 7, 2008 4:36 AM, Toby A Inkster [EMAIL PROTECTED] wrote: The order of the paragraphs doesn't have a special significance, yet the paragraphs do have an inherent order. Similarly, the order of class names within a class attribute don't have a special significance attached to them by the HTML spec, but they do still have an inherent order. There is an inherent order, but that order can not be relied upon to convey any useful information. -- Paul Wilkins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On Feb 5, 2008, at 8:23 AM, Toby A Inkster wrote: Tantek =?ISO-8859-1?B?xw==?=elik wrote: 1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't. A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered. It does claim that it's a set of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world set to be interpreted in that way -- far more likely they were referring to the layman's definition of the word. Specs aren't generally written in layman's terms. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On Feb 6, 2008 12:00 PM, Ryan King [EMAIL PROTECTED] wrote: Specs aren't generally written in layman's terms. If the ordering of class names were supposed to to have some special significance, there would be further information about such a specific order. In this case a lack of evidence points to no importance in the order of the class names. Attributes are unordered because if they were, it would make life a lot more difficult for those using them. Likewise for class names. Some browsers do impose their own ordering on the attributes, and other scripts may affect the ordering of class names too. As such any reliance on a particular order is liable to fall apart rather quickly. -- Paul Wilkins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
In message [EMAIL PROTECTED], Toby A Inkster [EMAIL PROTECTED] writes The order of the space-delimited class attributes should be considered significant -- that is, in foo class=bar #baz the content referred to by #baz is logically included as the last child of the foo element, but in foo class=#baz bar, it is logically included as the first child. I don't understand why that's necessary. Can you elaborate, please? Meanwhile, my proposal is now on the wiki: http://microformats.org/wiki/include-pattern-strawman#Andy_Mabbett -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On Sun, 2008-02-03 at 19:46 +, Andy Mabbett wrote: In message [EMAIL PROTECTED], Toby A Inkster [EMAIL PROTECTED] writes The order of the space-delimited class attributes should be considered significant -- that is, in foo class=bar #baz the content referred to by #baz is logically included as the last child of the foo element, but in foo class=#baz bar, it is logically included as the first child. I don't understand why that's necessary. Can you elaborate, please? Meanwhile, my proposal is now on the wiki: http://microformats.org/wiki/include-pattern-strawman#Andy_Mabbett You Know I don't think you actually have to include your data, you could perhaps just reference them eg: foo id=me class=fnMartin McEvoy/foo bar class=[EMAIL PROTECTED]http://wherever.com//bar parsers instead of replacing data can then just append their data? Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
In message [EMAIL PROTECTED], Toby A Inkster [EMAIL PROTECTED] writes The order of the space-delimited class attributes should be considered significant -- that is, in foo class=bar #baz the content referred to by #baz is logically included as the last child of the foo element, but in foo class=#baz bar, it is logically included as the first child. Wikied here: http://microformats.org/wiki/include-pattern-strawman You might like to compare that with my proposal, not yet on the wiki, but outlined in this post: http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html (aka http://tinyurl.com/2yjpj9) et seq. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On Sun, 2008-02-03 at 20:40 +, Martin McEvoy wrote: foo id=me class=fnMartin McEvoy/foo bar class=[EMAIL PROTECTED]http://wherever.com//bar No :( too verbose anyway: div class=vcard span id=me class=fnMartin McEvoy/span br /a class=url org href=http://someurl.co.uk/;WebOrganics/a /div div class=vcard a class=[EMAIL PROTECTED] [EMAIL PROTECTED] href=http://someurl.com/;DarkstarServer/a /div and you may have to actually use include to make it less so div class=vcard span class=[EMAIL PROTECTED]/span a class=url org href=http://someurl.com/;DarkstarServer/a /div which is not good, its almost like creating an empty p/p to create some space? Oh well Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On Sun, 2008-02-03 at 21:35 +, Martin McEvoy wrote: On Sun, 2008-02-03 at 20:40 +, Martin McEvoy wrote: foo id=me class=fnMartin McEvoy/foo bar class=[EMAIL PROTECTED]http://wherever.com//bar No :( too verbose anyway: A solution may be to remove our own anti-patterns such as using id and empty anchor text links altogether: div class=vcard span class=include span class=fnMartin McEvoy/span /span a class=url org href=http://someurl.co.uk/;WebOrganics/a /div all sibling hcards could then use the include as the Required fn when not explicitly stated. div class=vcard a class=url org href=http://someurl.com/;DarkstarServer/a /div Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On 2/3/08 4:34 AM, Toby A Inkster [EMAIL PROTECTED] wrote: Toby A Inkster wrote: The order of the space-delimited class attributes should be considered significant -- that is, in foo class=bar #baz the content referred to by #baz is logically included as the last child of the foo element, but in foo class=#baz bar, it is logically included as the first child. I shall add to the Wiki momentarily... Wikied here: http://microformats.org/wiki/include-pattern-strawman Also fleshed out to include an example where included data is placed in the middle of its parent element rather than at the beginning or end. Two problems: 1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't. 2. inclusion of arbitrary data (#baz) in the class attribute is a documented anti-pattern. http://microformats.org/wiki/anti-patterns#data_in_class_attributes Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
Toby A Inkster wrote: For addresses, the order of the included elements is probably not important. When it comes to, say, printing an envelope, we all know that the street address comes before the locality. Parsers can have this knowledge hard-coded. This is probably true, although note this will require them to be locale-aware as such rules don't necessarily hold fast in different territories. For example, it seems that in Chinese addresses written in Chinese the locality would come before the street address: http://www.upu.int/post_code/en/countries/CHN.pdf -- Benjamin Hawkes-Lewis ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
