Imagining CSS for URLs and HTTP Headers | Hacker News Reader

Imagining CSS for URLs and HTTP Headers

blog.jim-nielsen.com

31 points5amdotis18 comments

> there can be information critical to styling a webpage that lives outside of the HTML alone

There... shouldn't be? I'm kind of missing the part that explains why you'd need this? Are there any concrete examples where "I need the headers and/or URL" lets you do something that you can't already do by making sure your document has the information it needs, in the document itself? (if you need URL-specific CSS, you just... load more CSS...? You template in the necessary <link> elements because your server knows which URL is being requested?)

Agreed. I don't understand why CSS should know the page's URL. Today, one can use a bit of JS to figure out the page's URL, and use it to add a class to <html> or <body>.

It seems like the "FART" problem is sort-of driving it, but the second URL contains a rough solution to it that doesn't require the (IMO crazy) idea in the main article.

I think the second linked article required an "edge function" to add the data- attribute to the HTML delivered to the client, and I think TFA's author doesn't like the need for that (i.e., wants to deliver a static document), but I think you could do it with some synchronous Javascript; the fallback for clients not wanting JS would be CSS media queries that just obeyed the UA's preferences… which seems like exactly what one should want…?

(So, I'm also missing a convincing "why", here.)

I'm kind of missing the part that explains why you'd need this?

I don't think it completely solves it, but it would be useful to be able to apply styling to a specific part of the page ie: highlight something so when you send it, it saves the receiver a little time searching for it.

Or in a similar vein, wouldn't it be cool to make any header an anchor? So I could say,

http://example.com/article.html#second_header

or whatever. Not the same concept, but it would be useful.

There's really nothing stopping a UA from doing this, and in bygone eras "document trees" used to be part of browser UIs.

Gemini clients still keep that dream alive, although there's plenty of disagreement as to exactly how it should function: https://gitlab.com/gemini-specification/gemini-text/-/issues...

> Or in a similar vein, wouldn't it be cool to make any header an anchor? So I could say,

You already can make any header an anchor, right?

eg: <h2 id="second_header">Second Header</h2>

Also, letting the page see all of the response is a bad idea, security-wise.

> How do we get the DOM? The browser knows how to create it from an HTTP request consisting of a URL, some headers, and some HTML.

I would already call this bit into question. At least originally, the "document" was only the HTML part. The task of HTTP was to shuffle the document around, not itself be part of the document.

In practice today, most documents have a HTTP request attached to it, but you can still see the issues if you try to load HTML from a file or from cache. What is the corresponding HTTP request for that?

I sort of can see the appeal of styling by URL, but that too seems in danger if opening a huge can of worms. Suddenly, you can't test styles locally anymore, because the domain name now influences the selectors. Also, if you move domains and forget to update your styles, suddenly your site will be broken.

> Setting aside the open-ended possibilities people might dream up with non-standard X- headers

What possibilities would that enable that couldn't also be done using data-* attributes?

> imagine being able declare some styles based on the presence of a cookie

Ok, that might be a useful idea after all.

You can simulate this today by having your webserver add HTML attributes for the HTTP headers, domain, path, etc to the body element. It should then be possible to write CSS selectors like the one in the article

The author specifically mentions static websites, which wouldn't have the functionality to alter the HTML.

if it's served via a CDN then it may be possible there, they often have facilities to transform the content based on headers etc

You can specify HTTP headers for a path/location in nginx in a static website and have it include arbitrary headers. Most standards respecting browsers (like Firefox) accept HTTP header specified CSS like,

    #/etc/nginx/sites-enabled/whatever.conf 
    location /this-isnt-for-you.html { 
        add_header Link "<//site.com/isntforyouheader.css>; REL=stylesheet";
    }

    $ curl -I http://site.com/this-isnt-for-you.html
    curl -I site.com
    HTTP/1.1 200 OK
    Server: nginx
    Date: Mon, 28 Nov 2022 18:08:01 GMT
    Content-Type: text/html
    Connection: keep-alive
    Link: <//site.com/isntforyouheader.css>; REL=stylesheet
    ...

This works to set CSS atributes only for a specific URL on my static websites using .html files. For nginx. But nginx is a very common and secure choice for static sites and available in everyone's repos. And you can probably add arbitrary headers per path with other static webservers configs too.

Maybe I'm missing something but the proposed @document rule just mimics using different .css files for different pages? For example: about.css and then include that in the HTML of the about page?

you can point multiple domains to the same document (e.g. i want to white label or personalize a document), or have the same document deployed to different services (e.g. i want to warn visitors that they are using a preview/test copy of that document). a lightweight ssr-friendly framework may have a low barrier to entry, but maybe i need or want to have the document in static storage to meet a legal constraint or to reduce cost, electricity input, maintenance overhead, or architectural complexity.

The @document and other at-rules mentioned in the article are related to user styles. https://en.wikipedia.org/wiki/Stylish was popular back in the days. As more and more websites moved towards generated CSS classes, it's become more difficult to maintain custom styles.

This would be a little more complicated to test with local static HTML files versus the same files being hosted on a server

Set-Cookie would only exist on the first requests where the server actually tells the client to set a cookie. On subsequent requests, the client would inform the server about the cookie (using the Cookie header), so this would have to match both requests and response headers.

We have this exact problem currently solved with a little hack that uses sessionStorage and media qieries, but it's an annoying.

In the end the best solution is probably move this to the edge with includes and edge functions, with a non-tracking cookie or header.

Reply on news.ycombinator.com