[uf-discuss] Vote Links: rel="voted-for"

[Tantek Ç elik]

On 1/23/07 12:15 PM, "Ara Pehlivanian" <ara.pehlivanian at gmail.com> wrote:

>> I wouldn't call people 'thick' just because they don't understand the
>> difference between @rev and @rel. I've seen numerous people (myself
>> included) mistake the two. Hey Tantek, why don't you tell everyone
>> the story about how you and Kevin confused the two and wrote the
>> wrong one into vote-links? :D
> 
> I meant 'thick' in the nicest possible way (myself included). I'm more
> than willing to admit that there's a whole lot that I don't know and I
> don't appreciate for a moment that IE3/4 were forgiving of my bad
> markup when I was learning to build sites. I stagnated for a long time
> building crappy markup because of that.

Ara, the point is that with rel/rev in particular, it has confused *even the
people that are supposed to be experts*.  As Ryan points out, I myself got
it wrong when I initially proposed to Kevin Marks that we use 'rel' for
VoteLinks instead of their initial idea of using a new HTML attribute
'vote'.  In fact I can say that *everyone* (without exception) I have spoken
with who has tried to use rel/rev has made this mistake at some point,
including a lot of the people on this list.

The 'rel' / 'rev' distinction is perhaps one of *the most* confusing things
in HTML4 (if not *the most confusing*).  It is an outlier in the extent of
confusion caused.


>> Also, 'bending to popular usage' is what microformats are all about.
>> We try and figure out how people are already using the web, the
>> vocabulary that they use and the common use cases, then document that
>> into a microformat.

I know Ryan was summarizing, but to be clear (since this is a common
misconception), how people are using the web is taken as an *input* to the
process[1], NOT the conclusion.  From those real world examples we produce
analysis, implied schemas etc., and then take as additional input
established vocabulary, formats etc. and synthesize them through the process
into brainstorms which are eventually distilled into microformats.

>> Formats and applications should follow behavior,
>> not try and create it.

Yes.  Certainly for the 80/20 case.  And certainly pre-existing behavior
should drive the development of a format.  Only in the rare case that there
is no pre-existing behavior for a type of data does it make sense to try and
invent, but that set of solutions is outside the scope of microformats since
microformats are based on paving the cowpaths.


> I think that the spirit of microformats is right in adopting the
> standards that are in popular usage (ie adopting vcard for hcard). But
> at the same time, I think it's a mistake to adopt bad practices and
> use them because "everybody does it".

Agreed.  Hence why I pointed out that existing practices are only an *input*
to the process, not the conclusion.


> Best example of not doing this
> is the steady stream of developers now dropping table based design.
> The alternative would have been for the spec writers to say "well,
> everyone's using it, let's just alter the spec in the next version to
> state that tables are also inteded for use in layout".

Right, user/developer behavior is an indicator of the *need* for a solution,
not necessarily the solution itself.  Hence W3C took that behavior as input
and produced CSS table layout as a solution, rather than simply saying "go
ahead and use <table> for layout".

Thanks,

Tantek

[1] http://microformats.org/wiki/process