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
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
