Skip to end of metadata
Go to start of metadata

Css Grid

We already have the css grid design in to help get started with some of basic layouts, but we need make sure that we have the device screen widths are defined and we are using bootstrap-responsiveness sizes.

There is something severely messed up with our css as it is importing bootstrap multiple times and overriding each other.  Also, it seems this is causing adverse affects with the grid system as it is not picking up the breakpoints correctly when using xs, sm, md, lg classes (I tested the same structures outside the kuali environment in local html to verify that what we are doing is somehow incorrect).  It may be related to import order and these multiple imports ( ? ).  I wonder if it is a problem with client-side less dev mode, as well.

The enhancements to css grid need to include changes to what classes we are putting on the divs by default based on number of columns, and the ability for full control of the classes on the divs for each screen size level (ultimately they will be concatenated as the class for the div cell).

We also need to add the ability to use the offset classes.

Detecting media size in the js

There are 2 ways we could go about doing this. 

  • Add the modernizr js plugin and evaluating a css media query through their plugin, or
  • using a hidden div to detect the current size 

Both solutions we would probably want to implement as multiple functions which we could query with something like isLgScreen or isSmScreen etc.  Both approaches require us to be aware of our breakpoint sizes in the js as a constant (which should change because the values in bootstrap we shouldn't change).

The reason why you do not want to check directly against screen/window width is that different browser have different interpretations of this, and it is safer to check against the breakpoints from the css.

Solution two prototype from stack overflow (obviously we would the less boostrap constants here instead for the widths):

Modifying js/components in response to the screen sizes

We will have to a add a handler on resize (per component, or a global one which iterates over a list of callbacks) to check what window size we are at and fire the appropriate code in response.  What we can do in response may differ from component to component.

For our nav menu, for example, we may invoke the collapse action when it reaches a tablet size and then when it reaches a phone size we would likely have to swap classes on it somehow - may even require dom manipulation (and/or use media aware versions of its classes).  What is difficult about this is that we have to think of each of our components, and figure if they need to change state/functionality based on screen size, and whether or not we are going to do this dynamically on resize OR only once on initial screen size for each component.  If we have to do it dynamically the component complexity could becomes MUCH more complex as it requires us to manipulate or redraw it in real time based on screen size.  The simple ones are css manipulations, the hard ones are functionality changes as they will require us to add hooks. 

However, there may not be a ton of cases for this... (too optimistic probably).

Things to think about (off the top of my head):

  • How will messages appear at the different devices sizes?
  • How accessible does it need to be on a phone vs a desktop (obviously ideal is the same, but can we let in pass in some scenarios, case by case)?
  • Can we eliminate features at different screen sizes?
  • How will lightboxes work at the smaller screen sizes (I believe we need to invoke something that takes the whole screen at the smaller sizes for this, ie replace/hide page content temporarily)
  • How will tooltips work at different screen sizes (cut? inline? etc)?
  • Do we always show the full instructional text/constraint text at different screen sizes?
  • Do we even support suggest at smaller screen sizes?

Media Queries

Some of our concerns (at least the css based ones) could be solved by media queries.  For example :

In addition to media queries we can also show/hide content at different levels using the bootstrap classes: visible- and hidden-.  See:


The most difficult problem to solve, in my opinion, will be what to do with tables at multiple screen sizes.  There are a bunch of solutions out there, but most of them will not fit our needs mainly because of our usage of datatable (and its functionality).  In my opinion, only 3 a remotely feasible for our implementation.  A word of warning:  all the solutions will take a large amount of time to implement 100% correctly (talking weeks to months) in my estimation.

The one I like best would output something similar to one of these as the screen got smaller:

However this will have problems with datatables (obviously).  Note that even though it looks vastly different, it does not actually change the markup of the table (all css manipulations).  My thought on this, is that we may need to move sort into a dropdown that shows up when transitioning to this layout and somehow use that to activate the column sorts.  Another thing we may need to do is automatically change the number of items in the page as 10 or greater items will be really annoying to scroll through (maybe even make it one at  time so it is more like a slide deck).

Another solution is a plugin built for datatables, that will hide columns and put them into a details like disclosure as the screen gets smaller.  Opening this disclosure will reveal these extra fields.  This works exactly like our details functionality does right now, so it has obvious conflicts with that functionality (what do we do when we have details and this, where do we show the details, etc).  Also, its unknown if the plugin will work for us in all cases (or even work at all): (live examples don't work, you have to download then fix them)

which is based on:


The third solution is one that is similar to the above.  It will hide columns as the screen gets smaller, but will put these in a drop down where you can select what columns are currently visible.  This on will obviously add horizontal scroll as you add back in the non-important columns that were hidden for screen size reasons.  I think most of these options could be supported by datatables by toggling its options on and off as the size changes.

All these solutions are questionable when you also factor in subcollections (how will that look at each scenario?).



  • No labels