Skip to content

Instantly share code, notes, and snippets.

@darobin

darobin/index.html

Last active December 12, 2015 07:48
Show Gist options
  • Star 8 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save darobin/4739457 to your computer and use it in GitHub Desktop.
Save darobin/4739457 to your computer and use it in GitHub Desktop.
Download ZIP
Who needs srcset? Who needs <picture>? Not the AppCache people we don't!
Raw
index.html
<!DOCTYPE html>
<!--
- controllerpath should default to /*, it's just the typical thing
- controllersync ensures the controller is always there
-->
<html controller="respimg.js" controllerpath="/*" controllersync>
<!-- ... -->
<img src='my-shiny-donkey.png#resp-me'>
</html>
Raw
respimg.js
// this all assumes no resizes
// if you need resizes, you can handle it using postMessage and a resize handler
// implementation left as an exercise to the reader
this.onrequest = function (e) {
if (e.request.url.match(/#resp.me/)) {
var size = doSomeMagicToPickRightSize()
, url = e.request.url.replace(/#resp.me/, "").replace(/(\.\w+)$/, size + "$1")
;
// XXX this could possibly use a better API
var xhr = new XMLHttpRequest();
xhr.open("GET", url);
e.preventDefault();
e.respondWith(xhr);
}
};
@yoavweiss
Copy link

My first reaction was "WUT???".
I gave it some time to sink in and realized the underlying primitives (controller & onrequest) are a framework that will enable anybody to roll his own resource fetching polyfill.
That may mean custom responsive images solutions, custom responsive image format fetching mechanism, pipelining polyfills, custom SPDY-like protocols, etc.
Tthis can be revolutionary. Where do I sign up? :)

A few points I think needs addressing:

  • Possibility of inlined controller, to avoid SPOF, but have the controller working from the first request.
  • Possibility to add multiple controllers (for various file types or various paths)
  • When the controller is external, add some timeout beyond which simple request sending will take place

Personally, I'm not sure the above should replace a native responsive images solution. But it sure will make polyfilling the "next big thing" a whole lot easier.

@brucelawson
Copy link

nice. However, manually having to deal with resizes etc with postmessage etc will inevitably lead to libraryitis and cargo-cult code. I agree with Yoav: we still need a simple, declarative way to do this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment