[uf-discuss] Size considerations

[Mike Schinkel]

>> A. You probably won't notice any impact on page size when authoring with
microformats. 

In many cases, I agree.  But let's look at some of the proposals for money
(forgive me if my example is not exactly what was proposed, but it should be
equivalent in # of characters used). The following is 6 characters:

	$54.97
 
This is 151 characters (according to MS-Word's stats dialog):

	<span class="money">
		<span class="symbol" title="dollar">$</span>
		<abbr class="currency" title="USD">
			<span class="amount">54.97</span>
		</abbr>
	</span>

So let's think about a price matrix with 10 columns and 100 rows.  Without
markup it would be 6000 bytes or 5.85Kb just for the 1000 prices.  With
markup it would be 151,000 bytes, or 147.5Kb just for the prices. That's a
huge difference and is pretty significant, especially when you consider that
it is not unlikely to have many prices on a single page and a matrix of
10x100 is not unrealistic.  For those concerned about SEO, Google evidently
likes pages to be less than 101kb[1]. This could keep SEO concerned people
from using the money microformat, for example.

I guess what I'm saying is I think we need to consider each microformat
individually and also consider the likely use-cases (though we can never be
sure.)  If a microformat is by definition only going to be used once on a
page, it can be as damn big as it want's to be.  But if there could be
thousands on a page, we should really be careful when adding too much
markup.  IMHO anyway. :)

-Mike
P.S. This example may argue for putting a page-global currency spec back
into the planned microformat, even though not that many people voted on
it...

[1] http://www.morearnings.com/2006/03/26/page-size-and-keyword-density/

-----Original Message-----
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Benjamin
West
Sent: Wednesday, October 18, 2006 5:18 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] Size considerations

Added to the wiki: http://microformats.org/wiki/faq#Class_semantics

Q. How will microformat class names impact page size?

A. You probably won't notice any impact on page size when authoring with
microformats. Our experience is that people use comparably sized class
names, and semantic class names are now considered an industry best
practice. Some sites are successfully publishing millions of microformats,
and we haven't heard any complaints yet. You are more likely to gain space
savings by more fully adopting the principles of microformats [TODO: Add
link to microformats principles.], and eliminating tables for layout. [TODO:
Consider creating a new section for web authoring tips? Or at least linking
to another site that advocates good authorship. ]

On 10/18/06, Charles Roper <reachme at charlesroper.co.uk> wrote:
> Scott Reynen wrote:
> > I agree with all of this, but I think a more fundamental issue is 
> > that this problem is always presented as a hypothetical, and we 
> > shouldn't spend out time trying to solve hypothetical problems.  We 
> > know readability is a problem when someone can't understand 
> > something.  We'll know size is a problem when someone says they 
> > can't implement microformats due to size.  No one has ever said that, as
far as I know.
>
> It's hypothetical because not many people are using microformats yet.
> However, we *do* know that people are concerned with file sizes and 
> html bloat as this was one of the main selling points of switching to 
> tableless CSS designs was that of reducing file size [1].
>
> Javascripters also go to extreme lengths to compress their large 
> libraries, often using cryptic variable and object names to shave off 
> a few more bytes. The (lack of) size in a js library has become a feature.
> I don't happen agree with the practice of sacrificing readability for 
> file size and others seem to agree [2].
>
> [1] http://www.stopdesign.com/articles/throwing_tables/
> [2] http://tinyurl.com/y2twvy
>
> The thing is, I don't think it's as black or white as saying one 
> can/can't implement microformats due to size. Size should be a 
> *consideration*, surely, and compromises need to be made. I just 
> think, given the balance of pros and cons for longer, more readable, 
> attributes, I'd go with longer.
>
> Cheers,
>
> Charles
>
> --
> Charles Roper
> www.charlesroper.co.uk
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
_______________________________________________
microformats-discuss mailing list
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss