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
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
