If you want the whole UI around rendering the content, sure, but you don't need that – it's just an iframe that sets a `data:` URI anyway. The link can just as well be the data URI itself. It'd be a very long link for any non trivial content, but it works just fine without any connectivity.
Seeing as tickets are typically sent in HTML emails anyway the scary looking URI can just be hidden behind a nice anchor tag or something anyway. When the recipient clicks the link, the page will open in a browser and render just fine without any connectivity. Graphics can be embedded in the same way, using `data:` URIs as image tag sources, or in embedded css.
Here's an example, turn off your connection and try this in your browser's address bar:
Unfortunately that comes with a bootstrapping problem: what if the first time you hit the link is when you aren't connected? If everything is embedded in the data URI and the link is in fact the data itself then it doesn't matter.
I think that's an acceptable requirement. After all, you wouldn't expect an app to work without downloading it. If instead of using lzma, gzip were used, I bet you'd be able to include some code that would unzip itself using the browser's unzip capability. I am not sure how much code that would take though.
Right, for an app that makes sense but the use case I mentioned was really just pure data. A ticket is rarely more than a qr code or some other identifier, whose veracity is then checked t the point of reading. In an arena full of people it’s not uncommon for cell towers to get overloaded, or you may be roaming if overseas and don’t want to waste data, or you’re on a moving train with no on board WiFi or if it has one it might not work right. In those cases (and it seems to happen to me a lot) I would’ve preferred that the ticket I received in my email was viewable offline, even if I’d never seen it before. With a data URI, that’s possible. It’s not an entirely contrived use case I don’t think.
Could you not register a URI format with the mobile OS to open an IttyBitty reader app that contains the rendering scripts?
Sure, initially that means only users who've noticed it would be able to benefit, but the app would be generic, not vendor-specific, so over time, it could become a standard & make it into the OS, at which point it becomes properly useful.
Edit: (sorry, I appear to have been rate-limited)
In reply to @mstated below:
---
Only really that itty bitty's compressed in the URL, not in the transport (& could be extended to add encryption).
It's absolutely true that, that may be tackling the wrong area - if data: were extended with compression/encryption options (not that itty bitty has encryption, but it's an option with the JS layer there) then the itty bitty decoder has nothing to do.
BUT, experiments like itty bitty might spur on ideas & standards changes for things like data: which to me makes it worthwhile.
(Self-contained, standardised, compressed [, encryptable?] content objects [in this case URL] renderable via ubiquitous web technologies feels like a win, itty bitty or not)
---
Also, if links are shared on html-based platforms, some block data: url's in links. Not sure of the justification, but reddit doesn't seem to render markdown formatted URLs with data: on them, as links. Not sure how to tackle that one - itty bitty sidesteps the restriction.
Why? The `data:` schema is already there and is well supported across platforms. All itty bitty does is take the base64 encoded fragment part of the URL and put it in an iframe, wrapping it in the `data:` scheme. No need to register anything new.
Only really that itty bitty's compressed in the URL, not in the transport (& could be extended to add encryption).
It's absolutely true that, that may be tackling the wrong area - if data: were extended with compression/encryption options (not that itty bitty has encryption, but it's an option with the JS layer there) then the itty bitty decoder has nothing to do.
BUT, experiments like itty bitty might spur on ideas & standards changes for things like data: which to me makes it worthwhile.
(Self-contained, standardised, compressed [, encryptable?] content objects [in this case URL] renderable via ubiquitous web technologies feels like a win, itty bitty or not)
---
Also, if links are shared on html-based platforms, some block data: url's in links. Not sure of the justification, but reddit doesn't seem to render markdown formatted URLs with data: on them, as links. Not sure how to tackle that one - itty bitty sidesteps the restriction.
