W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2017

Re: [whatwg] rel=bookmark

From: Ed Summers <ehs@pobox.com>
Date: Mon, 7 Aug 2017 10:27:07 -0400
Message-Id: <9294EF7B-8D7A-4984-9423-D4F31078E0FB@pobox.com>
To: Domenic Denicola <d@domenic.me>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
Hi Domenic,

> On Aug 5, 2017, at 9:19 PM, Domenic Denicola <d@domenic.me> wrote:
> 
> (Remember to use the HTML Standard, located at https://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] https://tools.ietf.org/html/rfc6596
Received on Monday, 7 August 2017 14:27:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 7 August 2017 14:27:39 UTC