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@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
