4 ms·
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 f
by Kalabasa 3y ago
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.
- niutech 3y agoThere is a new request header: `Sec-Fetch-Dest: iframe`
- Kalabasa 3y agoWow, thanks! That header's so new. Just months ago. I just added an example using Sec-Fetch-Dest https://github.com/Kalabasa/htmz/commit/6ad3a76be3ee755bb5e777348ce526a704f07050#diff-36239d93e83b88f4c8135ccf21fb7e6c80481f883470d554069ec338e5b2d796 https://github.com/Kalabasa/htmz/commit/6ad3a76be3ee755bb5e7...
- naasking 3y agoYou 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.
- simpaticoder 3y ago> 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.
- niutech 3y agoThere is a new request header: `Sec-Fetch-Dest: iframe`
- sesm 3y agoCan we add a cookie instead of modifying URLs?
- simpaticoder 3y agoNo. The same cookies are added to both the host and guest pages.
- nymanjon 3y agoI would think you could add a cookie with JS. Then you know JS is being used. So, that does seem viable.