mjs at apple.com
Sun May 27 15:16:57 PDT 2007
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
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
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:
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"
> 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
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.
More information about the microformats-discuss