Purdue Conferences
View Live SiteOverview
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.
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
"
>
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.