You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's call a visualization (whether chart, plot, layout, etc) a picture. Currently pictures have a size based on the Vega/Vega-Lite height and width attributes of the outer view. This means that the total window area taken up by a picture is determined by this size. This also influences where and how much more area is taken up by any surrounding picture frame elements (top, bottom, left, right). Even with very large screen real estate this can easily overflow in large renderings. Overview+Detail charts are one way of trying to control this. But they do not work in all cases - for example, tree and network layouts. Or faceted charts involving a large number of data 'points' (hundreds to thousands). But making the picture size 'small' can render (so to speak) the graphic useless (unable to resolve individual cases or things start overwriting themselves, etc).
Putting the picture in a scroll area (scroller component), would enable choosing a limited amount of window area to be allocated, while keeping the picture itself at the optimal (or at least good) resolution. This is not always needed and in many cases would be a nuisance, so the ability should be optional.
The basic idea would be to add a special :scroller element to picture frames (currently they have the :top, :bottom, :left, and :right elements), which, if provided, would define the window area limits:
Where all of these are optional, but if none are given the whole point of the scroller is lost. Generally the :max-width and :max-height would be all you would ever provide. "CSS size style" would most typically be a "xxxxpx" size, for example "1000px", but could be others.
One thing to keep in mind with these sizes is that Hanami uses re-com and is all in on Flex styling! So, scrollers will have flex behaviors.
The text was updated successfully, but these errors were encountered:
jsa-aerial
changed the title
Support optional scoller containers for visualizations
Support optional scroller containers for visualizations
Jan 10, 2019
Let's call a visualization (whether chart, plot, layout, etc) a picture. Currently pictures have a size based on the Vega/Vega-Lite
height
andwidth
attributes of the outer view. This means that the total window area taken up by a picture is determined by this size. This also influences where and how much more area is taken up by any surrounding picture frame elements (top, bottom, left, right). Even with very large screen real estate this can easily overflow in large renderings. Overview+Detail charts are one way of trying to control this. But they do not work in all cases - for example, tree and network layouts. Or faceted charts involving a large number of data 'points' (hundreds to thousands). But making the picture size 'small' can render (so to speak) the graphic useless (unable to resolve individual cases or things start overwriting themselves, etc).Putting the picture in a scroll area (scroller component), would enable choosing a limited amount of window area to be allocated, while keeping the picture itself at the optimal (or at least good) resolution. This is not always needed and in many cases would be a nuisance, so the ability should be optional.
The basic idea would be to add a special
:scroller
element to picture frames (currently they have the:top
,:bottom
,:left
, and:right
elements), which, if provided, would define the window area limits:Where all of these are optional, but if none are given the whole point of the scroller is lost. Generally the
:max-width
and:max-height
would be all you would ever provide. "CSS size style" would most typically be a "xxxxpx" size, for example "1000px", but could be others.One thing to keep in mind with these sizes is that Hanami uses re-com and is all in on Flex styling! So, scrollers will have flex behaviors.
The text was updated successfully, but these errors were encountered: