[whatwg] Where did the "rev" attribute go?

Hello Matthew,

On 7/11/06, Matthew Raymond <mattraymond at earthlink.net> wrote:
>
> Charles Iliya Krempeaux wrote:
> > Perhaps I can illustrate what I mean with an example.
> >
> > (But first note that people can make up their own values for "rel" and
> > "rev".  But anyways, here's the example.)
> >
> > Let's say in a page, I have the following HTML code...
> >
> > <li class="xoxo shows">
> >     <li><a rel="show" href=" http://show.example.com/">Example IPTV
> > Show</a></li>
> >     <li><a rel="show" href="http://show2.example.com/">Another Example
> > IPTV Show</a></li>
> > </li>
>
>    (Not the best example, because "show" can be a verb.)
>
> > The semantics here are....  The class-xoxo (on the <li>) says that I'm
> > giving a list here.  And the class-shows says this thing is/has
> > "shows".  (So basically, I'm listing shows.)
>
>    Wouldn't this be a lot like using |rel| to define a media type?
> Granted, it's more the example you're using than your general concept
> that's causing the confusion.


Perhaps it's a poor example.  But what I've gotten from the specs is that
the "rel" attribute can be used in this way.



> The rel-show inside the "list of shows", says what's at the end of the
> > "href" is a "show" for the list of "shows".
> >
> > So,... if you go to the URL in the "href", you get a whole HTML page
> > with all sort of stuff in there.  But what is the "show"?  The whole
> > page?  Just part of it?
>
>    How about the element that has the ID that's in the URL in the |href|
> attribute? That would take you directly to the element in question. I
> think |xml:id| is pretty much a standard now.


Yeah, that would definitely be better from a developer's point-of-view.  And
there are times when you do do that.

But sometimes, you can't do that.

Perhaps the HTML fragment that you want has no "id" on it.  (And you have no
control of the page any you can't add it.)

Or, even if it does have it, perhaps linking to that fragment makes for poor
usuability.  And in terms of usability it's better to link to the page
(without the fragment identifier -- without the "id".)  (I.e., jumping to
that part of the page would be "bad" from the usability point-of-view.... Or
maybe doing so skips the ads on the page, and would mess up the business
relation you have with that publishers.)

Or perhaps the thing you want there is spread out into multiple HTML
fragments on the page.  (I show an exampe of this later on in this e-mail.)


> Well, I then search the page for [class "show"].  (I look for something
> > inside the page with a class with the same token/name use in the "rel"
> > that linked there.)
>
>    What if the web page you're linking to has the class name
> "JoeMunchey" instead of "show"? You're requiring people to examine the
> HTML of the target page in order to use this feature. The |rel|
> attribute doesn't have this requirement; you need only to know what the
> nature of the target page is.



What I'm saying is that peolpe would choose their "rel", "rev", and "class"
names ahead of time.  And everyone would agree on them.

And you'd have a (defacto) standard created.  (A Microformat possibly.)

So that people who made a "show" (would be aware of the standard ahead of
time and) would mark up their pages with the class-show.  (And anything else
the standard required or asked for.)

And people would make their "list of shows" with rel-show point to each show
in their list.

But,... people would agree on these ahead of time.


For an example that's gained some popularity, look at hCard.
http://microformats.org/wiki/hcard

People wanted to semantically denote "contact info".  So they choose a set
of class names to use (to do this) and some rules about them.

Creating the standard is a somewhat arbitrury process.  And requires humans
to do it.

Although with opaque semantics, like the "rel" name matching the "class"
name, you don't need a human intervention to parse much of it.

Does what I'm saying make sense?  Or should I explain it more?



> If I find (just) one, then great, that's probably what I want to
> > concentrate on.  (The other parts of the page are probably
> [irrelevant].)
> > If not, I'll probably have to concentrate on the whole page.
> >
> > (This is the idea of opaque semantics that I was talking about before.)
> >
> > Does that clear it up?
>
>    It seems like some sort of a link-to-class, rather than linking to a
> URL + ID. I don't see the point. How is anyone going to see this on
> their browser? Will it open multiple tabs? I'm not thrilled about giving
> authors the ability to open multiple tabs or windows in my browser
> without my consent. Will it create a drop-down that lists all the
> elements that are part of the class? This will not give me any
> contextual information from the page that may help me figure out which
> element I want to look at. In fact, if I were creating a page about
> various shows, most if not all of the information on the page would be
> contextual or supporting information for the shows contained within.
>
>    Sorry, but I just don't see the use case.



Alot of this is done for the benefit of machines (like browsers, spiders,
search engines, etc).

It lets you add a bit of "semantic salt" to bring out the "meaning" in the
HTML so that machines can understand the meaning of what you are saying too.

I wrote a kind of intro to this a while ago.  I've had people (who able web
developers but know nothing about semantic HTML) say that it's easy to read,
so I'll refer you to that...
http://changelog.ca/log/2005/09/12/proposed-microformats-for-reputation-and-trust-metrics

(It's about trust metrics and reputation with HTML... but it should give you
a use case for it.  If it needs more explaining please let me know.)


But getting back to one things you said... it is NOT always the case that
you can "grab" something with an "id".  Sometimes using "class" works
better.

For example, consider if I wrote an article.  And, in the HTML for that
article, I mark certain parts of it as being part of a "summary" for it.
For example....

<p>
    <span class="summary">Blah blah blah.  Blah blah blah blah.  Blah blah
blah blah.</span> Blah blah.
</p>
<p>
    Blah blah blah blah blah.  Blah blah blah blah.  Blah blah blah blah.
Blah blah.  <span class="summary">Blah blah blah.</span>
</p>
<p>
    Blah blah blah.  Blah blah blah blah.  Blah blah blah blah. Blah blah.
</p>

How would I grab that with an "id".

The class-summary's in there let me get at the summary that spread out in
multiple fragments.


Just one other example for good measure.  Consider this code...

<p>
    I am <a href="http://changelog.ca/">Charles Iliya Krempeaux</a>.
</p>

As a human you can understand what that means.  You know it is a statement.
You know "Charles Iliya Krempeaux" is a name.  You know that "
http://changelog.ca/" is the site for "Charles Iliya Krempeaux".

But a machines does not know that.  It cannot figure that out.

That's where some "semantic salt" can be helpful.  hCard's let us add a
little semantics to make it so machines can figure out the "name" part of it
too.

So, if I were add an hCard I'd get...

<p>
    I am <a class="vcard fn url" href="http://changelog.ca/">Charles Iliya
Krempeaux</a>.
</p>

(The class-vcard, class-fn, and class-url are all part of hCard.)

With just that, machines now know that "Charles Iliya Krempeaux" is a name.
And "http://changelog.ca" is the site for "Charles Iliya Krempeaux".

I could even add more semantics....

<p>
    I am <a class="vcard fn url" href="http://changelog.ca/"><span
class="given-name">Charles</span> <span class="additional-name">Iliya</span>
<span class="family-name">Krempeaux</span></a>.
</p>

Now, not only does it know that "Charles Iliya Krempeaux" is a name.  But it
also knows that "Charles" is the person's "given name".  That "Iliya" is
that person's "additional name".  And that "Krempeaux" is that person's
"family name".

(If you are coming from an XML point-of-view.  Using the class names for
semantics is almost like entangling XML within HTML.  If that makes sense.)

>> I would think something like "linktype" would be more appropriate.
> >> That said, |rel| is pretty much already corrupted to mean that, and if
> >> we introduced another attribute for the purpose of link types, it would
> >> either go unused for backwards compatibility reasons or it would
> >> supplant both |rel| and |rev|.
> >
> > I suggested "hrefclass" because we already have things like... "lang"
> > and "hreflang".  It just seemed to follow the same style.  (Since this
> > seems to be just like the "class" attribute, expect we are applying it
> > to what is at the end of the "href"... so "hrefclass".)
>
>    That would be more appropriate for what you've described above. I
> just don't see the point of it.
>

Just a method of allowing web developers to add "semantic salt" to the
HTML... and to allow for opaque semantics where the token/name used in the
"class" attribute can be reused in the "hrefclass" too.


See ya

-- 
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Make Television                                http://maketelevision.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060711/750c0e67/attachment.htm>

Received on Tuesday, 11 July 2006 14:52:08 UTC