Skip to main content

Purdue Conferences

View Live Site

Overview

Tech

Task Runner
Gulp.js
CSS
flexbox and grid layout structured with BEM and ITCSS
JS
vanilla JS bundled with Browserify and Watchify
CMS
UI built & data stored in Cascade Server and compiled via Apache Velocity
Templating
reusable components generated via Handlebars

Responsibilities

  • review design for accessibility issues
  • use Git and GitHub for version control and tracking progress
  • develop reusable components and templates based on design
  • test for browser inconsistencies
  • implement the site within the CMS

Development Notes

The layouts proposed in the design of this site were trickier than others I've done in the past. This and difficulties with past projects called for some new approaches:

  • using CSS grid and flexbox
  • implementing Handlebars to handle templating

Using CSS Grid and Flexbox

CSS flexbox had been in my toolset for over a year since the start of this project; however, the overlapping rows of the home page along with the desired order of content didn't really work for flexbox.

the home page of the site, which implements CSS grid

Instead, I decided to use CSS grid to create this layout. I had avoided grid in the past because it had proven difficult to manage within IE11, the oldest browser we needed to support. Most of the layouts we created in the past could be handled with flexbox anyways, so there was no point in spending extra time to implement grid. Grid was acceptable to use in this instance since flexbox wouldn't work.

As a fallback for IE11, I decided to take a similar approach that the Slack team used in their latest redesign. This called for wrapping any use of grid within @supports rule. Since IE doesn't understand @supports, I was free to provide a flexbox backup.

/* example of using @supports */
.panels {
  // flexbox styles for browsers that don't support @supports
  display: flex;
  flex-flow: row wrap;
  justify-content: flex-start;
  align-items: stretch;
  &__panel {
    flex: 1 1 auto;
  }
  @supports (display: grid) {
    // grid styles for browsers that support @supports
    display: grid;
    grid-template-columns: 1fr 1fr;
    grid-template-rows: 0.75fr 0.25fr 0.73fr 0.15fr 0.75fr;
    grid-template-areas:
      "panel--0 panel--1"
      "panel--0 panel--2"
      "panel--3 panel--2"
      "panel--4 panel--2"
      "panel--4 panel--5";
    &__panel {
      &--1 {
        grid-area: panel--0;
      }
    }
  }
}

This approach did mean that IE11 would not have the desired layout, but still have a usable, appealing fallback.

Implementing Handlebars

The reason for using Handlebars during development was to have the ability to create more flexible components. In the past, I had simply used gulp-file-include in order to handle templating various components and page types. The problem with this plugin is that it didn't provide enough flexibility with its conditionals. For example, if I wanted to include a button that has four different looks depending on the used modifiers, I'd have to have multiple conditionals.

@@if(type === 'default'){
  @@if(light === false){
    @@if(color === ""){
      <a href="#" class="button">Button Text</a>
    }
    @@if(color !== ""){
      @if(color == "campus gold"){
        <a href="#" class="button button--campusGold">Button Text</a>
      }
      @if(color == "black"){
        <a href="#" class="button button--black">Button Text</a>
      }
    }
  }
  @@if(light == true){
    @@if(color === ""){
      <a href="#" class="button button--light">Button Text</a>
    }
    @@if(color !== ""){ 
      @if(color == "campus gold"){
        <a href="#" class="button button--campusGold button--light">Button Text</a>
      }
      @if(color == "black"){
        <a href="#" class="button button--black button--light">Button Text</a>
      }
    }
  }
}

This meant that I could need to have a conditional for every possible class combination. Gross, right?

Writing the same thing using Handlebars would be much shorter.

<a
  href="#"
  class="
    button
    {{ifEquals this.light true 'button-light'}}
    {{ifEquals this.color 'campus gold' 'button--campusGold'}}
    {{ifEquals this.color 'black' 'button--black'}}
  "
>
  Button Text
</a>

Using Handlebars did have a drawback though. There were some components that didn't have a large level of customization, which meant they didn't need various conditionals assigned to properties; however, the way it was built meant that that I still needed to create the Handlebars partial, import the partial into the template, and pass properties to the component.

In the end, I decided that Handlebars is a good for creating flexible components when we're not also implementing the site within a CMS. Otherwise, it's easier to create quicker, simple HTML snippets.