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
[uf-discuss] Re: Possible alternative methods for include
Paul Wilkins wrote: Toby A Inkster 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. An inherent order is all that is needed by my include pattern. It uses the inherent order of class names to emulate the inherent order of child nodes. 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 Both examples take advantage of inherent rather than explicit order. In the first case the inherent order of class names is used; and in the second, the inherent order of child nodes. However, my suggested format is less verbose, creates no dummy elements in the DOM and is likely to cause fewer accessibility problems. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 9 days, 17:08.] The Great IE8 Meta Tag Debacle http://tobyinkster.co.uk/blog/2008/02/06/ie-8-meta-tag/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Possible alternative methods for include
Ryan King wrote: Toby A Inkster wrote: 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. What I meant was that the vast majority of the words used in most specifications are not explicitly defined, nor are other normative references provided giving a definition of them. This is fair enough. You don't want to read through an enormous glossary at the end of a specification defining words such as first, down and the. When a word is not explicitly defined in the specification itself, or in a reference, one should assume that the normal everyday meaning of the word is implied. I seem to remember reading somewhere that of all the entries in the Oxford English Dictionary, the word set has the longest, spanning several pages. In the context used in the HTML 4.01 spec, I find it unlikely that they were specifically referring to the mathematical usage of the word set, unless they were attempting to be deliberately obscure. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 21:25.] Looking Ahead to Perl 6 http://tobyinkster.co.uk/blog/2008/02/05/perl6/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Possible alternative methods for include
Paul Wilkins wrote: 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. If the ordering of paragraphs were supposed 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 paragraphs. Thus the following HTML documents may be rendered identically by a conforming browser, right? titleDocument one/title pone/p ptwo/p titleDocument two/title ptwo/p pone/p 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. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 21:47.] Looking Ahead to Perl 6 http://tobyinkster.co.uk/blog/2008/02/05/perl6/ ___ 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
[uf-discuss] Re: Possible alternative methods for include
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. As far as parsers are concerned, DOM Level 2 HTML provides as className property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order. And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained. I can't think of a single HTML parser that is only able to provide access to the class attribute as an unordered set. If any such parser exists, please enlighten me. 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 This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 6 days, 22:24.] The World in 2050? http://tobyinkster.co.uk/blog/2008/02/03/world-2050/ ___ 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
[uf-discuss] Re: Possible alternative methods for include
pWe have three branches in span class=locality id=ldnLondon/span, including our head office in span class=locality id=kenKensington/span:/p ul li class=adr #ldn span class=street-address123 Oxford Street/span /li li class=adr #ken #ldn span class=street-address5 Kensington High Street/span /li li class=adr #ldn span class=street-address1 Pall Mall/span /li /ul 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. Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors. If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'. I shall add to the Wiki momentarily... -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 4 days, 18:02.] Looking Ahead to PHP 6 http://tobyinkster.co.uk/blog/2008/01/29/php6/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Possible alternative methods for include
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. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 4 days, 18:50.] Looking Ahead to PHP 6 http://tobyinkster.co.uk/blog/2008/01/29/php6/ ___ 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
