Affects Version/s: None
Fix Version/s: 0.9.6
:: "Columnizer" framework: Helps in building multi-block pages w/ parallel columns and various proportions
:: "Form" framework: Helps in building arbitrary <form> compositions w/ all kinds of input fields, comments and nested fieldsets
While the columnizer only works inside div#main for now (actually acting as the first DOM child layer in there), the form framework works in any kind of container, even dropdown controllers.
For the columnizer framework, here are the building blocks:
:: The div#main needs the class "columnized".
:: Depending on what number of columns you want and in which proportions, you add another class to div#main.
Currently, I support these schemes:
The first number sets the number of columns, the suffix tries to explain their proportions.
Please note that I can extend the number of supported schemes very, very easily and quickly! I can make them generally available or derive specialized scheme only available to sections or subsections.
:: To denote columns inside div#main, you use basically <section class="view-column"> as containers.
These containers need to follow onto each other w/o anything in between.
Currently, no other HTML elements may follow onto section.view-column. Before them it's not a problem (e.g. for aside.controller or aside.toolbar).
Each section.view-column must have a class denoting its order, like "col-1", "col-2" and so forth. I would also recommend to add classes categorizing a column's content type (like I did in my demo for the Project data page).
You may put anything inside a section.view-column. I haven't considered what to do if the content is too wide, maybe I'll add a overflow: hidden to inhibit flow-breaking.
:: Column headlines:
I would recommend to use <h4> wrapped headlines for each column, maybe even w/ our beloved <mark> double scheme.
In some cases, we can use them to help the user and give them appropriate styling. In other cases we can simply hide them by CSS (or bring them up again when we're changing s.th.).
Specifically for the Project Data page, I developed dedicated structures to enhance it. Please check the demo page to see details.
The first column should contain a list of filters, applying to the tree or graph. Each filter is contained in an <li>. If the filter is currently used, just add a class "active" to it.
I'd recommend to set up on/off filters as simple links instead of a <select> element. You can still choose whether to allow for multiple filters at once or not. You can also use a free-text filter like I set it up in the demo page.
The middle column should contain the tree/graph viewer, consisting of a tabswitcher, an "toolbar-inline" for view settings and a div.specialviewer for the actual view.
I would like to use the class "specialviewer" in long-term to denote wrappers for any 3rd-party-view like JS-driven, WebGL, Java etc.
The last column contains a node editor, here already using my form framework.
Usually, if we have a big and only one form on a page, the central toolbar contains the form's controls. But here in the Project Data page, we have to divide the controls as they either may affect the selected node only and the whole project.
If still figuring out which action buttons to place where in this special case as there are so many of them.