Link header processing not defined

[domfarolino]

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]

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]

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]

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]

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]

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:

• Figure out what Link header rels are supported by different browsers, and assemble a list of all that are supported in 2+ browsers.
• Add a column to the table at https://html.spec.whatwg.org/multipage/links.html#body-ok, and supporting normative text in each rel, saying whether a given rel is supported as a header
  • As part of this, when we explicitly do not say that styleshet is supported as a header, we'd remove the CSSOM text and any other discussion in HTML.
• Figure out some way of abstracting the processing model in https://html.spec.whatwg.org/multipage/semantics.html#fetching-and-processing-a-resource-from-a-link-element (and its overrides in rel-specific sections) to work with the header, not just the element. Presumably this would supplant the current contents of https://html.spec.whatwg.org/multipage/semantics.html#processing-link-headers.

[awwright]

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]

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

[awwright]

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

[domfarolino]

Says who?

[awwright]

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

[yoavweiss]

@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]

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]

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]

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]

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]

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.

[yaroslav-ilin]

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]

@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]

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.

[goodevilgenius]

The only use-case I heard so far is application of styles to image documents.

It actually applies to most non-HTML documents renderable by the browser: images, video, audio, plain text, PDFs. All of these could be styled through CSS within the browser using a Link header.

If I link to an MP4, it will play in the browser inside an implied <video> tag, which can be styled, e.g.

[noamr]

I suggest to start with spec'ing the currently implemented common denominator - preload links that get loaded in two phases - when the document is initialized if they're not viewport dependant, after the first chunk if they are.
I can work on a PR for this.

Once this is in place, we can incrementally and optionally add more things:

• Link headers in subresources
• Link headers in workers
• preconnect (which is not yet 100% spec'ed)
• prefetch (requires spec'ing prefetch first regardless of header)
• early hints
• Consider additional link types, such as stylesheet as per this issue, given additional implementor interest.

[domenic]

@noamr, do you think there's anything left for this? Maybe only things that are tracked in other issues?

We could spin off a separate "implementer interest needed" issue for tracking rel=stylesheet support, in particular.

[noamr]

@noamr, do you think there's anything left for this? Maybe only things that are tracked in other issues?

We could spin off a separate "implementer interest needed" issue for tracking rel=stylesheet support, in particular.

Yes sounds good
Also we have other open PRs for subresource link headers (which I'm still not sure is a good feature...)