Support alternate layout systems

[h2oai]

Support alternate layout systems

[mturoci]

I suggest trying out CSS grid as an alternate layout system. This would allow developers to have a fine grained control on the CSS level. E.g. ability to specify mixed units - fr - relative to viewport and px - fixed size as opposed to current state where card width is fixed only. We could also take advantage of grid-template-areas:

grid-template-columns: 200px 1fr 1fr;
grid-template-rows: 80px 1fr 1fr 100px;
grid-template-areas:
    "header header header"
    "sidebar content-1 content-1"
    "sidebar content-2 content-3"
    "footer footer footer";

This API could be more intuitive for non-pure web devs.

I am not sure if this will not affect the the mouse handling in viz mentioned above.

[lo5]

Agree, grids are one possible solution (assuming they behave identically across major browsers).

One way to state the overarching goal is:
"Make my app look professional and slick out of the box, without making me do a ton of upfront work."

This implies:

1. Allow authors to choose between multiple layouts that best fit their use case, say:
   1. Pixel-perfect grid (what we have today).
   2. 2-column layout with a header/footer that automatically transforms into a 1-column layout when space-constrained (fig. 1).
   3. 2-column layout with automatic header/footer/menu/navigation. For example, we have a mechanism today for laying out content (fig. 2), but we need to allow authors to enable the surrounding chrome (fig. 3).
2. Preserve the conciseness of the current API.
   1. Introduce a new layout attribute on the meta_card that lets users specify which layout to use. e.g. layout='GridLayout(foo=..., bar=...)'.
   2. The box= string argument on each card continues to be the primary mechanism for specifying "how and where this card is laid out". Today, the box string is parsed into 4 numbers that indicated a left top width height tuple. Instead, we need to interpret the box argument based on the meta_card.layout attribute.

Fig. 1

Fig. 2

Fig. 3

[lo5]

Related to #38

[lo5]

Closed via #58