TODO

disposalMethod/bgcolor
Canvas center text.
Dynamic CSS (what about :hover?)

Make text fit in canvas (if text should even be painted in the canvas).

Center toolbar?

Figure out letterSpacing mess!

Figure out float mess! Disabled for now.


Keyboard shortcuts?
  Currently uses focus-on-button.

What if:
  An img is styled?
    Can be either through CSS img {}, CSS #id {}, CSS .class {}, or .style = ''
    (Even if we can't carry over everything, we should *at least* carry over the position.)
  And image is resized from its original size?
    (A sub-case of the case above, but an important one.)
  A gif is a link, or has properties like onclick (or even other properties))?
    (Should the canvas, too? Should click-to-play/pause on the canvas even be supported?)
    OK, added a .preventDefault() click handler to the div, which stops clicks from going to the website. But text is still blue and underlined; this should be fixed somehow.
  There's a noticeable delay (e.g. light.gif), and play is clicked?
    Do we want to move on to the next frame immediately, or after the delay?

Penguin


Nicer way to Math.ceil(x / 8)?


setTimeout(f, 0) -- is there a nicer name for that? Or at least can we safely say setTimeout(f)?


Maybe all the functions (playGIF etc.) should be all OO-ish.


Investigate textContent/innerHTML/innerText/escapeHTML/etc. business


Maybe show "Rendering... Frame x/y"?
  This would involve (because this is so slow) parsing all the blocks, then
  decompressing (and deinterlacing -- and these could both have their own
  progress bar (as in "Decompressing frame x/y... Byte a/b" or "Deinterlacing
  frame x/y... Row a/b", etc.) them, then rendering them, each step on its own.


Note: With some images (e.g. spin.gif in Firefox), using putImageData() for each frame is too slow.


Is there any reason to be W3C-compliant and put the <input> in a <form>?


If we could actually fiddle with CSS *classes* dynamically (which I think is
possible, actually), we could get rid of the whole .visibility = 'hidden'
business neatly.

Add some more things to the toolbar to make it symmetrical.

Maybe i should be 1-indexed to be consistent with curFrame etc.?


If you have a canvas, it goes above (z) a toolbar of a jsgif above (y) it. Not good.


Make curFrame etc. the right width rather than hard-coding it.
  (Make the non-editable ones non-inputs, preferably, if there's a way to make
  the toolbar stay the same size. Maybe even make curFrame be regular text
  while not paused?)

Look up CSS letterSpacing solutions; there has to be a better one.

Naming troubles: Many
  delayInfo inconsistent with showInfo


Handle LCT/GCT etc. properly


Possibility: Allow prev/next even while the animation is playing (good when there are long delays). Why not?



Perhaps increase the z-index of a :hover toolbar? (If you have multiple toolbars which are pinned, you always want the :hover one on top.)
  In general, figure out the z-order thing.

It might be *much* more memory-efficient to store the frames as PNGs or something instead of uncompressed imageData objects.

computedStyle

XXX:
 tef.gif is an invalid animated GIF, because it doesn't have a GCE block preceding each frame (well, one isn't actually necessary for the first frame).
  All it describes is one big frame, with many image blocks that overwrite each other.
 Browsers tend to display it as an animated GIF, rather than one frame, but that's just because they're compensating for broken behavior.
   Should I compensate for this broken behavior too? I *suspect* it wouldn't be a good default.

Handle exceptions everywhere properly.

Oh, just realized that there's a bug with transparent frames and the translucent progress bar.