Processing Link headers states "These headers are to be processed according to the rules given in the relevant specifications" and that "Registration of relation types in HTTP Link headers is distinct from HTML link types, and thus their semantics can be different from same-named HTML types".

However, Web Linking states "It is semantically equivalent to the <LINK> element in HTML", so it seems that the specs are sort of pointing at each other. Since Web Linking claims they are semantically equivalent to the <LINK> element, we should at least point to the obtain the resource in HTML. I imagine to be more formal maybe should define a collection of the given Link headers that we can "obtain" before parsing the document?

Furthermore there are some processing bits that are relevant for Link headers that are not necessarily a concern for normal <link> processing. Generally Link headers can be fetched immediately, however some headers require viewport information that might not be available when the headers arrive (and would otherwise be fetched):

• Link headers with media attribute
  • media attribute helps determine whether a rel=stylesheet is script-blocking or not
  • also for rel=preloads it determines whether or not the resource should be obtained
• Link headers with imagesrcset and imagesizes attributes (/cc @irori @kinu ran into this when implementing also cc @yoavweiss )

Implementers will need to defer the fetching of these Link headers until the viewport info is available (Chrome waits until the first chunk of the document is parsed IIUC) so I think it might be nice to indicate this in the spec in some way.