You're off about canvases, unfortunately... they're so much more basic that you're currently thinking.
(Though there is something else that you an look inside... I'll come back to that)
A Canvas doesn't really store any data except for the image that is currently displayed on it.
But canvases are very flexible and convenient as the display component of anything interactive or animated that uses images.
This might be a weird metaphor but if we were trying to play a film in Decker.... a canvas is like a projection screen.
It's not the projector (that's probably the script, wherever it lives) or the film (your stored images).
---
Okay! So! In Phinxel's Field Notes almost all of the extra images are stored in separate canvases on a card named 'storage'.
This card can't be navigated to while flipping through the book in interact mode because I prevented that... but you can find it by arrow key navigating around in widget mode or by opening up [ File > Cards ] to see the full list of cards and navigate to it that way("storage" is near the very bottom of the list) if you want to see all the stuff in there.
Inside of the script for the cookie slider example you mentioned there's a snippet that looks like this:
plate.paste[ storage.widgets[x].copy[] ]
What this does is copy an image from a canvas on my storage card onto the canvas on the same card that we're on now... the relevant canvas on this slider example card is named 'plate'.
storage.widgets[] is telling Decker to look at the widgets on my "storage" card and 'x' is a temporary variable combining the naming pattern I used for my stored canvases and the current number that the slider is set to. Don't worry about that part... I think I was trying to make my own example a little more compact.
If I was going to rewrite it to copy from a single specific named canvas it might look like this:
plate.paste[ storage.widgets["cookie3"].copy[] ]
# or, alternatively #
plate.paste[ storage.widgets.cookie3.copy[] ]
# or if I was copying from a canvas on the same card as the one I'm pasting on...#
plate.paste[ cookie3.copy[] ]
So... we have to store our extra image data somewhere else that isn't just on the 'projector screen' and there's a few options:
Canvases
Storing images in other canvases is totally fine! Depending on how many images you're storing it might not be ideal but it works. Canvases are built for displaying images and they have easy to use .copy[] and .paste[] functions to move those images around.
Fields
When you make a new field it'll be set to "rich text" by default, which is exactly what we need for it to be able to store images. If we put some images into a field we can use the .images attribute to refer to them in scripts.
You can see some examples of this on one of the pages about Fields in Phinxel's Field Notes (here's a direct link to the page) but it probably warrants more discussion here on the forums because it's very handy! This is a particularly good method for storing lots of animation frames in one place.
Other Places ....
Images can be stored in grid widgets as text (image data correctly stored this way would begin with %%IMG) or maybe also as pasted images if the grid column format is set to support rich text (this is not the default for grids).
(I've never really used grids for storing images for animations, honestly. I just know that it should technically be possible....)
You can also store images directly on a card and refer to the card.image or even use a widget as a marker for a smaller area on the card that you'd like to use. Someone can probably explain more about this if it sounds appealing.
But I personally tend to use canvases and fields for most things.
---
The other thing I wanted to mention is Contraptions, which do actually have an "Inside". Contraptions are custom widgets made of the 5 basic types of widgets + scripts (see the contraption bazaar thread to tour some of the community contributed contraptions).
Going back to the idea of a projector... a contraption could be made of a canvas to play your sequence of images and a field to store the full collection of frames. And you'd definitely also need a script to tell the widgets how to relate to each other.
This could absolutely just be built directly on a card (or split across a display card and a storage card...) without getting contraptions involved but sometimes it's handy to package these combinations of widgets together. And this is the concept that exists in Decker where a widget does actually have a secret "inside" area so I wanted to mention it. :) It's a much bigger topic though so I'll stop here.
Hopefully this made a little sense.