On May 27, 2007, at 5:09 AM, Benjamin Hawkes-Lewis wrote:


It doesn't make any sense to me. When browsers (e.g. Opera) or extensions (e.g. Firefox Link Widgets) properly expose <link>ed resources, they are just as visible as anchors. That would work very nicely.

When browsers or extensions expose <link>ed resources, they generally do so for a selected set of <link> types (for example, <link rel="stylesheet"> is not exposed) and often do so with specialized UI (for instance, feed links, those being <link rel="alternate"> with a syndication feed MIME type, or per HTML5 ones with rel="alternate feed" are often displayed

Some link relationships only make sense on one of <a> or <link>. That being said, I think it makes more sense to call a link to a page with editing UI rel="edit", than one with a PUT-able location for the document, I would call the latter rel="writeable". Since Atom Publishing Protocol is only a draft, I wouldn't assume it is unchangeable, and they seem to have take a notion of "edit" that is pretty specific to newsreader applications.

Naming two entirely different things the same invariably produces confusion (e.g. some authors don't understand the rather different semantics of the cite attribute and the cite element). Making names have semantics dependent on context is even worse. Making a new link type work differently to other link types by having two sets of semantics is also a bad idea IMHO.

I wonder, though, if marking up the edit link has a real use case. What kind of tool would make use of it, and in what way?

Browsers could be configured to open webmail compose links in a new window.

My understanding of the proposal is that rel="edit" is intended for a link to edit the current document, as in a wiki. Thus, it would not be appropriate, as proposed, to put on a webmail compose link, or even a webmail reply link, since neither is an example of editing the current document.

Additionally, I think it would be really bad for interoperability if some but not all browsers interpreted rel="edit" to mean "open in a new window". So this idea is unlikely to be implemented.

Compare your suggestion of this use-case to the WHATWG list:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/ 011098.html

Actually, that suggestion was about links *in* mail messages that you received, which being viewed in a webmail client. And in the context of link targeting. I don't think it is related to the rel="edit" proposal.

Now Atom's semantics may throw a cog in the wheel of rel="edit". But how about differentiating rel="edit" from Atom's rel="edit" by using rel="compose" instead? Or, alternatively, we could try and get the Atom draft changed to use rel="put" since "edit" is rather vague?

Sounds to me like rel="compose" would not be a good way to label the "edit this page" link on a wiki page.

Getting back to the proposal, the canonical use for rel="edit" proposed was for "edit this page" links on wikis and similar. To determine if it is useful, I think we need to identify what things web browsers, data mining tools, browser extensions or other user agents might do with the knowledge that some particular link is an "edit this page" or "edit this section" link.

Regards,
Maciej



_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss

Reply via email to