There is nothing worse than believing something that isn't true. Imagine trouble-shooting a front-end issue, and not knowing about this. You think you know where all the CSS is coming from, and that it couldn't possibly produce the effect you're seeing. But actually you do not know where all the CSS is coming from. Adding subresources via http header is pure evil.

Seems like there’s a multitude of similar situations to deal with with modern front development. This would hardly be more “evil” than anything else.

Well, then I don't think I respect your opinion. It's true that tab state is, in general, a function over a truly vast array of variables, plus transitives. But there are some invariants that have been present in the browser from the beginning which constrain this diversity. This feature removes a foundational invariant, namely that the content (and style) of a page depends on the content of a resource. This is a profound mistake that is not in the same league as, for example, a misconfigured webpack. It is more akin to an intrusive, badly written browser extension that injects random crap into a page, but this is far worse because of its novelty, and because of its (potential) scale.

This feature needs to die.

The fact of the matter is that what-a-resource-is includes the headers it is served with and the context in which it is requested. Consider https://lcamtuf.coredump.cx/squirrel/

It may not be normal in your day-to-day work, but it's definitely an important point of extensibility. Extensibility is indeed opposed to management (see _The Principle of Least Power_ for more on that front) but that is a trade off that worked really well for the web for decades. I for one would be really sad to see this further limited and would love for browser support for `Link` header behavior to increase rather than decrease.

By that reasoning content-length should include headers. Needless to say you have not changed my mind. There's never going to be a hard and fast rule distinguishing headers from content. It's all just data after all. That doesn't mean it's a good idea to eliminate the distinction entirely.

It's almost as if software engineers are doomed to this pendulum of constraining and then under constraining. It happened with SQL and noSQL and it seems to be happening now with HTTP. Constraints are for your own benefit but maybe it takes time to really grok that.

At a cursory search, Link appears in 1996. It was there before CSS.

https://www.rfc-editor.org/rfc/rfc1945#appendix-D.2.6

Wow, you're right! Good that it was summarily ignored until now I guess.

I fear we’re getting into xkcd 386 but…

As svieira says above, Link is a standard thing. It’s widely used. CSS is even based on it. Another example is ‘canonical’.

https://http.dev/link#canonical

You may not have encountered it personally, but I don’t think it’s wise to extrapolate from that.

I've been making websites since 1996 and I've never seen it. Not once.

No, content and the resource are two different things. The resource is the content and its metadata. Content length is what it says.

So would you also want the Content-Type header to die?

That is a very strange question. Why would you ask it? Content-Type is the canonically proper use of an http header field, as it is metadata about the content, rather than content itself.

One could argue that for some content, how to style it is just a suggestion anyway. Ie you could think of “our style guide for text content can be found at this address” as metadata for semantic HTML documents

That breaks down when you try to think like a content creator, nowadays everyone talks about UX, I'd say the styling has at least equal weight in terms of communicating ideas. (net negative if the document is shown without it applied, really pissed artists etc)