The idea of skin is that each visual component is a cell. that cell manages it's internal state - what data it has, how that data is present, and how it should be rendered when changes are accepted, and when the cell itself should be destroyed.

this means that a UI is a giant cell hierarchy. each cell knows it's parent and it's children, but that's it. A lot of messages will filter up and down between them to make things work.

DOM elements do not map individually to cells. A cell can be a single dom element, or it could be a complex structure of tags. That will be up to the internal implementation.

There will be two ways to build skin cells. One is to use a default with a template to build the cell. The second will be to override the rendering with a custom renderer. This should make it easy to get started, but allow for a lot of flexibility when needed.

There should be a lookup of common templates, but also a way to pass the template.

SIGNALS

skin.create
    o: parent_pk
        The PK of the parent cell. This will be used in plumbing to identify what cell it should be a child of. If not defined, it will be the first skin cell.
    o: pk
        The name of the cell, if you want to name it. The cell will auto-name it if one is not provided.
    o: dom_pk
        If there is no parent_pk, the dom_pk must be passed. This is the dom element the skin cell will attach to. *body is a special PK for the HTML body.

AUTO-PK

Start with the parent's PK.
Keep track of the current index.
If the last character of the parent is a number, the next character will be a letter. Vice versa. When letters become greater than Z, it will roll over to two letters, starting with A.
Deep, undefined PKs could look something like
example_parent5d12ag
    example_parent
        5
            d
                12
                    ag