Life 360

the online magazine of the Purdue College of Health and Human Sciences (HHS)

View Live Site

Overview

Tech

Task Runner: Gulp.js
CSS: structured with BEM and processed by PostCSS-cssnext
JS: vanilla JS linted by JSHint and minified via UglifyJS
CMS: UI built & data stored in Cascade Server and compiled via Apache Velocity

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 all content management within CMS

Development Notes

After being inspired at the University of Illinois' Webcon, I decided this site was an opportunity to implement new methodology and tech:

using BEM to structure CSS classes
using PostCSS-cssnext to compile CSS

BEM — Block Element Modifier

Implementing BEM in this project was my first, hands-on experience with using a CSS methodology, and I'm not sure how I survived without one. While I tried using descriptive class names before, having a clear organization to the type of element being styled was a game-changer.

example of desktop version of featured stories section of home page — BEM was especially helpful when styling the various components that shared elements.

example of desktop version of highlighted and other stories sections of home page

PostCSS-cssnext

cssnext was pitched as an alternative to SASS or LESS that, instead, compile the future spec of CSS into CSS that is available now. Using it seemed like a no-brainer. The point of using a CSS preprocessor was to fill-in the shortcomings of the current state language. Why not use the future spec of the language rather than using an entirely different one?

As I continued through the project, I started noticing that even the future spec didn't have some features I used in SCSS:

mixins with parameter support
functions with the ability to return a value rather than a CSS property

For example, I usually convert my font-sizes, usually received as a pixel value, to rems in order to allow the user to resize them via the browser.

/* font-size conversion via cssnext */
:root {
  font-size: 1rem;
  --baseFontSize: 16; /* default font-size (in pixels) of most browsers */
}
.event__title {
  font-size: calc(20 / var(--baseFontSize) * 1rem); /* 1.25rems (20px) */
}
.event__description {
  font-size: calc(14 / var(--baseFontSize) * 1rem); /* 0.875rems (14px) */
}

Setting something as simple as converting the font-size is quite wordy in cssnext. In contrast, SCSS allows me to create a function that I can name in a friendlier manner.

/* font-size conversion via scss */
$font-size-px: 16;
@function convert-toRem($i) {
  @return $i/$font-size-px * 1rem;
}
.event__title {
  font-size: convert-toRem(20); /* 1.25rems (20px) */
}
.event__description {
  font-size: convert-toRem(14); /* 0.875rems (14px) */
}

While I could have used a mixture of SCSS and cssnext, I believe that it would have defeated the purpose of using cssnext in the first place. Overall, it was an interesting experiment, but I don't think cssnext will be added to my preferred toolset.