[uf-discuss] rel-edit

[Maciej Stachowiak]

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