New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`Link` header processing not defined #4224

Open
domfarolino opened this Issue Dec 5, 2018 · 3 comments

Comments

3 participants
@domfarolino
Copy link
Member

domfarolino commented Dec 5, 2018

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.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Dec 10, 2018

I think Firefox waits as well, which for rel=stylesheet (which I'm not sure other browsers support) is important due to quirks mode et al.

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Dec 24, 2018

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)

AFAIK, the same is true for WebKit as well.

so I think it might be nice to indicate this in the spec in some way.

Agreed. At the same time, I think Chrome currently performs some optimizations that WebKit does not, so we need to spec language to allow for that.

@domfarolino

This comment has been minimized.

Copy link
Member Author

domfarolino commented Jan 10, 2019

As Anne pointed out elsewhere, https://drafts.csswg.org/cssom/#requirements-on-user-agents-implementing-the-http-link-header seems worth looking into more, though it is relatively incomplete at the time of writing this. (Just making note of it here).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment