[whatwg] Absent rev?

[Smylers]

Martin McEvoy writes:

> Ian Hickson wrote:
> 
> > given the way that the "rel" attribute and the related keywords are
> > defined, rel=author does in fact convey the semantics that rev=made
> > did.
> 
> No It doesn't

Yes it does; it's specified that they are equivalent:

  For historical reasons, user agents must also treat link, a, and area
  elements that have a rev  attribute with the value "made" as having
  the author keyword specified as a link relationship.

  -- http://www.whatwg.org/specs/web-apps/current-work/multipage/structured-client-side-storage.html#link-type-author

> Reverse and Inverse properties are key factors of any Semantics

OK.

> without both @rev and @rel there is hardly any semantics at all just a
> one way stream of information,

That simply isn't true, since it's always possible to define rel=foo and
rel=bar where bar conveys the same semantics as foo but in the opposite
direction; no rev needed.

> which most of the time you have to guess what the Authors intentions
> were.

Not at all, since part of the definition of the rel values says in which
direction they are to be interpreted.  For example, rel=author

  indicates that the referenced document provides further information
  about the author of the section that the element defining the
  hyperlink applies to.

> rel=author on the whole only relates to published documents,  rel=made
> relates to  Documents, Music, Photos, Videos, Sunday Lunch! Literaly
> anything that can be *made*

So the problem is that if I wanted to be able to create a link from my
Sunday lunch to its cook, annotating it as such, I wouldn't be able to
do so because rel=author isn't appropriate terminology to use in meals?

That's true, but given that my Sunday lunch isn't written in HTML
anyway, I don't see how it could be trying to use rel=author (or indeed
rev=made) in the first place!  Ditto for all your other examples.  By
definition the thing which is making the rel=author link has to be
written in HTML 5, and therefore has an author of some sort.

> > Furthermore, since the definition of "rel" in HTML5 allows
> > relationships in either direction to be defined, there is no need
> > anymore for a separate rev="" attribute.
> 
> So essentially @rel in html5 is breaking the semantics of @rel just
> because it cant deal with @rev?

No, the semantics of rel aren't changed from existing use; HTML 5 takes
care not to break existing widespread use.

> > > the misuse of "stylesheet" is trivial and only a matter of
> > > informing  authors of their error
> > >     
> >
> > Well, who's going to be doing the informing?
> 
> The publishers of HTML5

Why should they bother to do that when then can more easily define the
problem no longer to exist?

> > Authors who today use rev="made" could equally well use rel="author"
> > without loss of generality IMHO.
> 
> OK then example:
> 
> I am the author of numerous websites and I decide (like many people do)  
> to place some links on my homepage a portfolio If you like.
> My Homepage is at : http://groovydeveloper.com/
> Here is my link <a rel="author" href="http://somegroovysite.com/"> Groovy  
> Site</a> 
> 
> Above Statement (In HTML4) says
> 
> <http://somegroovysite.com/> Authored  < http://groovydeveloper.com/> 
> 
> Which Is rubbish its the other way round

Indeed.

> The Same statement in HTML5 will say (because @rel is a reverse and
> inverse link type)

I don't understand what you mean by the part in parentheses.  Please
could you expand on it, or provide a reference.

> <http://somegroovysite.com/> Authored  < http://groovydeveloper.com/> 
> and
> < http://groovydeveloper.com/>  Authored <http://somegroovysite.com/> 

Of course not.  See my quote from the rel=author part of the spec above;
it clearly defines in which way that relationship applies.

Among the set of relationships that rel allows there are relationships
in each direction (both from and towards the current document), but a
given relationship is always unambiguously defined to be in a particular
direction.

> > If there are redundant features that are only used 0.2% of the time,
> > we should probably remove them, yes. Are there any?
> 
> A lot considering that the average website only uses 19 elements[1]

That simply doesn't follow.  There are many ways in which hundreds of
different elements could be distributed throughout a population such
that each of them are used on more than 0.2% of pages yet the mean
elements per page is 19.

Smylers