4 ms·

Imagining CSS for URLs and HTTP Headers

31 points by 5amdotis 4y ago

xg15 4y ago
> 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.
TheRealPomax 4y ago
> 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?)
- theandrewbailey 4y ago
  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>.
- deathanatos 4y ago
  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.)
- justinator 4y ago
  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 http://example.com/article.html#second_header or whatever. Not the same concept, but it would be useful.
  - slondr 4y ago
    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/3 https://gitlab.com/gemini-specification/gemini-text/-/issues...
  - hayyyyydos 4y ago
    > 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>
- cryptonector 4y ago
  Also, letting the page see all of the response is a bad idea, security-wise.
zffr 4y ago
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
- jaywalk 4y ago
  The author specifically mentions static websites, which wouldn't have the functionality to alter the HTML.
  - anentropic 4y ago
    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
  - superkuh 4y ago
    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.
Phelinofist 4y ago
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?
- replygirl 4y ago
  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.
luckylion 4y ago
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.
ignitionmonkey 4y ago
The @document and other at-rules mentioned in the article are related to user styles. https://en.wikipedia.org/wiki/Stylish 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.
tanepiper 4y ago
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.
Minor49er 4y ago
This would be a little more complicated to test with local static HTML files versus the same files being hosted on a server

31 points by 5amdotis 4y ago

xg15 4y ago

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

TheRealPomax 4y ago

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

theandrewbailey 4y ago
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>.
deathanatos 4y ago
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.)
justinator 4y ago
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 http://example.com/article.html#second_header or whatever. Not the same concept, but it would be useful.
- slondr 4y ago
  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/3 https://gitlab.com/gemini-specification/gemini-text/-/issues...
- hayyyyydos 4y ago
  > 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>
cryptonector 4y ago
Also, letting the page see all of the response is a bad idea, security-wise.

zffr 4y ago

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

jaywalk 4y ago
The author specifically mentions static websites, which wouldn't have the functionality to alter the HTML.
- anentropic 4y ago
  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
- superkuh 4y ago
  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.

Phelinofist 4y ago

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?

replygirl 4y ago
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.

luckylion 4y ago

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.

ignitionmonkey 4y ago

The @document and other at-rules mentioned in the article are related to user styles. https://en.wikipedia.org/wiki/Stylish 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.

tanepiper 4y ago

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.

Minor49er 4y ago

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