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

Ryan King ryan at technorati.com
Wed Oct 19 00:07:54 PDT 2005

On Oct 18, 2005, at 12:50 PM, Charles Iliya Krempeaux wrote:

> 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).

Except for Windows IE.

> (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?


These are, by no means, mutually exclusive.

> (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?

I'm not sure what point you're trying to make here. URN is not an  
option, it is no longer a valid attribute.

>> 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?)

Not quite. We're using the class attribute to apply semantics where  
no existing tag or compound would work. See Tantek's presentation on  
Semantic XHTML for some examples[http://tantek.com/presentations/ 


Ryan King
ryan at technorati.com

More information about the microformats-discuss mailing list