wip: Container and Element documentation brain-dump

Containers.md

@@ -0,0 +1,8 @@
+# [TODO] Containers
+
+Decorations should respect the layout and the viewport accordingly. This means
+that scrollbars are always visible (except there is no need to have a scrollbar)
+irrelevant depending on the size of the content. The rectangle apply to all
+cells of the content (and may be overwritten by child elements contents).
+The border of an element should be around independent of the scrolling of the
+contents, just like padding.

Elements.md

@@ -8,6 +8,39 @@ library should instead provide small examples to show how you can implement
 such user fields yourself and connect them using your own event system loops to
 communicate with other `Container`s and/or `Element`s.
 
+### User specific event handling and content rendering
+
+For interactions controlled by the user each container can use an `Element`
+interface which contains functions which are called by the `Container`
+during event handling (i.e. `fn handle(..)`) and during rendering (i.e. `fn
+content(..)`) to provide user specific content and user interaction. The
+`Element` may be stateful, but may also be stateless and then be re-used in
+multiple different `Container`s.
+
+Composing multiple `Element`s currently requires the implementation of a wrapper
+which contains the `Element`s that need to be handled (should work pretty well
+for stateless `Element`s). Such *stateless* `Element`s may be provided by this
+library.
+
 ### Scrollable
 
+Contents that is scrollable should be done *virtually* through the contents of
+the `Container`. This means each container contents implements scrolling for
+itself if required.
+
+This still has one issue: Layout of child elements that are already too large
+(i.e. or become too small). The library could provide automatic rendering of a
+scrollbar given the right parameters however. The scrolling input action would
+then also be implemented by the user.
+
+Open questions are regarding the sizing options (i.e. how is the size of a
+`Container` actually controlled?, how should it be controlled?, etc.). There
+should be support for the child elements to provide some kind of 'list'
+functionality built-in.
+
+**REMINDER**: (mostly for myself) The library should be and remain simple. This
+means that some code for using the library may be duplicated, but this is not
+the main goal. Others may provide more re-usable code snippets that build on top
+of this library instead.
+
 ### Advanced usage