Uploaded image for project: 'stripes-components'
  1. stripes-components
  2. STCOM-130

In-pane grid system



    • New Feature
    • Status: Closed (View Workflow)
    • P2
    • Resolution: Cannot Reproduce
    • None
    • None
    • None


      Hi John,

      I finally have an, I think, coherent overall idea of how we might make the in-pane grid system work on various screen sizes, and behave consistently usable with customizable pane widths and fly-out pane logic:

      Rather than our components—and app developers' own components—using css media queries to turn e.g. a multi-col table into a cards list, or to change layout different, here is what I propose:

      Since our panes, when they are resizable (and before that, with the dev set width), will have a set Default Width, we might utilize this width to add a class called e.g. ".pane-width-is-500", rounding down to 100s, based on the pane's actual width (through javascript in runtime). We then have a percentage based grid that sizes columns based on a nested selector, rather than using media queries for it. We might make this more convenient with some PostCSS function, I don't know.

      This way, the code would not need to be read in runtime, the layout of items and components would not depend on the overall screen width when components are confined actually to part-width-panes, and it is a quite similar technique to styling for media queries (syntax wise).

      The only challenge I can see with this is that it does not follow along well with the notion of completely splitting up CSS code into components. We do have some global styles, but I don't know if this is problematic for one reason or another.

      JohnC ?

      CC rasmuswoelk, zburke, mike

      TestRail: Results


          Issue Links



                JohnC John Coburn
                filipjakobsen Filip Jakobsen
                0 Vote for this issue
                1 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases