[uf-discuss] Size considerations

[Charles Roper]

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