Blacklight Styling

6/4/2019

Recently I've been working on implementing a Blacklight-based catalog for Penn State University Libraries. We are mostly through with mapping the MARC data from the catalog via Traject and integrating availability information, so we are at a point where we can start worrying about look-and-feel.

And then today Jonathan Rochkind asked "Can we stop redefining base bootstrap?" Considering my current working in theming-land, this got me thinking about markup and styling in general on a Blacklight application. There are a few different ways styles and their necessary markup are handled in the Blacklight engine, for example

  1. Adding special classes without styling to serve as hooks (see this PR)
  2. Also, there are a lot of places that have camel case id attributes, which probably made sense at the time, but now is probably not very useful (being that id targets are too brittle for JS and slower than classes for CSS). 
  3. Additionally with Bootstrap 4 there is an abundance of utility classes for modifying alignment, border, padding, margin, etc. And it becomes even blurrier in terms of where and how an element should be styled. There are a few places this is used too.

FWIW (spoiler: not a lot) to me what makes sense is

  1. Rely on Bootstrap 4 as much as possible
  2. Don't override Bootstrap classes (as Rochkind suggests)
  3. Eliminate any id or class that is not currently in use
  4. Override Bootstrap via modifying Bootstrap set variables.
  5. If you just need to nudge an element a little, like modifying a bit padding, then just use the utility class (i.e., pb-1). IMO, these should be used sparingly - mainly because I think it is a little messy to look at and can feel a bit too much like the old inline style attributes of yore.
  6. If you need to make a lot of style changes to an element because of a real custom need, make a class and hang it on the element. This is a last resort. And use built-in Bootstrap mixins and variables whenever possible in these classes.

Oh, and one bonus one: use the nifty Nittany Valley assembled (h/t Adam Wead) niftany gem (or at least scss-lint).

Lastly, to muddy all of this further, something to keep an eye on is the fact that Blacklight seems to be headed toward favoring an API-based decoupling of backend and frontend. I make this comment based on the fact that the community in general seems to have a lot of pain around Bootstrap upgrades, the fact that I can see how it'd be nice to not have to worry about theming in Blacklight core and instead just focus on Rails logic of controlling and outputting Solr data, and lastly because of the popularity of decoupling in general via React, VueJS, etc (especially given webpacker). I could be very wrong about this, but it seems at least a possibility. Certainly the Blacklight engine right now can be integrated with a modern event-driven Javascript framework. There have been a few examples of this kind of decoupling, like this Blacklight VueJS sample project.

P.S. Just to be clear, the Blacklight community is amazing and the engine and its related family gems are fantastic.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.