We don't need to encodeURIComponent at all when using blob links.
The data never goes into the dom directly, just a guid reference.
This makes saving with blobs very fast!
This should fix crashing on large wikis under chrome
see chrome bug: https://code.google.com/p/chromium/issues/detail?id=103234
This should also speed up generating the download html by a couple of seconds
it avoids repeatedly marshalling the base64 encoded href string across the sandbox boundary
it avoids some time and memory consumed by "large" dom manipulation
major remaining delay is in encodeURIComponent
TODO: consider using iconv on the server
TODO: consider async invocation of regular expressions to avoid client "lockup"
Conflicts:
core/modules/savers/download.js
The problem is that insertBefore() on Win7/IE10 crashes if the second
parameter is undefined, rather than behaving as if the parameter is
missing, as all other browsers do. Aaargh.
Belatedly realised that the design would be clearer without these two
separate concepts being conflated into a single widget.
As a result of this change, any other widget or template that generates
transclude widgets has needed adjustment.
Usually the list transcludes each tiddler through the sample template.
This hack makes it work differently, where each tiddler is used as a
template to render the same current tiddler. The attribute that
switches modes is called "hackTemplate" because this is a temporary
implementation of this capability for experimental purposes
This makes it possible to generate UL or OL lists as well as the
current divs and spans.
This feature is clearly necessary but I'm not very happy with it. It
feels as though the syntax should be modifying a UL tag to specify the
extra information required to generate the list, rather than turning
the list widget to indirectly specify it's elements.
It displays internal configuration information for debugging and
learning about TiddlyWiki. Also introduces a way of interleaving
documentation tiddlers (complete for tiddler fields, more module type
docs to come)
Changes to the main layout CSS a few weeks ago meant that the drag
image element was visible at the top left corner of the window.
Astoundingly, the fix is to cover it with another div with the same
background colour as the page….
