>> The point I am trying to make is this: file size *is* an issue, but it is not an insurmountable problem and can be solved through technology and good design; file size shouldn't compromise the semantics and design of a microformat.
Since I was the one that originally called the question I want to also point out that, related to size of the microformat, if a microformat is too conceptually large (and complex) it is less likely to be applied than if it is simple and easy. Remember, there are lots of people publishing web pages that are far from technical... (Sorry if I'm belaboring the point...) -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Roper Sent: Thursday, October 19, 2006 3:41 AM To: Microformats Discuss Subject: Re: [uf-discuss] Size considerations Scott Reynen wrote: > Who is publishing 10 columns and 100 rows of prices or something > similar? It would be helpful to look at some real-world markup so we > can come up with practical ways to address this concern. If it's in > rows and columns, I would assume each price to be in a <td>, so <span > class="money"> becomes just <td class="money">, removing 14 characters > by my count. But it's hard to know if this is a realistic assumption > when we're dealing with hypothetical markup. Here's an example of a page that would be made larger if a species microformat were applied to it that used the longer class names (they're pretty long already): http://www.sxbrc.org.uk/biodiversity/speciesinventories/psrlist.php It's not a great example as it's a short list without much detail. The scientific community often share long lists such as this, although web users outside of this field probably don't come across them often. HOWEVER, there are design and implementation decisions on my part as the developer and designer of a site I would take *before* I ruled out using uFs due to their size. (I would consider 100K to long, btw) These are: 1. I would apply output compression (which I have done in the example above, taking it from 17835 bytes down to 3972 bytes) 2. If the list were to grow much longer than it already is, I would consider it a bad fit for a one page design and redesign with a paging and search mechanism. 3. If #2 came into effect, and visitors required one long list (which I know they do), then I would offer a variety of download options *including* the big HTML version. The point I am trying to make is this: file size *is* an issue, but it is not an insurmountable problem and can be solved through technology and good design; file size shouldn't compromise the semantics and design of a microformat. -- Charles Roper www.charlesroper.co.uk _______________________________________________ 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
