[microformats-discuss] RFC: Thoughts on Video and Audio Microformats

[Charles Iliya Krempeaux]

Hello,

On 10/18/05, Dr. Ernie Prabhakar <drernie at opendarwin.org> wrote:

[...]

> > The "class" attribute and the "title" attribute imply absolutely no
> > semantics (as far as I know).
>
> Um, not quite.  Let me try to explain, though Tantek or Ryan could
> probably do better.  First of all, you *are* correct in that the
> preferred method is to reuse *existing* HTML semantics; the URN trick
> is rather clever, I must admit.
>
> However, there's a deeper design principle at stake: human-
> readability.   The one concern I have with URNs -- even more than the
> fact that they are deprecated -- is that they are pretty much opaque,
> and somewhat confusing.

I like to get some clarification here.  When you say "The one concern
I have with URNs... is that they are pretty much opaque".  Who are you
talking about?  Opaque to who?

There are (at least) 2 parties involved.  The person scripting the
HTML code.  And the person viewing the HTML code (through their
browser).  (You could also consider web crawlers and other "machines"
to be parties too.  But I won't get into that here.)

To the person scripting the HTML code, the "urn" attribute is no more
opaque than the "rev" or "rel" attribute.  If we consider that using
"rel" and "rev" is good practice (for Microformats) then I can't see
why "urn" wouldn't be acceptable also.  (Well, if it was still part of
the latest HTML spec, that is.)

And to the person viewing the HTML code,.... Just so I understand
things, what makes "title" and "class" non-opaque?  OK, "title" will
popup up a "tooltip" (at least in my browser).  But "class" is only
visible when you apply a "style" to it.  But there is nothing stopping
you from applying styles based on the "urn" attribute (or any other
attribute).  (I've seen some nice examples of applying styles based on
the "rel" attribute to find XFN usage.)

> To better match how humans handle HTML, we leverage CSS class name,
> as seen in hCalendar and hCard:
>
> http://microformats.org/wiki/hcalendar
> http://microformats.org/wiki/hcard

I think that many people only use the "class" attribute to apply
style.  And it has little to do with (usable) semantics.  (If often
amounts to what I consider an abuse of the <span> and <div>
elements,... must like we had an abuse of the <table> and <font>
elements before.)  But I do agree that there are certain cases when
the "class" does imply semantics.  For example, people sometimes do
things such as the following:

    This is <span class="highlight">so cool</span>!

    <div class="note">NOTE: You must be there before 11:00pm.</div>

(Which is where I think you are coming from.  Although Microformats
like hcard and hcalerdar have more "structure" to them... in the same
way that <table> has more structure.)

I.e., they use the "class" attribute with <span>'s and <div>'s to
effectively make up new tags (not found in HTML).

Also we see people using the "class" attribute to create
specializations of existing tags.  For example:

    <a class="wiki-link" href="http://example.com/wiki/NewTube">NewTube</a>

    <a class="some-other-kind-of-link"
href="http://example.net/a/b/c">Click It</a>

I think we need to consider how Microformats are going to be used...

    #1 Are they something we expect people to script by hand?
    #2 Or are they something people are going to generate with "code
builders" and embed into webpages?

(Certainly if #1 is our objective then #2 can certainly be met too
without any conflict to #1.  But anyways.)

If it is #2, then we should NOT use "urn".  But we should also note
use "rel" or "rev".

But it is #1, then attributes seems acceptable.  Or am I missing something?


> To be sure, there is some risk:
> > And there could be systems (either now
> > or in the future) that transform HTML that break Microformats because
> > they relied on the "class" or "title" attributes.
>
> However, here's the point I think you are missing.   The underlying
> premise of microformat as class names is that they *naturally*
> reflect the underlying semantics.

Well,... for English-speaking/writing people anyways :-)

> Hence the concept 'semantic salt'
> -- bringing out that which is latent.   If those class names do in
> fact reflect what the designer  *means* by the use of those elements,
> then:
>    i) this is in fact the optimal way to identify those styles
>    ii) any transformation that obliterates that metadata will
> (inevitably) lose information
>
> That isn't to say that my proposal is perfect -- it's a very crude
> first approximation.  However, I hope this at least gives you a bit
> more clue about the parameter space we're trying to explore, and our
> criteria for success.

Yes,... I think I understand.  You are using the "class" attribute to
"invent" new tags.  (Is that correct?)


See ya

--
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com

     developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from