- From: Tore Eriksson <tore.eriksson@po.rd.taisho.co.jp>
- Date: Thu, 06 Jul 2006 13:21:17 +0900
Hello everybody. Regarding usage of "rev", I would like to point out the RDF/A proposal http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-syntax.html where they use "rev" to incorporate RDF into (X)HTML documents. As for myself, I use the "rev" attribute in an internal project (sorry, no link) at work. I have to agree with Charles/Iliya that the recognition of "rev" is probably going up in the future if the adaption of new microformats continues. Ian Hickson wrote: > On Wed, 5 Jul 2006, Charles Iliya Krempeaux wrote: > > > > It would be a shame to get rid of it now, now that web developers are > > starting to become "semantically minded". > > On the contrary, I would argue that we should get rid of it as fast as > possible, so that we don't scare away authors who are becoming > "semantically minded" by making the language more complicated than > absolutely necessary. > I have to disagree here. Removing the complexity in the HTML specification just moves it to the semantic application where the "semantically minded" users have to agree on what the corresponding inverse relations are. In my opinion the HTML spec is the place where this distinction can be kept with the least amount of "interfering" complexity. As your survey shows, there is not a lot of confusion about "rev", just some people having problems with spelling the "rel" attribute. I think there would probably have been a lot of "herf" attributes out there if they were not discovered as easily as they are. > > As developers start building semantics into web technologies, their > > going find that they need the "rev" attribute. (Not sure if that would > > be enough "justification" here to keep it. But since we already have > > it, it would be nice to keep it.) > > For HTML5 the assumption is that we're removing everything unless we can > put forward a convincing argument to keep it. > > What are the use cases for "rev"? Do they outweigh the author cost? See RDF/A. What is actually the author cost in keeping the "rev" attribute? Wouldn't you say that there is a cost in removing it as well? And removing it also contradicts the statement "care has been taken to ensure that backwards-compatibility is retained" in the draft (1.3.) > > > That is essentially my personal reason for wanting "rev". So that the > > exact same label can be used no matter what the direction of the > > relation. (That way a generic parser and query engine can be written > > for this type of stuff, even if the system does NOT understand the > > meaning of the labels.) And there might be cases when the relationship is different in the two directions. I just have to come up with some convincing example... > > While I understand what you're saying, it seems highly theoretical. Data > on authoring practice shows that authors simply don't understand rev="": > the top five <link rev=""> were made, stylesheet, owns, author, and owner. > rev="made" is the only one of those where rev="" wasn't a typo for rel="". > > Usage of <a rev=""> was so low that even the "height" attribute on the > "space" element is used more often, according to the data I have. And the > <space> element doesn't even exist! In contrast, the <a rel=""> attribute > was used more than 60 times more often than the <space height="">. (I use > <space height=""> as the example here because that's the least-used > attribute that I actually recorded data for; <a rev=""> is used so rarely > that it didn't even appear on my top-1000 attributes list. I have data > regarding <a rev=""> values because I specifically recordeded rel/rev data > in the study, to determine whether or not we should keep rev="".) Just for reference, what was the usage of the "hreflang" and "media" attribute in anchor tags? At what usage level do you feel it is apropriate to compromise backward compability by removing an attribute? Regards Tore _______________________________________________________________ Tore Eriksson [tore.eriksson ad po.rd.taisho.co.jp]
Received on Wednesday, 5 July 2006 21:21:17 UTC