Hacker News Reader

Comment by Kalabasa | Hacker News Reader

Yeah it breaks without JS. You could add the iframe behind JS, so the target would default to a new tab. But the server would still be designed to return HTML fragments. I never found a way for a server to check if the originating request is for an iframe or a new tab. It's not quite a graceful degradation.

View on HN

> I never found a way for a server to check if the originating request is for an iframe or a new tab.

There is no such technique. One way to distinguish is to pick a URL convention and modify the URL (before the hash) of the iframe URL. For example, add ?iframe=true to the URL, and then have the server check for that. Perhaps more usefully you could include information about the parent URL, e.g. url += '?parent=${document.referrer}'. Or something.

There is a new request header: `Sec-Fetch-Dest: iframe`

Can we add a cookie instead of modifying URLs?

No. The same cookies are added to both the host and guest pages.

I would think you could add a cookie with JS. Then you know JS is being used. So, that does seem viable.

You could intercept the clicks with JS and add a special header, like htmx does, to return fragments, otherwise fall back to full documents.

Edit: rather than a header, dynamically adding a query parameter to the URL of the element that was clicked would probably fit better with htmz's approach.

There is a new request header: `Sec-Fetch-Dest: iframe`

Wow, thanks! That header's so new. Just months ago.

I just added an example using Sec-Fetch-Dest

https://github.com/Kalabasa/htmz/commit/6ad3a76be3ee755bb5e7...

Reply on news.ycombinator.com