Just a total brain bomb here, but I thought I'd kick it around to see
if I can get some feedback -
Basically, I have a proposition to extend the HTTP spec that could
make partial page updates work better with URL modification. However,
before I talk about my proposition, let me first try to explain the
problem. Currently, if we want to do partial page updates, it seems
easy enough to do: just open up an AJAX request and swap in the
partial content. However, if we want to change the URL cleanly, it
seems like our options are limited to using the new HTML5 pushState
functionality or one of the many "hash bang" hacks in the URL. For all
intensive purposes, libraries and polyfills have abstracted this
problem to the point where its not so much of a problem but more of an
annoyance (extra stuff to be downloaded to ensure graceful
degradation). In the end, the solution for a clean partial update in
the URL and the DOM seems to live in the browser.
My suggestion is to move this solution to the server, where adoption
isn't as hard to force. Essentially, extending the HTTP language to
include a new verb (say PARTIAL) would be pretty sweet. In this
hypothetical scenario, the same HTTP requests to the server can result
in full or partial content being returned. Now I know what you are
thinking, "I can totally do this without messing around with HTTP",
but now let's consider the scenario where the browser adopts this.
In the scenario where browsers start to adopt "partial" requests, you
can imagine a handshake similar to how CORS works. For instance:
- Browser sends HTTP GET / to
example.com
- After loading the markup for
example.com, the user clicks on an
anchor tag formatted like such
- <a href="/subpage.html' target="#content">Sub Page</a>
- The browser looks for a frame with that ID and cannot find it
- Typical browsers will just open up a new tab at this point, but
let's assume that this browser implements partial HTTP and now it goes
down a path similar to CORS
- The browser sends an HTTP OPTIONS request to /subpage.html asking if
the server supports partial HTTP requests for #content. for instance,
it could send headers:
- Partial-Content-Selector: #content
- If supported the server could respond with affirmative header
validation for that element, or all elements. For example:
- Partial-Content-Set: #content, .footer, .navigation
- Now the browser can make an HTTP PARTIAL request to /subpage.html
and insert it's response into the DOM under the correct selector.
- For completeness, I suppose the browser could even fire off an event
indicating that the DOM has changed, so that behavioral code may be
applied to the new content.
- Finally the browser changes the URL to /subpage.html, all without
any JavaScript magic to coerce the URL!
This seems obvious to me, and I wouldn't be surprised if there is
something similar in the works that I may have glossed over. I
especially like it because it makes modern web apps a bit cleaner, and
gracefully degrades to regular navigation for older browsers. It also
aligns developers with developing sites in an accessible way, lending
their sites to better indexing and so forth. Anyway, I'm interested to
see if this makes sense to anyone else, and if there is anything else
I can do to help.
- Jon