title attribute and abbreviated class names (Was:[uf-discuss]Currency Quickpoll: Preliminary results)

[Mike Schinkel]

>> Your examples seem to leave a lot of ambiguity about what things mean,

I'm new to proposing microformats, so I clearly have a lot to learn, but
that said I don't see where what I was proposing was ambiguous. Can you give
me explicit examples where allowing default assumptions for the most common
use cases will by necessity lead to ambiguity?  It seems to me that either
something will be specified or if not it will default?  That seems non
ambiguous to me. Am I wrong?

>> There's no getting around that.  Reducing this markup by making the class
names more ambiguous isn't worth it.

Okay.  But one final point on this; has this been discussed this with those
who make the decisions for markup used at the largest sites: Google, eBay,
Amazon, etc.?  Just curious? (and I don't mean to push this, it's just that
being pedantic is in my nature, unfortunately. :)

>> Do you know someone who actually has this problem?

No, just bringing up something now that occurred to me rather than wishing I
had brought it up later.

>> And I don't see any other high-volume sites doing this kind of
micro-optimizing for bandwidth.

Okay. Maybe it was more of a concern a few years ago when bandwidth was more
expensive. I'm happy to drop it now that I've had a chance to test the
concern.

-Mike


-----Original Message-----
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Scott
Reynen
Sent: Saturday, October 14, 2006 11:42 AM
To: Microformats Discuss
Subject: Re: title attribute and abbreviated class names
(Was:[uf-discuss]Currency Quickpoll: Preliminary results)

On Oct 14, 2006, at 3:42 AM, Mike Schinkel wrote:

>>> I think your use of the title attribute in these examples contains 
>>> two
> bad practices....
>
> Hmm.  I see your point, and being new to this I'm learning from your 
> examples.
>
> OTOH, I also see that the proposals I first viewed as being very 
> complex and I'd fear many people simply won't implement them until 
> there is a direct benefit, and there will likely be few direct 
> benefits until lots of people start implementing them; a classic chick 
> and egg problem.  Is there not a way to significantly reduce 
> complexity, at least in the 80 percentile case and still maintain 
> proper semantics?  I know I'm new and might be schooled to understand 
> the downside of my current view, but currentky if I had to between the 
> two, I'd vote for semantics that don't fit perfectly over 
> significantly greater required complexity per each marked up amount.

We should minimize complexity, but not at the expense of clear useful
semantics.  Without clear useful semantics, there's no point in
microformats.  Your examples seem to leave a lot of ambiguity about what
things mean, and this reduces the benefit of use, which will hurt adoption.
Small businesses don't want to get a bunch of payments submitted in the
wrong currency because some parser guessed wrong.  A microformat should
leave no room for guessing.

>>> It's a minor problem, but it's also a minor solution - typing four 
>>> extra
> letters.
>
> Point of note, my concern wasn't typing extra letters, it was the need 
> to transmit extra bites over the wire.

This is also a good goal, but also a lower priority than clarity.   
Microformats are going to require some amount of additional markup.   
There's no getting around that.  Reducing this markup by making the class
names more ambiguous isn't worth it.

> Imaging a very large volume site that
> has hundreds of prices to mark up per page, and they server millions 
> of pages an hour. It might add up to be a concern.

Do you know someone who actually has this problem?

> For example, why does
> google use "q" instead of "query" on it's search box?  I'm assuming to 
> reduce unnecessary characters.

Take a look at the HTML source of any Google page.  It's full of comments
that don't provide any functionality at all, and inline CSS and JavaScript,
which could be cached separate from the HTML to significantly reduce
bandwidth.  I see no evidence unnecessary characters is a real concern for
Google.  And I don't see any other high-volume sites doing this kind of
micro-optimizing for bandwidth.

Peace,
Scott
_______________________________________________
microformats-discuss mailing list
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss