Consider adding an HTTP header that indicates whether the response should be a fragment

[bparks]

In the first example, clicking the "Home" link updates the items visible in the browser

<a href="/home" target="main">Home</a>
<main> <!-- Existing page content --> </main>

But presumably in keeping with HTTP/HTML/REST/Hypertext, the URL should change?

If I then go to http://MY_DOMAIN/home, the server should probably default to responding with the whole HTML page.

But then how do I indicate that I should only receive a fragment in response?

Options include:

• Adding an HTTP header when the request is initiated from the link (e.g. X-Response-Type: fragment)
• (Client-side) extracting the contents of main from the response before injecting into the current page
• Some sort of other hackery (like sending a POST instead of a GET), but these start to feel extremely rough and clunky quickly.

My preference would be for adding an HTTP header, but maybe in a pinch (if some response header isn't present maybe) falling back to the client-side option.

[alexpetros]

Hey thanks for the feedback! I agree with you that there should probably be a header, but I also think it's non-critical.

In a hypermedia system, you, author of the webpage and owner of the server, control what the URLs return. I don't see much justification for re-using the same URL to provide both partial-page updates and full-page navigations. If /home is meant for full-page navigations, it should always be used that way. I should update the example on the README, actually, to a route that more clearly communicates a partial change.

(htmx, for example, has an hx-request header that people use for progressive enhancement: if it's present they'll send the partial page update, if it's not they'll send the full page. It's a fine way to do progressive enhancement, but I also think it's overkill. You usually should just send the full page.)

Triptych also doesn't (currently) have a way for targeted links to update the URL because I believe that if the link needs to update the URL, it should just be a (full-page) navigation. I can do deeper into it, but the gist is that, in my opinion, navigations and partial page updates serve different semantic purposes, and I don't think that HTML semantics should (or need to) blur them.

Relatedly, one of the reasons that I feel so strongly that forms need to natively support methods like PUT and DELETE is because I want to use them in navigations, which JavaScript cannot properly simulate.

All that having been said—partial page replacements should definitely send some new request and response headers (I think retargeting from the server is especially crucial). I'm more than open to suggestions about what those should be.