Web Design: Right-to-Left Support, Legacy Browsers & Organizing CSS

In the April 2015 issue of Website Magazine, Four Kitchen discussed its redesign of World Pulse's website - making it responsive and, overall, giving it a more modern feel. Four Kitchen provided such great detail into its project, that we turn to the Web to include what we couldn't in print. Those looking for more "geeky" accounts of the redesign are in luck, as Four Kitchen's Designer and Front-End Engineer Taylor Smith enlightens us on the heavy internationalization of the site, CSS organization and supporting legacy browsers.

Heavy internationalization, including right-to-left ("RTL") support.

Smith: While only English and French are currently supported natively, this site will ultimately be offered in three additional languages including Arabic. From a front-end perspective, internationalization for other LTR languages was fairly simple. The words change, but the layout is mostly the same. Speaking Spanish was definitely helpful. Minor challenges included making sure Web fonts had a full suite of accented characters for Spanish, or accommodating longer words and phrases for labels in French. 

RTL, however, flips the entire design "backwards," uses a character set I can't even pretend to read, and introduces a key cultural difference: these users will look to the right by default. A simple distinction, but a very different mindspace. Thankfully, Drupal knows to add the direction attribute on the HTML tag, which makes targeting this language in CSS as easy as using a Modernizr or IE conditional class. We wrote a simple Sass mixin `@include rtl()` to be consistent with our application of that root-level selector, which takes an optional argument to add a class to the selector (in the case of needing to combine both a direction and a Modernizr/IE conditional class), which would look something like `html.svg[dir="rtl"] &` when expanded. 

Partial Madness - Organizing CSS

Smith: As a large site with many features, organization of CSS became very important. Thankfully, Sass makes splitting CSS across multiple files easy with partials. When compiled, Sass aggregates all imported partials, unlike CSS's default behavior of fetching included CSS files client-side (a major performance hit). With a focus on component-based design, we split out partials into distinct items. Each partial addressed a single selector, and we were fairly granular: _view-wp-home-global-issues.scss contains rules which apply only to .view-wp-home-global-issues and its descendants. Beyond this Sass also enabled us to make heavy use of extendables to reduce code duplication, and to leverage the parent selector within these component partials to stay organized about changing the appearance of a component based on its location or context.

Powerfully Responsive, but Functional on Legacy Browsers

Smith: IE8 is not dead for this user base, and maintaining support for that version was important. Respond.js is a workable solution for pixel-based min/max-width media queries, but it's slow and has to be placed in the head area, and we output media queries in ems for better accessibility. Thankfully, Breakpoint, the Compass extension, makes "no-query" fallbacks easy to write. For example, given a content-focused breakpoint like "two-column-article-list" which has a screen mid-width of 30em, a no-query fallback can be declared for that breakpoint so that the styles assigned to it will also be output in a separate file (like, say, styles-ie8.css) which does not specify a media query. This way, styles for wider screens (with browsers that support media queries) as well as for IE8 (which we can assume to be desktop users) can be written once and output in two different ways so that it is employed appropriately for both groups of users.