Skip to content
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 · 19 comments
Open

Link header processing not defined #4224

domfarolino opened this issue Dec 5, 2018 · 19 comments

Comments

@domfarolino
Copy link
Member

@domfarolino 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
Copy link
Member

@annevk 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
Copy link
Collaborator

@yoavweiss 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
Copy link
Member Author

@domfarolino 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).

@domfarolino
Copy link
Member Author

@domfarolino domfarolino commented Jun 10, 2020

As per https://bugs.chromium.org/p/chromium/issues/detail?id=19237, Chrome is not interested in implementing the Link rel=stylesheet headers, and I believe Firefox is the only browser that implements this feature. Should we consider removing this from the spec? I guess that would entail changing the CSSWG draft mentioned above, as well as mentioning in this spec that the stylesheet relation is not supported by the Link header.

What do people think about this?

@domenic
Copy link
Member

@domenic domenic commented Jun 10, 2020

I agree that if this is only supported by one implementer then it should be removed from the spec.

I guess Chrome does support Link for other rels though, e.g. preload. So fully closing this issue would involve specifying the processing model for those.

Here's one idea for a plan:

@awwright
Copy link

@awwright awwright commented Jun 10, 2020

I would like to see support for the Link header, I think this belongs in Web browsers. But I'm struggling to see how this is an HTML issue; especially since one of the use-cases is styling non-HTML media types (which is supported by CSS). So I think this should be factored out of HTML.

Web browsers should be able to process a Link from multiple sources—an HTML <link> header being the most common, but the Link header too; and they should process it the same way.

@annevk
Copy link
Member

@annevk annevk commented Jun 11, 2020

The HTML Standard defines page load for all web browser resource types, not just HTML. See the section "Browsing the Web".

@awwright
Copy link

@awwright awwright commented Jun 12, 2020

@annevk That should be factored out. HTML has no business being the Web Browser Specification(TM)

@domfarolino
Copy link
Member Author

@domfarolino domfarolino commented Jun 12, 2020

Says who?

@awwright
Copy link

@awwright awwright commented Jun 12, 2020

@domfarolino In short, RFC 6838; I opened #5639 to provide more details.

@yoavweiss
Copy link
Collaborator

@yoavweiss yoavweiss commented Jun 12, 2020

@awwright - I doubt you'd have much success in convincing the HTML spec editors and browsers to modify how browsers' processing model is defined.

Specifically for Link headers, if we were to properly define support for stylesheets, we would need to define how they interact with the cascade and in-document stylesheets. That definition needs to live in HTML.

Link header support for stylesheets also introduces complications in case there are more than one header, as HTTP intermediaries can change the order of headers. That's contrary to the HTTP specification, but never the less is something I've seen happening, so I'd be highly reluctant to introduce content reliance on proxies doing the right thing, as in those cases applying those styles can result in different applicable styles based on e.g. which cache the page went through.

At the same time, on the issue that's been open for the last 11 years, I haven't heard any strong use-cases as to why this is something that the web needs.

If you have clear & strong use-cases for Link header application of stylesheets, I'm more than willing to hear them.
The only use-case I heard so far is application of styles to image documents.
Theoretically we could support:

  • Application of Link styles only to image documents
  • Assuming there's a single Link header, to avoid potential cascade issues

It would still be something that requires implementer interest in order to add such support in Chromium or WebKit. I'm not aware of such interest.

@j9t
Copy link
Contributor

@j9t j9t commented Jun 14, 2020

I’m in favor of this feature and keeping it in the specification: It’s amazing to make websites simpler and more maintainable and may just have received too little attention. (Which was certainly due to lack of support, but is generally not the first and only time this has happened.)

How can outside developers best make and support the case? I suppose the most effective way was to somehow convince another vendor to implement the header (those here involved with Chrome, what would tip the scale?), but do you see additional options that could also help?

PS.
I’d have some thoughts about some of the concerns (@yoavweiss), though these definitely include authors making a conscious choice, weighing pros and cons of each approach.

@yoavweiss
Copy link
Collaborator

@yoavweiss yoavweiss commented Jun 14, 2020

I’m in favor of this feature and keeping it in the specification: It’s amazing to make websites simpler and more maintainable

Could you please elaborate on how this feature would do that? What would it enable you to do that is not possible today?

those here involved with Chrome, what would tip the scale?

An actual strong use-case that this feature would enable would be a good start.

@annevk
Copy link
Member

@annevk annevk commented Jun 15, 2020

I thought the way this works in Firefox is that there is a shared processing model so it would end up being more work to support some <link>-only features.

And it is somewhat nice for styling arbitrary documents, including XML, plain text, and media.

@yoavweiss
Copy link
Collaborator

@yoavweiss yoavweiss commented Jun 15, 2020

I thought the way this works in Firefox is that there is a shared processing model so it would end up being more work to support some <link>-only features.

That's not the case in neither Blink nor WebKit AFAIK. So supporting this would require someone explicitly devoting time to implement and ship the feature.

And it is somewhat nice for styling arbitrary documents, including XML, plain text, and media.

Yeah, that doesn't sound to me like a strong motivator for someone to implement.

@annevk
Copy link
Member

@annevk annevk commented Jun 15, 2020

Sure, and you'll have that cost each time you add something new to Link / <link>. I think it's worth considering what we want the long term architecture for these features to be. Case-by-case decisions doesn't seem great for web developers.

@nilfalse
Copy link

@nilfalse nilfalse commented Jun 15, 2020

One important use case for applying the Link: header to HTML documents had been described in the following blog post:
https://meyerweb.com/eric/thoughts/2009/01/22/using-http-headers-to-serve-styles/
FWIW, this is in fact how I first learned that <link /> HTML tag has an equivalent header.

IMHO, this is a niche feature which would be used mostly by developers and for developers, but it's an important one.

@domfarolino
Copy link
Member Author

@domfarolino domfarolino commented Jun 15, 2020

@yoavweiss Do you know how hard it would be to implement this in Blink? Should we maybe just do it? It might not be a huge priority, but there might not be a huge reason not to do it. I'm not sure.

@j9t
Copy link
Contributor

@j9t j9t commented Jun 15, 2020

It’s amazing to make websites simpler and more maintainable

Could you please elaborate on how this feature would do that? What would it enable you to do that is not possible today?

An actual strong use-case that this feature would enable would be a good start.

I think Link’s unique strength is that it does away with markup for styling purposes. Every other approach requires special markup.

The main benefit seems to be ease of maintenance of CSS references. To an extent, that easier maintenance is even automatically enforced (because several types of such updates would need to happen by changing the Link header).

Its main use case, in my eyes, are large collections of documents, meaning large content sites.

Now, these points can certainly be attacked (HTML payload decreases but HTTP header payload increases, or a single style sheet ref in a single server config being no improvement to a single style sheet ref in a single site template). Still, overall Link does come with unique advantages that would be great to be available for use in practice.

—A frank side note: I’m biased because a huge fan of this option. I love HTML code like the one in https://hell.meiert.org/temp/link/ (just some fooling around—obviously, use Firefox for styling), where all code except for the doctype relates to structure, as pure as one might wish HTML to be. However, I also realize how our field has changed a lot, so that I wouldn’t bet on broad adoption even when there was broad support. Still—for HTML optimization, in my mind, it’s a fantastic feature, and I keep seeing use cases for it.

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

Successfully merging a pull request may close this issue.

None yet
7 participants