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