rel=bookmark

# Ed Summers (3 days ago)

I was wondering if anyone can provide any information, or a pointer to previous discussion, about why the bookmark link relation can't be used with the <link> element [1].

The topic has come up recently on the IETF link-relations discussion list [2] where a new link relation has been proposed to encourage persistent linking [3]. The proposed 'identifier' relation seems to closely resemble the idea of a permalink (a persistent link) that can be found in the definition of bookmark. If bookmark allowed use with the <link> element then I think there would be less of a demonstrated need for the new 'identifier' link relation.

Thanks for any information you can provide. I apologize if I'm restarting a conversation that has already happened.

//Ed

[1] www.w3.org/TR/html5/links.html#link-type-bookmark [2] www.ietf.org/mail-archive/web/link-relations/current/msg00670.html [3] datatracker.ietf.org/doc/draft-vandesompel-identifier

Contact us to advertise here
# Domenic Denicola (3 days ago)

(Remember to use the HTML Standard, located at html.spec.whatwg.org/multipage/links.html#link-type-bookmark, not any forks of it.)

Right now the bookmark link relation has a specific purpose, as you can read in the spec:

The bookmark keyword gives a permalink for the nearest ancestor article element of the linking element in question, or of the section the linking element is most closely associated with, if there are no ancestor article elements.

Your proposal is essentially to give it an entirely separate meaning when used in the context of the <link> element, but that's not usually how we share link relations between the different elements: cf. alternate, author, help, license, next, etc.

At least, that is how I understand; I'm having a hard time distinguishing what "identifier" is for in practice, and in particular why it is different than "canonical".

# Kevin Marks (3 days ago)

That use case sounds more like rel="canonical"

# Philipp Serafin (3 days ago)

As the IETF usecase seems to be about permalinks, is there any requirement for rel=canonical regarding validity in the future?

Am 06.08.2017 3:20 vorm. schrieb "Kevin Marks" <kevinmarks at gmail.com>:

# Ed Summers (2 days ago)

On Aug 6, 2017, at 6:13 AM, Philipp Serafin <phil127 at gmail.com> wrote:

As the IETF usecase seems to be about permalinks, is there any requirement for rel=canonical regarding validity in the future?

Yes, the quality of persistence is why I thought rel=bookmark worked best, although canonical was the relation I first thought of too.

As the IETF draft authors describe in a related blog post [1] canonical was dropped from consideration because it exists to "identify content that is either duplicative or a superset of the content at the context (referring) IRI" and does not speak to the durability of the link.

//Ed

[1] ws-dl.blogspot.com/2016/11/2016-11-07-linking-to-persistent.html

# Ed Summers (2 days ago)

On Aug 5, 2017, at 9:19 PM, Domenic Denicola <d at domenic.me> wrote:

(Remember to use the HTML Standard, located at html.spec.whatwg.org/multipage/links.html#link-type-bookmark, not any forks of it.)

Oops, my bad! Luckily the definition looks the same so I think my question is still relevant?

Right now the bookmark link relation has a specific purpose, as you can read in the spec:

The bookmark keyword gives a permalink for the nearest ancestor article element of the linking element in question, or of the section the linking element is most closely associated with, if there are no ancestor article elements.

Your proposal is essentially to give it an entirely separate meaning when used in the context of the <link> element, but that's not usually how we share link relations between the different elements: cf. alternate, author, help, license, next, etc.

I don't think allowing rel=bookmark to be used with <link> would change the meaning because of the clause "... or of the section of the linking element is most closely associated with". If the <link> were used in the <head> of an HTML document then the bookmark would be associated with the HTML document itself, not some section within it.

At least, that is how I understand; I'm having a hard time distinguishing what "identifier" is for in practice, and in particular why it is different than "canonical".

Yes, I initially thought canonical was the logical choice too. But as the draft authors point out, canonical [1] says nothing about persistence and is used instead to indicate a preferred URL for duplicative content.

//Ed

[1] tools.ietf.org/html/rfc6596

# Ed Summers (16 hours ago)

On Aug 5, 2017, at 9:19 PM, Kevin Marks <kevinmarks at gmail.com> wrote:

That use case sounds more like rel="canonical"

You weren't the only one (myself included) who thought that. Michael Nelson, one of the authors if the identifier I-D, just wrote a blog post explaining why not canonical:

http://ws-dl.blogspot.com/2017/08/2017-08-07-relcanonical-does-not-mean.html

I think I'm convinced that canonical isn't the right fit for what they are talking about. But if rel=bookmark could be used in <link> elements I think it would work better than a slightly similar, oddly named, link relation, which IMHO is bound to cause confusion for web publishers.

//Ed

# Kevin Marks (15 hours ago)

This sounds like what we use uid for in microformats - the url that you want as the persistent identifier.

microformats.org/wiki/uid - it looks like you wrote this up a while back, Ed.

See u-uid in h-entry microformats.org/wiki/h

# Kevin Marks (15 hours ago)

See also microformats.org/wiki/sharelink-formats for a (recent) related use case

# Ed Summers (14 hours ago)

On Aug 8, 2017, at 2:04 PM, Kevin Marks <kevinmarks at gmail.com> wrote:

See also microformats.org/wiki/sharelink-formats for a (recent) related use case

On 8 Aug 2017 7:01 pm, "Kevin Marks" <kevinmarks at gmail.com> wrote:

This sounds like what we use uid for in microformats - the url that you want as the persistent identifier.

microformats.org/wiki/uid - it looks like you wrote this up a while back, Ed.

Oh boy, that is going back a ways yes :) I see some of that documentation still refers to HTML 4!

I guess I'll put a contribution together that adjusts rel="bookmark" and see how it fares. Thanks for the feedback everyone.

//Ed

# Ed Summers (12 hours ago)

On Aug 8, 2017, at 3:43 PM, Ed Summers <ehs at pobox.com> wrote:

I guess I'll put a contribution together that adjusts rel="bookmark" and see how it fares. Thanks for the feedback everyone.

I started with an issue ticket [1] that references this conversation in case anyone is interested in following along there.

//Ed

[1] whatwg/html#2899

Want more features?

Request early access to our private beta of readable email premium.