rem: Scroll from Propierties of Container

Updated the corresponding documentation and ideas for how to realize
scrollable contents.

README.md

@@ -73,16 +73,12 @@ the primary use-case for myself to create this library in the first place.
 ## Roadmap
 
 - [ ] Container rendering
-  - [ ] Layout
+  - [x] Layout
     - [x] direction
       - [x] vertical
       - [x] horizontal
     - [x] padding
     - [x] gap
-    - [x] alignment (removed - for now at least)
-      - center
-      - left
-      - right
     - [x] sizing (removed - for now at least)
       - width
       - height
@@ -96,10 +92,23 @@ the primary use-case for myself to create this library in the first place.
     - [x] corners
     - [x] separators
   - [x] Rectangle
-  - [ ] Scroll
-    - [ ] vertical
-    - [ ] horizontal
-    - [ ] scroll bar(s)
+  - [ ] User control
+    - [x] event handling
+    - [x] user content
+    - [ ] Default `Element` implementations
+      - [ ] Scrollable
+        - [ ] user input handling
+          - [ ] vertical
+          - [ ] horizontal
+        - [ ] scroll bar(s) rendering
+          - [ ] vertical
+          - [ ] horizontal
+      - [ ] Content alignment (i.e. standard calculations done with the provided `Size`)
+      - [ ] Text display
+      - [ ] User input
+        - [ ] single line
+        - [ ] multi line
+      - [ ] min size? (I don't have access to the `.resize` `Event`..)
 
 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)
@@ -119,6 +128,30 @@ This still has one issue: Layout of child elements that are already too large
 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.
+
+### 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.
+
 ### Input
 
 How is the user input handled in the containers? Should there be active