[uf-discuss] rel-edit

[Benjamin Hawkes-Lewis]

Maciej Stachowiak wrote:

> 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)

It is when you have a series of alternate stylesheets (in Firefox, 
anyhow), isn't it?

> 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>.

None of that equates to having a single name for two /different/ link 
relationships.

> 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.

Agreed.

> 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.

Hmm. Yes I agree there is a distinction between editing the current
resource and creating a new document. My main point was that this could 
be used for deciding when to open a new window.

> 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.

Why would UAs behaving differently with respect to rel="edit" be bad for 
interoperability? UAs already differ when it comes to opening new 
windows. And rel attributes give users criteria by which to decide 
whether to open new windows, rather than have it dictated by authors.

>> 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.

Eek, sorry Maciej. I misremembered your WHATWG post and didn't reread it
carefully enough (I compose emails in a new window and completely 
confused the two).

>> 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.

Agreed.

> 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.

A second use-case for rel="edit" (or whatever) would be to add a Edit 
link to the navigation toolbar. This would provide a more consistent UI: 
no more searching around for the edit link.

--
Benjamin Hawkes-Lewis