Using esbuild and pnpm to Set Up Frontend Asset Bundling in an ASP.NET Core Web App

2025-08-25T00:00:00+00:00

Recently we had to build an admin dashboard on ASP.NET Core. We decided to hit the ground running by looking for a template online. Luckily, we found a very cool one from Start Bootstrap that met our requirements. It was built using Bootstrap, had nice styling, and included examples of graphs, tables, and basic common pages like login and registration.

However, integrating the template into an ASP.NET Core web app was a bit involved. The template uses tools like Pug and Sass/SCSS, which are not supported out of the box by ASP.NET. So some work had to be done to properly integrate it.

We ended up with a nice approach for handling frontend asset bundling using pnpm and esbuild, with support for JavaScript and Sass.

You can find a codebase that uses the setup we’ll be discussing here on Github. It’s an empty ASP.NET Core Razor Pages project that implements Start Bootrap’s admin template. Feel free to review it alongside this article and/or use it for your own projects.

We’ve also uploaded to NuGet a template for an empty ASP.NET Core Razor Pages web app that has implemented the esbuild-based frontend asset bundling.

Installing pnpm and the necessary packages

First of all we need to have the .NET framework installed. We also need to install Node.js and the pnpm package manager.

$ dotnet --version
9.0.302
$ node --version
v22.18.0
$ pnpm --version
10.14.0

Once we have those, we need a Razor Pages project to apply the changes to. For our purposes, I’m going to assume we’re starting off with a fresh project, created using something like dotnet new webapp.

With that out of the way, we can create a package.json file in the root of our project:

$ pnpm init
Wrote to /path/to/code/package.json

{
  "name": "demo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "packageManager": "pnpm@10.14.0"
}

We can adjust the resulting package.json to better reflect our project. Maybe remove the main and scripts.test settings, which we don’t need. Maybe also set a name and description.

In any case, now that we have this, we can install the Node.js packages that we need. I mentioned that we were going to use esbuild and SCSS so let’s install those as dev dependencies:

$ pnpm add esbuild esbuild-sass-plugin sass@1.78.0 --save-dev
Packages: +41
+++++++++++++++++++++++++++++++++++++++++
Progress: resolved 103, reused 50, downloaded 0, added 41, done

devDependencies:
+ esbuild 0.25.9
+ esbuild-sass-plugin 3.3.1
+ sass 1.78.0 (1.90.0 is available)

╭ Warning ───────────────────────────────────────────────────────────────────────────────────╮
│                                                                                            │
│   Ignored build scripts: esbuild.                                                          │
│   Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.   │
│                                                                                            │
╰────────────────────────────────────────────────────────────────────────────────────────────╯

Done in 2.5s using pnpm v10.14.0

I’ve pinned the version of the sass package to 1.78.0 in order to work around some compatibility warnings with Bootstrap’s stylesheets. You may or may not need to do this in your own projects.

We have to address the warning message and allow esbuild to run scripts. Running pnpm approve-builds and selecting esbuild (by pressing either the “Space” or “a” keys) takes care of that:

$ pnpm approve-builds
✔ Choose which packages to build (Press <space> to select, <a> to toggle all, <i> to invert selection) · esbuild
✔ The next packages will now be built: esbuild.
Do you approve? (y/N) · true
node_modules/.pnpm/esbuild@0.25.9/node_modules/esbuild: Running postinstall script, done in 40ms

With that, the package.json file should be looking like this:

// ./package.json

{
  "name": "demo",
  "version": "1.0.0",
  "description": "",
  "scripts": {},
  "keywords": [],
  "author": "",
  "license": "ISC",
  "packageManager": "pnpm@10.14.0",
  "devDependencies": {
    "esbuild": "^0.25.9",
    "esbuild-sass-plugin": "^3.3.1",
    "sass": "1.78.0"
  }
}

There should also be a new pnpm-workspace.yaml file that contains the setting for the approval we gave for esbuild:

# ./pnpm-workspace.yaml

onlyBuiltDependencies:
  - esbuild

In this particular example, we’re adapting Start Bootrap’s admin template, so we’re going to install the packages that it needs:

$ pnpm add @fortawesome/fontawesome-free bootstrap chart.js jquery simple-datatables
Packages: +9
+++++++++
Progress: resolved 112, reused 59, downloaded 0, added 9, done

dependencies:
+ @fortawesome/fontawesome-free 7.0.0
+ bootstrap 5.3.7
+ chart.js 4.5.0
+ jquery 3.7.1
+ simple-datatables 10.0.0

Done in 2.9s using pnpm v10.14.0

These are the ones we need for this project but of course, in your own projects you can install whatever you want.

Authoring JavaScript and SCSS source files

Now that we have the Node.js part of the project set up, we need a place where we can put our JavaScript and SCSS files. For that, we created two new directories: JavaScript and Stylesheets.

Since we’re adapting Start Bootrap’s admin template, we copied all its SCSS files into the Stylesheets directory and put its JavaScript into the JavaScript directory. It all ended up looking like this:

 .
+├── JavaScript
+│   └── site.js
 ├── Pages
+├── Stylesheets
+│   ├── layout
+│   ├── navigation
+│   ├── plugins
+│   ├── variables
+│   ├── _global.scss
+│   ├── site.scss
+│   └── _variables.scss
 ├── wwwroot
 │   ├── css
 │   ├── js
 │   └── favicon.ico
 ├── appsettings.Development.json
 ├── appsettings.json
+├── package.json
+├── pnpm-lock.yaml
+├── pnpm-workspace.yaml
 ├── Program.cs
 ├── RazorStartBootstrapAdmin.csproj
 └── README.md

Of course, the specific file contents will be different in your own projects, but the take home message is that these two new directories are meant for the source files of your frontend assets.

Bundling frontend assets with esbuild

With that, we have the NodeJS package management ready, the tools we need, and a project directory structure that supports writing JavaScript and SCSS.

Now we need to put together an esbuild.config.mjs file that processes these files and produces the bundles. Here it is:

// ./esbuild.config.mjs

import * as esbuild from 'esbuild';
import { sassPlugin } from 'esbuild-sass-plugin';

// SCSS
// This is a list of all the SCSS files that we want to bundle and their
// respective output files. In this project's case, we have only one.
// We put the resulting file under ./wwwroot/css. "wwwroot" is the default
// location used to expose files to the public in ASP.NET Core Razor Pages
// projects.
const scssFiles = [
  { entry: './Stylesheets/site.scss', outfile: './wwwroot/css/site.css' },
];

// Here we tell esbuild to take the entry SCSS files as input and produce CSS
// files ready to be interpreted by a browser. Since the source files are SCSS,
// we use the esbuild-sass-plugin plugin to translate them into CSS.
scssFiles.forEach(async file => {
  await esbuild.build({
    entryPoints: [file.entry],
    bundle: true,
    sourcemap: true,
    // Some libraries, like Bootstrap, include icons as woff and woff2 font
    // files. To handle this, we specify this loader setting. Instructing
    // esbuild to use the "file" loader, when it encounters such files. The
    // "file" loader takes care of copying the files into the output
    // location.
    // More info: https://esbuild.github.io/content-types/#file
    loader: { '.woff': 'file', '.woff2': 'file' },
    outfile: file.outfile,
    plugins: [sassPlugin()]
  });
});

// JavaScript
// Similar to the stylesheet files, for JavaScript we also declare a list of the
// files that we want to bundle.
const jsFiles = [
  { entry: './JavaScript/site.js', outfile: './wwwroot/js/site.js' },
];

// Bundling here is simpler than SCSS because we don't need custom loaders or
// plugins. Just specify entry points and output files and esbuild knows what to
// do.
jsFiles.forEach(async file => {
  await esbuild.build({
    entryPoints: [file.entry],
    bundle: true,
    sourcemap: true,
    outfile: file.outfile,
  })
});

One important thing to note here is that with esbuild, we can safely use JavaScript modules and import statements for both JavaScript and SCSS. This means that our frontend logic and styling rules can be broken up into any number of files, forming a tree of dependencies through import statements. We need only to specify the root files, or entry points, and esbuild takes care of building a complete and self-contained bundle. Not really a revolutionary idea in the grand scheme of things, but not always a given when working with JavaScript on the browser.

With this, we can trigger the bundling process: node esbuild.config.mjs. However, it’d be nice to have it better integrated with a typical .NET development flow. For that, we can add the following under scripts in package.json:

// ./package.json

{
  // ...
  "scripts": {
    "build": "node esbuild.config.mjs"
  },
  // ...
}

This allows us to run pnpm run build instead.

Finally, we can have this command run automatically as part of dotnet build if we add the following to our .csproj file:

<!-- ./RazorStartBootstrapAdmin.csproj -->

<Project Sdk="Microsoft.NET.Sdk.Web">

  <!-- ... -->

  <Target Name="BundleFrontendAssets" BeforeTargets="Build">
    <Exec Command="pnpm install" />
    <Exec Command="pnpm run build" />
  </Target>

</Project>

All this will result in our build process producing ./wwwroot/css/site.css, and ./wwwroot/js/site.js bundles. Which we can include in our .cshtml files like we would any other .js or .css file:

<!-- ./Pages/Shared/_Layout.cshtml -->

<!-- ... -->
<link rel="stylesheet" href="~/css/site.css" asp-append-version="true" />
<!-- ... -->
<script src="~/js/site.js" asp-append-version="true"></script>
<!-- ... -->

Importing libraries as modules

One interesting aspect to note is that, with esbuild, we are using JavaScript modules with import statements. This is particularly important for libraries, since some of them won’t necessarily support being included as JavaScript modules by default or in an obvious manner.

Our site.js demonstrates this. For example, it loads Bootstrap and the Font Awesome icons using the following statements:

// ./JavaScript/site.js

import 'bootstrap';
import '@fortawesome/fontawesome-free/js/all';

// ...

This makes it so any page that includes site.js will also have Bootstrap and the Font Awesome icons available.

To get the same for something like JQuery, for example, the strategy is a little different:

// ./JavaScript/site.js

import jQuery from 'jquery';
window.$ = window.jQuery = jQuery;

// ...

A similar scenario happens with the stylesheets. For SCSS, we have to use the @import statement. Our site.scss contains examples of this. Here’s how we load Bootstrap’s CSS, for instance:

// ./Stylesheets/site.scss

// ...
@import "bootstrap/scss/bootstrap.scss";
// ...

In your projects, you’ll encounter libraries with varying levels of support for JavaScript modules, and you will have to adapt accordingly, depending on the library itself and how you want to use it.

Importing libraries via HTML tags

There are also some libraries that only work via traditional <script> tags. For these, you might want to have esbuild copy files directly from the node_modules directory into wwwroot, without any preprocessing. You could use something like this in your esbuild.config.mjs file for that:

// ./esbuild.config.mjs

// Raw files
const rawFiles = [
  { entry: './node_modules/path/to/package.js', outfile: './wwwroot/lib/package.js' },
  { entry: './node_modules/path/to/package.css', outfile: './wwwroot/lib/package.css' },
];

rawFiles.forEach(async file => {
  await esbuild.build({
    entryPoints: [file.entry],
    bundle: false,
    sourcemap: false,
    loader: { ".*": 'copy' },
    outfile: file.outfile
  });
});

Then you can include the files from wwwroot using the appropriate <script> or <link rel="stylesheet"> tags.

Summary

So, in the end, using esbuild and pnpm to set up frontend asset bundling in an ASP.NET Core web app is perfectly doable and can be summarized like this:

Install NodeJS and pnpm
Create a package.json file with pnpm init
Install esbuild as a dev dependency with pnpm add esbuild --save-dev

Also make sure to run pnpm approve-builds to allow esbuild to run scripts
Install any additional preprocessor that you might need like sass with esbuild-sass-plugin, etc.
Create JavaScript and Stylesheets directories and put your source files in them
Add an esbuild.config.mjs file that can bundle your assets
Include the asset bundling step as part of the dotnet build command

Your package.json should end up looking something like this:

{
  "name": "",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    // Register this so that esbuild can be called with "pnpm run build"
    "build": "node esbuild.config.mjs"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    // Add your dependencies here.
  },
  "devDependencies": {
    "esbuild": "0.25.9",
    // Add other preprocessors and plugins here, like:
    "esbuild-sass-plugin": "3.3.1",
    "sass": "1.78.0"
  }
}

Here’s an example of an esbuild.config.mjs that covers the common scenarios:

import * as esbuild from 'esbuild';
import { sassPlugin } from 'esbuild-sass-plugin';

// SCSS
const scssFiles = [
  { entry: './Stylesheets/site.scss', outfile: './wwwroot/css/site.css' },
  // Add other stylesheet files here.
];

scssFiles.forEach(async file => {
  await esbuild.build({
    entryPoints: [file.entry],
    bundle: true,
    sourcemap: true,
    loader: { '.woff': 'file', '.woff2': 'file' },
    outfile: file.outfile,
    plugins: [sassPlugin()]
  });
});


// JavaScript
const jsFiles = [
  { entry: './JavaScript/site.js', outfile: './wwwroot/js/site.js' },
  // Add other JavaScript files here.
];

jsFiles.forEach(async file => {
  await esbuild.build({
    entryPoints: [file.entry],
    bundle: true,
    sourcemap: true,
    outfile: file.outfile,
  })
});

// Raw files
const rawFiles = [
  { entry: './node_modules/path/to/package.js', outfile: './wwwroot/lib/package.js' },
  { entry: './node_modules/path/to/package.css', outfile: './wwwroot/lib/package.css' },
  // Add other library files here.
];

rawFiles.forEach(async file => {
  await esbuild.build({
    entryPoints: [file.entry],
    bundle: false,
    sourcemap: false,
    loader: { ".*": 'copy' },
    outfile: file.outfile
  });
});

This is the addition that the .csproj file needs in order to bundle the frontend assets during dotnet build:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <!-- ... -->

  <Target Name="BundleFrontendAssets" BeforeTargets="Build">
    <Exec Command="pnpm install" />
    <Exec Command="pnpm run build" />
  </Target>

</Project>

With that, you’re free to add the bundles and raw files in your pages using traditional methods like:

<link rel="stylesheet" href="~/css/site.css" asp-append-version="true" />
<link rel="stylesheet" href="~/lib/package.css" asp-append-version="true" />

and…

<script src="~/js/site.js" asp-append-version="true"></script>
<script src="~/lib/package.js" asp-append-version="true"></script>

As you create more entrypoint JavaScript and SCSS files, you have to remember to add them to their respective arrays in esbuild.config.mjs.

You can add more packages using pnpm add <package_name>. Just remember that they have to be imported by your JavaScript files as modules. If you need to add raw files, especially from libraries that don’t support being imported as JavaScript modules, the esbuild.config.mjs file also supports that thanks to the “raw files” section. These raw files can be loaded normally via <link> and <script> HTML tags.

All right, that’s it for now. We’ve seen how to integrate esbuild with ASP.NET Core in order to setup a basic frontend asset bundling process. We did that through adapting Smart Bootstrap’s free admin template into an ASP.NET Core Razor Pages web app project — a project that’s up on GitHub. We saw how to organize source files in our repo, a basic esbuild config script that handles the most common scenarios, and how to handle a few different cases when it comes to including NodeJS packages into our apps.

Comparison of Lightweight CSS Frameworks

2022-01-13T00:00:00+00:00

Several months ago I was building a new website and needed a CSS framework. There are many new CSS frameworks around now, so I decided to do several small trial runs and compare them to find the most fitting for our site.

Initially I tried using Foundation, which this site is built on, but I ran into a problem: Foundation and other popular frameworks are powerful, but they have more features than I needed, and they take up too much disk space for a modest website. Foundation is about 6000 lines long and 200kB unminified. It can be shrunk by removing components you don’t need, but the time it takes to slim a large CSS framework down to your needs can be more than it’s worth, especially if you want to change any styling.

Instead of adapting a larger framework to my needs, I looked into lightweight CSS frameworks. These aim to provide boilerplate components, better styling for buttons, forms, tables, and the like, all at the cost of very little disk space.

I like to modify the source CSS as needed, so all of the sizes I list will be unzipped and unminified. They are also from my brief real-world testing on one machine, so your mileage may vary.

Bulma

Bulma looked very attractive at first. It has sleek, modern design and is quite popular, with a good-sized community for support. But for our site, it was still too big. I only used a few components and layout helpers, a fraction of its 260kB — around 50kB bigger than Foundation, in my tests!

mini.css

mini.css had some great things going for it, but got pushed out by even smaller options which I’ll cover shortly. It took up about 46kB with all the bells and whistles.

The use of flex is a bonus, but it’s a little too style agnostic for the website I was working on; I would have overridden a lot of its styling, making the overhead size even larger.

It has options for using SCSS or CSS variables, which I always like to see. I prefer SCSS’s added features and variables, but if you would rather use vanilla CSS, mini.css has a plain option using CSS variables, which I don’t see too often.

Pure.css

Pure.css offers similar features to the other frameworks on this list, and weighing in at around 17kB, it competes well in size. However, I wasn’t a big fan of its look, and with some odd omissions, notably, the absence of a container class for horizontally centering content, it was edged out by the competition.

Skeleton

Skeleton has very clean styling and a good selection of minimal components. It’s tiny, weighing in at 12kB. Unfortunately, it hasn’t had a release since 2014, and uses float instead of Flexbox, which took it out of the running for building a more modern site.

Milligram

Milligram feels like a spiritual successor to Skeleton: It covers a similar scope, and has a simple, clean design reminiscent of Skeleton’s. In lieu of using classes, it usually applies styling directly to HTML tags. This is a choice I like, since I don’t follow the Tailwind CSS approach of creating websites purely in HTML, with agnostic classes applied to the layout.

It also has an SCSS offering, so it’s easy to drop components you don’t want, making it even tinier!

The size and simplicity of Milligram made it win the bid. It has worked quite well, providing just enough framework to be useful for small websites, but getting out of the way so that you can do your own styling.

Making the most of your lightweight framework

Hopefully this post will give you an idea of what each of these frameworks is like, but the best way to test them is by trying them yourself! These five were fairly quick to spin up and test out on the website I was working on, and doing the same will give you the best idea of what your website needs.

With frameworks that are only a few kilobytes, you can also read through the entire source. I tried to look through enough of each framework’s CSS files to become familiar with its way of doing things. This eased the whole website-building process, and will help you find a framework that matches your style of web development.

Also see my colleague Afif’s article Building responsive websites with Tailwind CSS for an in-depth look at Tailwind CSS.

Building responsive websites with Tailwind CSS

2021-12-03T00:00:00+00:00

Tailwind CSS is a CSS framework, like Bootstrap, Bulma, and Foundation. However, Tailwind does things in a less conventional way when compared to traditional CSS frameworks. Instead of providing CSS classes based on components or functional roles (e.g. .card or .row), Tailwind only provides utility classes, in which each class does only one specific thing a CSS attribute usually does, such as m-4 for margin: 1rem or mt-8 for margin-top: 2rem.

In Bootstrap, one can simply apply the provided .card CSS class to have a <div> styled like a card the Bootstrap way. In Tailwind, the styles have to be constructed with a string of different atomic classes. E.g. the equivalent of a Bootstrap’s .card would be something like relative flex flex-col break-words bg-white bg-clip-border min-w-0 rounded border. Verbose, yes, but this gives flexibility for the developers to define the appearance of a .card element themselves (e.g. there could be multiple variants of appearances of a .card) without having to worry about overriding inherited/cascading CSS classes, which are typically the cause of many CSS bugs in production.

Atomic CSS

The first thing most notice when developing with Tailwind is how wordy CSS class lists can get. It feels almost like using the style="" attribute to write CSS. In the traditional approach to CSS, suppose there are two elements with identical margins:

.card {
  display: block;
  margin: 1rem;
}

.container {
  margin: 1rem;
}

Here, we can see that margin is declared twice. Those duplicates are going to be a few extra bytes in the final CSS payload.

With Tailwind, however, this is how the equivalent would be written:

<div class="block m-4">
</div>

<div class="m-4">
</div>

Here, both of the <div>s are reusing the same class m-4, which is provided out-of-the-box by Tailwind. This approach ensures that the project’s CSS does not grow, which is important for good user experience. Constructing the CSS of a page is a render-blocking task in a web page load. So, the bigger the CSS, the longer the wait time for a user to see something on the browser. Yes, the HTML payload will grow, but just by a little.

One of the differences between using Tailwind CSS classes and using style attribute is that the latter cannot be used to style pseudoclasses (e.g. :hover, :disabled). With CSS classes, that is achievable, but there are special prefixes that Tailwind provides for each of the variants to take effect.

For example:

<!-- margin: 1rem by default, margin: 2rem on hover -->
<div class="m-4 hover:m-8"></div> 

<!-- white background by default, light gray background when disabled -->
<input class="bg-white disabled:bg-gray-100"/>

Keep in mind that not all variants/pseudoclasses are supported by default, as this would make the development output of a Tailwind CSS file really big to cater all of the possible variants. To have them supported, it has to be configured inside the project’s tailwind.config.js:

// tailwind.config.js
module.exports = {
  variants: {
    extend: {
      backgroundColor: ['active'],
      // ...
      borderColor: ['focus-visible', 'first'],
      // ...
      textColor: ['visited'],
    }
  },
}

Or, if the project is on Tailwind CSS v2.1+, the developers can enable Just-in-Time mode, which grants access to all variants out-of-the-box while also being more functional in development mode.

See Just-in-Time mode for more details.

Shaking off the unused CSS

By default, Tailwind will be loading the whole Tailwind CSS project files, with CSS declarations on almost every possible CSS rule. There are a lot in there that a developer might never use. To put that into context, there are 105 different values just for grid and flexbox gaps. Most projects aren’t likely to use them all, so Tailwind needs a way to remove the unused CSS when generating the final CSS build for production use.

This is where PurgeCSS comes in. PurgeCSS is a plugin that analyzes all CSS, HTML, and JavaScript files in the project and removes unused CSS declarations from the final build. This tool is available as a PostCSS, Webpack, Gulp, Grunt, or Gatsby plugin.

Because PurgeCSS analyzes the project’s source code to find exact matches of a given CSS style, a CSS class cannot be used through string concatenations or PurgeCSS will not be able to detect that the given Tailwind class is used.

// SomeComponent.jsx
const SomeComponent = (props) => {
  return (
    <div className={'text-' + props.color}>
      Some text
    </div>
  )
}

// <SomeComponent color='gray-400'/>
// In this case, `text-gray-400` will be removed by PurgeCSS in the final CSS 
// production build because it does not know that the component is using it.

DRYing it up

Suppose we have two cards on the page and we want their appearance to be consistent. In the traditional CSS approach, both these two cards will just have the .card CSS class, and the same styles would be applied to both of them. In Tailwind we can’t do that, however, and it doesn’t make sense to be repeating 7 or 8 or more different class names on both HTML elements on the page.

const AppButton = () => (
  <button className='py-2 px-4 font-semibold rounded-lg shadow-md'>
    I'm a button
  </button>
)

// Just use <AppButton> everywhere and their appearances will be consistent
// No need to repeat the CSS classes for all three components
render(
  <Form>
    <AppButton/>
    <AppButton/>
    <AppButton/> 
  </Form>
)

Therefore, Tailwind can be easier to implement in component-based frameworks, such as Vue or React. But even if you’re not using any of them and are just building a plain HTML file, Tailwind provides a way to compose these classes together by using @apply:

.button {
  @apply py-2 px-4 font-semibold rounded-lg shadow-md;
}

.button.success {
  @apply py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-green-400;
}

Then, .button and .button.success classes will be available to us for reuse as in traditional CSS.

<!-- py-2 px-4 font-semibold rounded-lg shadow-md gets applied when using "button" -->
<button class="button">I'm a button</button>

<!-- py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-green-400 gets applied -->
<button class="button success">I'm a green button</button>

Building a responsive page using Tailwind

Now let’s look at responsive design. Suppose we want to implement a page with a navigation bar, a sidebar, a content area, and a footer:

And the sidebar and content area should collapse into one column on mobile devices, like this:

First, let’s have the basic page layout:

<nav class="p-4 bg-gray-100">
  <ul class="flex gap-2 justify-end">
    <li>Home</li>
    <li>About</li>
    <li>Contact</li>
  </ul>
</nav>
<div class="flex flex-col">
  <aside class="flex items-center justify-center p-4 bg-red-100">
    Sidebar
  </aside>
  <main class="min-h-screen p-4 bg-green-100">
    <p>
      Sit eos nam quam nemo qui. Quas recusandae praesentium ratione incidunt sunt commodi labore Nemo nemo error molestias saepe ducimus? Porro reprehenderit voluptatibus nihil voluptate quia. Voluptatibus autem maiores vero?
    </p>
    <p>
      Consectetur veniam voluptate esse amet debitis eius? Voluptatem officia quibusdam voluptates cum rerum Odio rem maiores laborum commodi cum. Nobis numquam quia nemo maiores repellendus error fuga Repellendus consequatur laudantium?
    </p>
    <p>
      Elit vitae sit reprehenderit sit laboriosam Ratione iusto numquam corrupti ullam libero! Nisi veritatis facere repudiandae eos perspiciatis recusandae veritatis. Cupiditate temporibus repellat tempore optio numquam id! Perferendis maxime unde
    </p>
    <p>
      Dolor autem dolore tempora atque provident. Maxime quos ipsum porro non suscipit. Consectetur et perspiciatis perspiciatis illum quos Ab nostrum unde facere nemo mollitia, saepe ab? Vitae tempore hic accusamus
    </p>
    <p>
      Elit labore odit error pariatur cupiditate Ex sequi accusantium maxime et vero Unde quo laboriosam illo ipsam modi eaque Delectus dolorem quas quidem reprehenderit fugiat! Exercitationem provident voluptatum perferendis ut.
    </p>
  </main>
</div>
<div class="p-4 bg-yellow-100">
  <h5 class="font-bold">Footer links</h5>
  <ul>
    <li>Home</li>
    <li>About</li>
    <li>Contact</li>
  </ul>
</div>

Tailwind official documentation recommends taking a mobile-first approach. Hence, all classes without any screen-size variants will be applied to all screen sizes. Tailwind then provides several screen-size variants such as sm, lg, xl, and 2xl that can be used to control the appearance on specific screen sizes range.

This is what we’re doing here. As you can see, we’re using flexbox layout to collapse all elements down to a single column.

Responsive variants

Now, let’s add Tailwind’s responsive variants so that the page is responsive to screen sizes. In our case, what we would want is to have aside and main placed side-by-side when there’s enough real estate on the screen. To achieve that, we would need to switch the flex-col class to flex-row on bigger screen sizes.

<div class="flex flex-col md:flex-row">
  <aside class="flex items-center justify-center p-4 bg-red-100 md:flex-none md:w-1/3 lg:w-1/4">
  <!-- sidebar -->
  </aside>
  <main class="min-h-screen p-4 bg-green-100">
  <!-- main content -->
  </main>
</div>

flex-col md:flex-row here does the trick for us. md variants, by default, kick in when the screen width is at a minimum of 768px. At that point, our flexbox will change from the column layout to the row layout, displaying our aside and main elements side-by-side in one row. To better distribute the width, we specify md:w-1/3 and lg:w-1/4 classes to the sidebar. w-1/3 and w-1/4 sets the width of the elements to one-third and one-fourth of the parent container respectively. The md and lg variants both control at what screen sizes should Tailwind apply which styles.

Conclusion

It can be a bit daunting to start, but once you get a handle on it, Tailwind CSS is a great option for rapidly building user interfaces with total control over the styles. Unlike other frameworks, Tailwind does not attempt to provide a default styling of any component, allowing every site that uses Tailwind to be truly unique from another.

These responsive variants can be applied to any other CSS class from Tailwind, providing a powerful way to build responsive user interfaces. The very thin abstraction over CSS provides developers with a greater flexibility and control over the design while being a good constraint to guide the development process.

Happy styling!

Catching CSS Regressions and Visual Bugs in Continuous Integration

2021-06-24T00:00:00+00:00

Photo by Alexandra Nicolae

Many web projects nowadays are equipped to simulate real users and automatically test a real use case, but these end-to-end tests still have a weakness. Browser automation tools run tests by performing the interactions and assertions in the context of the DOM of the pages. That is very different from how humans use web applications, which is by looking at the user interface. Due to this, the tests’ definition of a “functional web app” differs from that of a real human.

For example, let’s take a simple music player with two buttons:

One in green with a play icon, and
One in red with a stop icon.

The HTML would look something like this:

<!-- music player -->
<button class="button is-red"><i class="icon icon-stop"/></button>
<button class="button is-green"><i class="icon icon-play"/></button>

In our end-to-end tests, one would typically instruct the test to check:

If the expected classnames exist.
If clicking the stop button stops the music.
If clicking the play button plays the music.

If all of the above conditions were met, then the app is considered “functional”. However, the tests have no way to verify if the right colors are actually reflected on the buttons, or if the SVG icons on the button are properly loaded and shown to the users. Unfortunately, for a real user, both of these are very crucial in telling the user how the app functions. If the stylings for the buttons are not implemented or the SVG icons for the buttons fail to load, users will not have a clear indication on how the app works, and the app will not be considered “functional” by real users, even though the functionalities of both buttons are wired correctly in the code.

Web developers also frequently deal with styling regressions. This can happen due to the “cascading” characteristic of CSS: Badly scoped CSS values may affect other elements in unrelated areas unintentionally. Many times, styling regressions slip past even the end-to-end tests with browser automation because, again, end-to-end tests only verify that the app’s functionalities are wired together, but do not check if things appear the right way visually.

Visual regression testing to the rescue

Visual regression testing adds another quality gate in the workflow to allow developers to verify that, after a code change, the user sees what is expected. For example, if the code change is supposed to modify the appearance of an element, developers can verify that it’s doing just that, or at the very least, the code change should not adversely affect other areas. Visual regression testing involves taking screenshots of tested scenarios with changes and comparing them against the baseline (usually screenshots from the stable branch).

This type of test complements the other testing categories in the test pyramid and ensures user experience is not adversely affected from any given code changes. For more information on the test pyramid and different categories of testing, visit this blog post by my colleague, Kevin.

There are many tools that help with visual regression testing. Here are some tools that you could look into:

Percy.io
- Generous free tier to get you started.
- 5000 free screenshots per month with unlimited team members. This should get you going just fine for smaller projects.
- Integrate with many mainstream end-to-end tests frameworks.
Applitools
- Uses AI-powered computer vision for visual diffing. Said to reduce a lot of false positives and be more efficient.
Testim.io Automation
- Another service that uses AI-powered computer vision.
BackstopJS
- A Node.js library you can set up yourself.

Each tool has its own strengths and weaknesses. For today’s demonstration, we are going to look at implementing visual regression testing with Percy and see how it works.

Integrating Percy

Percy provides comprehensive guides to get you started with many popular end-to-end test frameworks such as Selenium, Cypress, TestCafe, and Capybara. You can check the documentation to see how to integrate it with your project. Since we work with Rails a lot at End Point, we are going to demonstrate Percy within a Rails project alongside Rspec/Capybara-driven end-to-end tests.

In this article, we are going to use this simple Rails project I built for fun as the demo. It is just a simple wiki project using Vue and Rails. Let’s start.

1. Register an account at percy.io

Head to percy.io and click the “Start for Free” button on the top-right side.
Choose the preferred sign up method. In this case, we are just going to use email and password, so we will choose Sign Up with Browserstack.
Fill in the email and password and complete the registration. It will then send an email to ask us to verify our email address. Let’s check our email and complete the email verification.
Next, we will see the Get Started screen. We will choose Create a New Project and give it a relevant name.
We have successfully created a new percy.io project and should be on the project page. There are some links to setup guides that can help us integrate Percy into our project.
Let’s navigate to Project Settings. We will scroll down to the Branch Settings section and make sure the Default base branch points to the primary branch of our project’s repository. This is usually main, master or develop depending on your team’s workflow. You might want to make the same branch auto-approved as well. That way, screenshots from this branch will be treated as the baseline and will be used when comparing against the development branches. In our case, we are using the main branch so we will specify that in both fields.

Great, we have now successfully set up Percy. There are other configurations in the Project Settings page (e.g. browsers to enable, diff sensitivity, and whether or not to allow public viewers), but we do not have to care about them for the purpose of this demo. You can always come back and tweak this later according to your project’s requirements.

2. Integrate with the Rails project

Now, let’s look at how to integrate Percy with our demo Rails project. Percy provides a comprehensive guide to do that here.

1. First, let’s export the PERCY_TOKEN provided to us in the Builds page into our environment variable.

export PERCY_TOKEN=<value>

2. Then, we will add percy-capybara into our Gemfile and run bundle install.

gem 'percy-capybara'

3. Next, let’s install @percy/agent via npm/Yarn.

yarn add --dev @percy/agent

That’s it! Now let’s look at adding Percy to our feature specs.

3. Percy in Feature Specs

Percy has to be integrated into feature specs (i.e. end-to-end tests) because it requires the app to be running in order for it to be able to take screenshots. Hence, it will not work in unit tests where the application context is mocked and chunks of code are tested in isolation.

First, we will check out the primary working branch main and take a look at the existing feature specs:

# spec/integration/document_spec.rb
require "rails_helper"

RSpec.feature "Add documents", js: true do
  before :each do
    User.create(email: 'user@example.com', password: 'password')

    visit "/documents/new"

    within("#new_user") do
      fill_in 'Email', with: 'user@example.com'
      fill_in 'Password', with: 'password'
    end

    click_button 'Log in'
  end

  scenario "User visits page to create new document" do
    expect(page).to have_text('Create new document')
  end

  scenario "User sees validation errors" do
    click_button 'Create'

    expect(page).to have_text("Title can't be blank")
    expect(page).to have_text("Body can't be blank")
    expect(page).to have_text("Body is too short (minimum is 10 characters)")
  end
end

The feature specs are pretty simple. /documents/new is a route that only registered users can access, so upon visiting the path, devise is going to ask the visitor to authenticate before they can access the page.

The first test case verifies that the user can see the Create new document page upon successfully signing in.
The second case verifies that the user will see validation errors if they do not fill in the required details for the new document.

Adding Percy into the mix

To add Percy, simply require "percy" at the top of the spec file and add Percy.snapshot(page, { name: '<screenshot description>' }) on the lines in which we want Percy to capture.

# spec/integration/document_spec.rb
require "rails_helper"
# Include Percy in our feature specs
require "percy"

RSpec.feature "Add documents", js: true do
  before :each do
    User.create(email: 'user@example.com', password: 'password')

    visit "/documents/new"

    within("#new_user") do
      fill_in 'Email', with: 'user@example.com'
      fill_in 'Password', with: 'password'
    end

    click_button 'Log in'
  end

  scenario "User visits page to create new document" do
    expect(page).to have_text('Create new document')
    # Screenshot when we're redirected to the create new document page
    Percy.snapshot(page, { name: 'Create document page' })
  end

  scenario "User sees validation errors" do
    click_button 'Create'

    expect(page).to have_text("Title can't be blank")
    expect(page).to have_text("Body can't be blank")
    expect(page).to have_text("Body is too short (minimum is 10 characters)")
    # Screenshot when we see the errors
    Percy.snapshot(page, { name: 'Create document page validation error' })
  end
end

That’s it! Easy enough, right? Next, let’s run the tests so that the screenshots are taken and sent to percy.io. To do this, we cannot run the usual bundle exec rspec. Instead, we will have to run Percy and pass rspec to it.

$ yarn percy exec -- rspec

Note: This is the command that you should use if you have continuous integration set up.

And we’re done here! Now, if we go to percy.io, we can see that a new build has been created for us. After a few minutes, we should see the screenshots of the app.

4. Introduce visual changes and see how percy.io compares

The last step we ran was on the primary working branch. Since we set this branch as the baseline and that the screenshots from this branch would be auto-approved, we are not going to be asked to verify anything on this build.

Therefore, to demonstrate the visual diff-ing feature of Percy, let’s create another branch highlight-create-button, and let’s make the Create Document button appear bigger as well as change the text to just say Create.

<%# app/views/documents/_form.html.erb %>

<%# ... %>

<%# Old button %>
<%#= form.submit class: 'button is-primary' %>

<%# New button %>
<%= form.submit "Create", class: 'button is-primary is-large' %>

Awesome! Now, let’s rerun yarn percy exec -- rspec and analyse the visual diff on percy.io.

Once percy.io is done processing the new screenshots, it will compare the screenshots against the baseline in the main branch. We will see this in our new build:

As you can see, Percy highlights any changed areas in red. This makes it easier for us to spot the differences. In this case, it is expected for the button to change, so we can just go ahead and approve the build with the green button at the top.

5. What about style regressions?

Let’s do one more demonstration. This time, let’s simulate a CSS change gone wrong:

Create another git branch called css-regression.

Add a text-indent: -5rem to the error messages to push the text out of its container. This is what it would look like:

Let’s run bundle exec rspec. We will get this output:

> bundle exec rspec
Capybara starting Puma...
* Version 5.3.2 , codename: Sweetnighter
* Min threads: 0, max threads: 4
* Listening on http://127.0.0.1:65318
..

Finished in 2.62 seconds (files took 1.3 seconds to load)
2 examples, 0 failures

As you can see, the tests were not able to catch this styling regression. This is because the error messages specified in the assertion still exist on the page, so the use case is not considered broken in the “eyes” of the regular feature specs.

Now, run yarn percy exec -- rspec to send the screenshots to percy.io to be processed.

Great, percy.io was able to catch the regression here in the visual diff! A reviewer can just mark the build as “Requested changes” and leave a comment in there to have it fixed.

6. Responsive design and cross-browser testing

Percy can also help test your app’s UI on different browsers — namely Edge, Firefox, and Chrome. By default, all three browsers are enabled. You do not need to do anything else.

It can be used to test against different screen sizes as well. You can just select the screen sizes that are relevant to you and instruct Percy to take screenshots at those screen sizes automatically. This is particularly helpful as testing on several screen size variants can be very time-consuming. With Percy, you do not have to pay attention to the screenshot variants that do not diverge from the baseline.

In order to specify screen sizes, just pass a list of screen sizes that you are interested in, like so:

Percy.snapshot(page, { name: 'Create document page', widths: [480, 768, 1024, 1366] })

Rerun yarn percy exec -- rspec. We can now see the different variants (browsers and screen sizes) of each scenario on the top-right corner of the screen.

That’s it! We have successfully demonstrated how Percy can help us verify expected UI changes and catch visual regressions.

Caveats

As helpful and as crucial as it is, visual regression testing is not without its caveats. One of the most common issues with visual regression testing is, in some cases, it can produce a huge amount of false positives. Major-but-intentional layout shifts and changes to shared elements may result in having to review a huge amount of screenshots in the project.

For example, let’s say you increase the height of the site header (which is a common element in all pages) by 30px. When Percy processes the screenshots, it will invalidate most of the screenshots in the project, because elements would have been shifted down by 30px as a result of the taller header. For large projects, reviewing each screenshot one-by-one can be a hassle, especially with the tens of permutations for each screenshot to cater different screen sizes and browsers. As a result, one would be tempted to just click “Approve build”, thinking all changed areas would just be elements being pushed down, but that may not necessarily be true for elements with position: absolute;; they might get hidden behind the now taller header, and this may cause visual regressions to still slip into production, which kind of defeats visual testing’s original purpose.

Other than that, dealing with external resources can also result in flaky builds (e.g. if a page has an iframe or links to an external image). There are a lot of ways in which an external resource can change, e.g. image quality, content, updated resource, etc., and because these resources are outside of our control, they may become a source of false positives and a nuisance to the reviewers.

One way to deal with this is to not screenshot whole pages. Instead, screenshot only the individual components that are relevant to each scenario. This way, layout shifts in other parts of the pages will not affect the build in major ways, and it also helps cut out the changes from external resources on the page. Unfortunately, Percy does not have the capability to do this yet.

Conclusion

So, there you go! I hope this article has given you a good introduction to visual regression testing, why should you have it, and how to get started with it. Hope it will benefit you and your team in pushing great web applications!

Other resources

Jamstack Conf Virtual 2020: Thoughts & Highlights

2020-06-16T00:00:00+00:00

Welcome to Jamstack Conf Virtual 2020

Last week I attended Jamstack Conf Virtual 2020. It had originally been slated to take place in London, UK but was later transformed into a virtual event in light of the COVID-19 pandemic. The conference began at 2pm London time (thankfully I double-checked this the night before!)—6am for those of us in the Pacific Time Zone.

Up early for #jamstackconf 😎☕️ pic.twitter.com/ydjvrHWCZH
— Greg Davidson (@syncopated) May 27, 2020

Before getting too much further I wanted to mention that if you are not familiar with the Jamstack, You can read more about it at jamstack.org.

To virtually participate in the conference we used an app called Hopin. I had not heard of it before but was impressed with how well it worked. There were over 3000 attendees from 130+ countries one of the times I checked. Phil Hawksworth was the Host/MC for the event and did a great job. There were virtual spaces for the stage, sessions, expo (vendors), and networking. If you opted to, the networking feature paired you with a random attendee for a video chat. I’m not sure what I expected going into it but I thought it was fun. I met a fellow developer from the Dominican Republic. The experience was very similar though more serendipitous than the hallway track or lunch line at an in-person conference.

Keynote

Matt Biilmann opened the conference with a keynote address about the challenges we face as a developer community trying to improve access to accurate, timely and locally relevant information to a global audience. Many billions of users with all kinds of devices and varying levels of connectivity. He moved on to share how Netlify is trying to enable developers to “build websites instead of infrastructure” and “ensure all the best practices become common practices” through features like git-based deployments, build plugins, and edge handlers (more on those later).

State of the Jamstack Survey results

Laurie Voss walked us through the results of the Jamstack Survey 2020. There were some interesting findings and surprises. Later on I read Laurie’s post (which Matt had mentioned in his talk) and found that very interesting as well.

Fireside chat with Harper Reed

Frances Berriman chatted with Harper Reed and asked him about his application of Jamstack principles from years ago when he led the technology team for Barack Obama’s election campaign. He described the need to “get far with very limited resources” and spoke about experimenting with serving HTML from Google App Engine and Amazon S3. Using pre-built HTML allowed them to scale very efficiently and he opted to use message queues rather than interacting with the database to keep things very quick for users.

Another benefit Harper noted was how quickly and easily new team members could be onboarded. Folks who knew HTML, CSS and JavaScript would be up to speed and productive in no time. He admitted it’s more complicated today 😀. Speed is another benefit—he just loves when he comes across a super-fast web site (often mostly static).

Lightning Launch: Netlify ⚡

David Calavera gave a demo of Netlify’s new Edge Handlers feature which lets developers add logic to their code at the edge (e.g. the CDN servers geographically closest to the user). He demonstrated how Edge Handlers make it possible to examine the headers of the request to tailor the response to that unique request. Check out the video of his talk to watch him live code an example. I believe Cloudflare Workers and Fastly’s Edge Compute are operating in a similar problem space. I plan to look into each of these offerings more thoroughly in future.

Lightning Launch: Prismic ⚡

Renaud Bressand from Prismic demoed Slicemachine—a new feature from Prismic which lets you combine nuxt/Vue components with content managed in Prismic. It looked like a very compelling way of enabling better collaboration between developers and content creators.

Lightning Launch: RedwoodJS ⚡

Tom Preston-Werner demoed his latest project RedwoodJS. I had heard Tom speak about this on a few podcasts recently and it was nice to see him demo it for us. It looks interesting and feels reminiscent of Rails. RedwoodJS simplifies wiring up your database to a GraphQL API (they use Prisma for this) and integrating it into a React application. Tom is also the creator of Jekyll—a Jamstack-style tool which has been around for many years. It was nice to see several speakers give him some recognition for his work on that project.

The COVID Tracking Project: 0 to 2M API requests in 3 months

Erin Kissane gave an inspiring talk about her work on The COVID Tracking Project. She described it as an “interim public data rescue project”. Erin and some friends, journalists and volunteers worked together to create the site. They started by scraping COVID data from each state’s web site and storing it in a Google Sheet. They used Gatsby, Contentful, and Sass modules and hosted the site on Netlify. Using the Jamstack approach allowed the site to remain performant and continue to be responsive under some huge traffic spikes. Over time, they iterated on the design and continue to improve the site daily. I highly recommend checking out the video of the talk when you get a chance.

Jamstack for emerging markets

Christian Nwamba described some of the challenges of building sites for users in Nigeria (low power devices, spotty connectivity, unreliable power). He shared that 55% of the most visited sites in Nigeria are global companies (Google, Facebook/Instagram, Netflix, Stack Overflow etc.). Christian reviewed a large, popular banking site in Nigeria and noted its many shortcomings.

To demonstrate how the bank might do better he built an app for transferring money between friends & family built in the Jamstack style and using serverless functions. The most interesting thing I picked up from this was his method of using serverless functions to protect the app secrets (API keys, etc.). The front end of the application did not need to concern itself with this—the serverless functions kept the secrets safe and acted as a proxy between the frontend and the backend APIs. Be sure to take a look at Christian’s code if you are interested.

Managing diabetes with Jamstack

Jamie Bradley taught us about diabetes and the Jamstack app he built to help himself and others manage it. He built HeySugar with Gatsby and Sanity, hosted it on Netlify. He’s making it easier for others to deploy their own instances as well.

Selling tickets without servers. Or frameworks. Or cookies.

Jan van Hellemond has volunteered for years at a very popular conference in Europe (Fronteers I think). In previous years tickets sold out in 6 minutes one year, and 30 seconds in another! Their ticket vendor was struggling to handle to the load and this caused them to oversell early bird tickets. Jan built a Jamstack site to sell their tickets and was very pleased with the performance. He used simple, single-purpose vanilla JavaScript components and simple, single-purpose API handlers (serverless functions).

Jan prerendered as much as possible and seeded a relational database with the tickets available for sale. As the tickets were sold, they were marked sold with a database update. Webhooks were used as customers stepped through the checkout flow. Jan joked about deploying to production on a Friday afternoon because of how safe and simple the deployment process was. There were no services to restart, etc. because “it’s just files”. It was cool to see a practical example and that Jan used the basic building blocks of the web (HTML, JavaScript, CSS, old school links) successfully without reaching for a large JavaScript framework.

The business side of the Jamstack

Ana Rossetto shared how her company has been having great success with the Jamstack. Previously, the agency had been building projects for clients with Drupal. She walked through a project she and the team built to encourage people to buy from small, locally-owned businesses. She was impressed with what they were able to create in a very short amount of time.

Build plugin authors’ session

After the main talks there were several sessions. In the Hopin app, I was able to peek into some of these and the presenters and attendees were chatting (both text chat and video). This was very much like the experience of peeking into conference rooms at a physical venue and choosing whether to stay and participate or move on. After some wandering I chose to attend a session with three Netlify build plugin authors.

Peter Müller built Subfont with a friend. He demonstrated how subsetting web fonts (i.e. only loading the characters & glyphs you really need) can dramatically improve frontend performance. He compared the WebPageTest results for Google Fonts with and without Subfont and Subfont was seconds faster! I have subset and locally hosted webfonts in several client projects here at End Point. It takes time and is a manual process. Peter’s plugin makes this excellent performance improvement relatively painless.

David Darnes demoed his build plugin to turn Ghost content into Markdown files. Very interesting and it seemed flexible enough to work with other tools as well.

Gleb Bahmutov presented the build plugin he created to run Cypress tests as part of your Netlify build process. It was amazing to see how simple it was (single devDependency and single line in the netlify.toml config file).

Videos from the conference

Netlify has already put all of the Jamstack Conf Virtual 2020 talks on YouTube so head over there and check those out if you’d like to. Thanks very much to the team at Netlify for organizing the conf, all of the speakers, vendors and attendees!

Winning with CSS Grid and Autoprefixer

2019-11-04T00:00:00+00:00

Photo by Stijn te Strake on Unsplash

Using CSS Grid Today

Support for CSS Grid is excellent (over 90% globally! 💯). I have been using it in a variety of client projects for the past few years with great success. The combination of CSS Grid and Flexbox has made layout on the web much simpler, more fun and less frustrating compared to the ~~hacks~~ techniques which were used for CSS layout in the past. Definitely give it a try if you haven’t already done so.

IE10 and IE11 support an earlier version of the CSS Grid spec and with help from Autoprefixer we can reap the benefits of CSS Grid in those old browsers with a little bit of extra work. I’ve long been a huge fan and happy user of Autoprefixer. It’s a PostCSS plugin that examines your CSS and augments it with vendor prefixes and alternative syntaxes. Although vendor prefixes (e.g. -webkit, -moz, -o, etc.) are much less common these days, there are a few still in use.

CSS Grid Basics

With CSS Grid the basic idea is to define the grid, i.e. the rows and columns that make it up, and then go about placing elements on the grid. Think of a website layout with a masthead, navigation, hero image, main content sidebar, and footer as an example. Your grid styles can specify where each of these elements should be displayed on the grid: how many rows or columns they span, etc. In addition to this method of explicitly placing elements on the grid, auto-placement places elements on the grid for you automatically.

Autoprefixer + CSS Grid

I recently learned how to use control comments in Autoprefixer to get fine-grained control over the way it operates on and enhances my CSS Grid styles. Rather than specifying a single (global) behavior via config options, control comments let you tell Autoprefixer how you would like it to process individual blocks of CSS code. For the scenario where I was explicitly placing elements on my grid I used the following control comment in my CSS file:

/* autoprefixer grid: no-autoplace */

This allowed me to lay out the elements and Autoprefixer generated the -ms-grid styles required to make my modern CSS Grid styles work in IE 10 and IE 11.

In another scenario I did want the auto-placement support and enabled it with the following control comment in a different block of the same CSS file:

/* autoprefixer grid: autoplace */

This was for a group of uniformly sized tile elements that I wanted to lay out in a grid that adapted as the viewport size varied. E.g.: from 4 tiles per row, to 3 tiles, to 2 and finally to 1 tile per row for the smallest viewports.

In both cases I was pleasantly surprised that my CSS Grid styles worked in modern browsers and also in IE 11 and 10! I added some fallback styles using flexbox for those browsers which do not yet support CSS Grid to ensure the content was accessible there as well.

Test Your Autoprefix’d Grid Styles

Please note the Autoprefixer docs warn its grid support may not work in all cases and must be tested. For my purposes this worked you great but make sure to test because your mileage may vary.

Learning More

If you’d like to learn more about CSS Grid I would recommend checking out Jen Simmons’ CSS Grid Basics series on YouTube and the Grid by Example site by Rachel Andrew. To learn more about Autoprefixer, check out the docs at GitHub or you can try it out interactively.

React: Style Tips

2019-09-28T00:00:00+00:00

Photo by Harpal Singh on Unsplash

I’ve worked on a couple of large React projects over the last few years. In my experience, one of the trickiest parts of getting a React project up and running is figuring out how you want to visually style your application in the browser, so I’ll share in this post some of the ways I’ve styled my projects.

CSS Modules

Libraries like Material-UI (which I’ll discuss next) do a lot of the work of styling for you. However, sometimes you’ll still need to define styles unique to your project, and the most common way is with CSS.

For projects created with create-react-app, any CSS you include in a React project isn’t scoped. This means that if you define a class tall in one component that has a height of 40 pixels and a class tall in another component with a height of 80 pixels, one of your rules will overwrite the other—whichever makes it into the compiled CSS file last. However, webpack allows you to use CSS modules, which restrict your CSS rules to components that explicitly import them. It took me a long time to figure out how to use them due to lack of relevant documentation, but eventually I discovered a very easy way to do it.

If your file structure looks like this:

- app/
  |-App.js
  |-App.css

It’s as simple as renaming your CSS file like this:

- app/
  |-App.js
  |-App.module.css

Using the suffix .module.css tells create-react-app that the rules within should be scoped only for where they’re imported. They can be used like other styles by importing and passing the classes like this:

import styles from './App.module.css';

export default function Component(props) {
  return <div className={styles.myClass} />;
}

Material-UI and similar libraries

There are many different design philosophies for web, but probably the most popular is Google’s Material Design. Material Design lays out some rules that help keep a user interface uncluttered, intuitive, and pleasant to use. However, jumping into the guidelines on Google’s website can be very intimidating. In addition, manually defining CSS for your web application is a lot of work. There are several different libraries that offer solutions to this, my favorite being Material-UI. Material-UI provides a set of components that you can reuse to put your application together.

Here’s a simple example showing different styles of text fields:

import TextField from '@material-ui/core/TextField';

export default function TextFieldDemo(props) {
  render() {
    return (
      <form>
        <TextField
          label="Name"
          value={values.name}
          onChange={handleChange('name')}
        />
        <TextField
          label="Name"
          value={values.name}
          onChange={handleChange('name')}
          variant="outlined"
        />
        <TextField
          label="Name"
          value={values.name}
          onChange={handleChange('name')}
          variant="filled"
        />
      </form>
    );
  }
}

And here’s what that looks like:

Vanilla CSS with Material-UI

It’s also important to note that Material-UI’s preferred way of defining additional styles is using CSSinJS rather than plain CSS. Given the following CSS:

.button {
  margin: --theme-spacing
}

.input {
  display: none
}

You would instead use the following JSS object:

{
  button: {
    margin: theme.spacing(1),
  },
  input: {
    display: 'none',
  },
}

Using the styles in your project is mostly the same after that, but I won’t go into detail about that here. CSSinJS has some advantages (which you can read about in the Material-UI documentation as well as on the CSSinJS website), but I prefer vanilla CSS. It’s not immediately obvious from their site, but you can still use vanilla CSS as well as CSS modules with Material-UI, and setting it up is pretty simple.

First, you need to make sure that your CSS is injected before styles included with Material-UI. There are two steps to making this work: first, you define an injection point for your CSS by adding an element to your index.html at the injection point:

<head>
  <noscript id="jss-insertion-point" />
</head>

Then, you wrap the entire application in the StylesProvider component with a prop named injectFirst:

import { StylesProvider } from '@material-ui/styles';

class App extends Component {
  render() {
    return (
      <StylesProvider injectFirst>...</StylesProvider>
    );
  }
}

Now, your imported CSS will take predence over the styles provided by Material-UI, so you can still use vanilla CSS if you like!

Conclusion

These methods have worked great for me, but they’re certainly not the only way to do things. Leave a comment if you’ve found a library you like, or have an approach you recommend!

CSSConf US 2016 — Day One

2016-10-07T00:00:00+00:00

Boston Common

I attended CSSConf US 2016 last week in Boston, MA. Having been to the 2013 and 2014 (part one, part two) events in Florida then missing it in NYC last year, I was looking forward to seeing what it would be like in a new location. It was fun to see some familiar faces including Eiríkur (congrats on organizing a very successful JSConf Iceland conference earlier this year!) and to meet many new folks in the CSS community. Claudina Sarahe was our MC for two days of talks and she did a great job. After each talk she took a few minutes to interview the speaker—asking them questions from the audience and some of her own. The chats were candid and interesting on their own and gave the next speaker time to set up.

Below are my notes and some observations on the talks from Day One. Be sure to check out the videos, slides and transcripts at the CSSConf site. Many of the videos are there now and they are adding more as they become available.

Sarah Drasner — Creativity in Programming for Fun and Profit

Sarah started off the day with an inspiring keynote about creativity. She explained how writing code is a creative endeavor by showing us several drastically different solutions to the classic FizzBuzz problem in computer science. She shared some stats and survey results which documented excellent, tangible results companies saw when they invested in R&D and fostering creativity. Sarah demoed some really cool creative projects she had built—many of them just for fun. She encouraged us to work on creative projects on the side to enter into flow while designing, coding and building things. Time devoted to purely creative and fun projects can makes less interesting day-to-day tasks more bearable. It was amazing to see some of the animation work she’s done and her passion for art and programming was palpable throughout the talk.

Brian Jordan — No Bugs in Sight: Continuous Visual Tesing at Code.org

Brian works for code.org which is the organization behind the Hour of Code and other initiatives promoting computer science education in schools. His work on apps that teach kids to code is used on a vast variety of hardware (tablets, old underpowered school computers etc.). Testing became a challenge early for them so Brian began to incorporate testing with Selenium into their development workflow. They use Cucumber to write their tests. They use Sauce Labs to run the tests and circleCI to integrate it with their source code control system. When code is committed, the tests are run which ensures broken code does not get merged in. They also use applitools eyes for visual diffing which looked very interesting. They keep a wiki of the larger and more interesting issues that it catches to help everyone remember them (and sometimes recall why they still need to keep a particular test). Brian showed us several screenshots of visual problems caught by their system including one that was a single pixel showing up in a strange (unwanted) location on the screen.

Jessica Lord — Nativize is the new Normalize

Jessica works at GitHub on the Electron project. Her talk was about Electron and how you can use it to build cross-platform (Windows/Linux/Mac) desktop apps using web technologies. Electron is used to power Atom, Slack and many other interesting apps. It uses V8 as its JavaScript runtime which allows you to use Node.js in your apps. Chromium is used for the all the DOM and rendering bits. She showed off the Electron example app and talked about some tips and tricks to building apps with Electron. Jessica stressed that you have to think about apps differently than web sites. You want your app to feel like an app not a website. She pointed out several good resources for learning more about it. Electron can also be used to build menubar apps for OS X.

Jen Kramer — CSS4 Grid: True Layout Finally Arrives

Jen is a professor at Harvard teaching web development. She talked about CSS grid and how it will make laying out sites much better than the current hacks techniques we have been using up to this point (tables, floats, flexbox). She explained how flexbox was designed to only work in a single dimension (grids need to work in two for both rows & columns) and showed some example layouts built with CSS grid. Jen’s examples showed how many CSS design challenges (e.g.: equal height columns) are easily solved with grid. The only thing holding it back is browser support. Today it’s available in Chrome and Firefox behind a configuration flag. Jen was really funny and engaging and drew everyone in with her presentation skills and passion for web development in general (grid too!).

Pete Hunt — Component-Based Style Reuse

Pete talked about React and how it can be used to create components (e.g.: a piece of UI that can be re-used in different contexts). He shared how OOCSS was a foundational concept and inspiration to him and walked through the process of building a React component that implemented an OOCSS “media block” component. Having previously worked at FaceBook, Pete discussed the issues that arise when developing many UI components at scale—especially CSS class conflicts and the resulting style pollution. Pete used jsxstyle (developed by his current team at Smyte) in his React component to keep the styles scoped to the component and avoid using descendent selectors. It was very interesting talk and I recommend watching the video of Pete’s talk to get the full effect.

Keith J. Grant — Stop Thinking in Pixels

Keith works for the company behind the NYSE website. He thoroughly explained how to effectively use em and rem units for font-size and other properties and how he recommends avoiding using pixels for font sizes altogether. Keith showed many examples using rem to set the font size for a container element and then use ems for all of its children. This had the benefit of flexibility and made is possible to adjust the sizes of all of the child elements by simply changing the size on the parent/container. He covered several formulas which can be used to determine the em values you will need for approximate pixel sizes. He shared type-scale.com as a web app that can help with these calculations. Once you understand the formulas, you can add mixins in Sass to perform the calculations for you. Near the end of his talk Keith showed us an example using rems for the parent, ems for the child elements and then combining calc() with viewport units (vh, vw) to smoothly scale the size of a component as the viewport changes. This was really neat to see and avoided the clunky switch between sizes that happens when the viewport changes between media queries. With the technique Keith demonstrated, the scaling was completely fluid—very impressive. Keith wrapped up by explaining that these techniques require a little work up front and often educating other developers on the team but the benefits are immediate.

Will Boyd — Silky Smooth Animation with CSS

Will talked about the deep dive he took into how browsers handle rendering and animation. He demoed how we can look into the process for our own performance debugging with tools like Chrome DevTools. To illustrate some of the performance wins Will had discovered in his own projects, he loaded up an animation he’d built for the talk and compared the performance before and after he used CSS properties that could be handled by the GPU. The performance improvement using transform, filter and opacity (all hardware-accelerated and rendered by the GPU) was drastic and impressive.

Lea Verou — CSS Variables var(–subtitle);

Lea’s talk was about CSS variables (aka custom properties). I admit to being surprised when I looked it up recently and found that they were already quite widely supported. The syntax looks little odd at first but it made sense when Lea explained it was intentional that they look different than preprocessor variables. I found it interesting that CSS variables are expected to be used alongside preprocessor variables rather than replacing them. Lea explained how they work, how they can be accessed by JavaScript and demonstrated several things CSS variables can do that preprocessor variables can not! Make sure to check out the video of her talk when you get the chance.

Zurb Foundation 5: Applying Styles Conditionally Based on Viewport Size

2016-02-08T00:00:00+00:00

The Zurb Foundation 5 front-end framework provides many convenient features such as the ability to control the visibility of HTML elements for different browser window sizes using CSS classes. Foundation CSS classes like “show-for-small-only” and “hide-for-large-up” (full list at https://get.foundation/sites/docs-v5/components/visibility.html) make it easy to add mobile-specific content to your page or prevent certain page elements from being displayed on mobile devices.

Having an easy way to show/hide elements based on viewport size is nice, but what if you want to style an element differently based on the size of the browser that’s viewing the page? Foundation has you covered there, too, though the method is less obvious. It’s possible to use Foundation’s media query SCSS variables when writing your own custom styles in order to apply different styling rules for different viewport sizes.

For example, if you have an element that you want to offset with a margin in a large window but be flush with the left edge of a small window, you can use the Foundation media query variables to apply a styling override that’s specific to small windows:

#element {
    margin-left: 100px;

    @media #{$small-only} {
        margin-left: 0;
    }
}

This will apply a specific set of styling to the element for small viewports and a different set for medium and larger viewports (with the definitions for “small”, “medium”, etc. corresponding to the same values used by Foundation’s visibility classes like “show-for-small-only” which were mentioned at the start of this post).

It wasn’t immediately obvious to me how to apply conditional styling using Foundation’s own definitions of small, medium, etc. viewport sizes but luckily the variable definitions provided by the SCSS framework make it easy to do so.

Full Screen Gallery with Supersized and video slides

2016-01-26T00:00:00+00:00

I was recently looking to build a full screen image and video gallery for our client Mission Blue. Something similar to the Google Maps interface you can see in the screenshot below:

After scouring the Internet to find a suitable jQuery plugin I finally decided on Supersized, Full screen background slideshow plugin for jQuery.

After downloading the library, include it on the page:

<link href="/wp-content/plugins/wp-supersized/theme/supersized.shutter.css?ver=4.2.2" id="supersized_theme_css-css" media="all" rel="stylesheet" type="text/css"></link>
<script src="/wp-includes/js/jquery/ui/effect.min.js?ver=1.11.4" type="text/javascript"></script>
<script src="/wp-content/plugins/wp-supersized/js/jquery.easing.min.js?ver=1.3" type="text/javascript"></script>
<script src="/wp-content/plugins/wp-supersized/js/jquery.easing.compatibility.js?ver=1.0" type="text/javascript"></script>
<script src="/wp-content/plugins/wp-supersized/js/jquery.animate-enhanced.min.js?ver=0.75" type="text/javascript"></script>
<script type='text/javascript' src='/wp-content/plugins/wp-supersized/js/supersized.3.2.7.min.js?ver=3.2.7'></script>

Basic functionality

Let’s create a variable that will hold all the images in the slideshow:

var images = [];
images.push({
  type: 'IMAGE',
  image: 'img1.jpg',
  title: 'Image 1',
  thumb: 'img1_thumb.jpg',
  url: 'https://www.endpointdev.com'
});
images.push({
  type: 'YOUTUBE',
  image: 'screenshot1.jpg',
  title: 'YouTube slide',
  videoid: 'abc12345678',
  thumb: 'screenshot1_thumb.jpg',
  url: 'https://www.youtube.com/watch?v=abc12345678'
});

Let’s initialize Supersized:

jQuery.supersized({
  slideshow: 1,
  autoplay: 0,
  min_width: 0,
  min_height: 0,
  vertical_center: 1,
  horizontal_center: 1,
  fit_always: 0,
  fit_portrait: 1,
  fit_landscape: 0,
  slide_links: 'blank',
  thumb_links: 1,
  thumbnail_navigation: 1,
  slides: images,
  mouse_scrub: 0
});

<div id="thumb-tray" class="load-item">
  <div id="thumb-back"></div>
  <div id="thumb-forward"></div>
</div>
<div id="slidecaption"></div>

Customizing the screen image size

I didn’t want to have the full screen image as it was a little overwhelming for the user. I wanted the black bars just like in the Google interface. Supersized allows for easy customization. This CSS did the trick:

#supersized, #supersized li {
  width: 70% !important;
  left: 0 !important;
  right: 0 !important;
  top: 1px !important;
  margin:auto;
}

Introducing video (YouTube) slides

First, I added the Youtube API:

<script type="text/javascript" src="https://www.youtube.com/iframe_api"></script>

Then I added a couple of CSS styles:

#supersized .player {
  margin: auto;
  display: block;
}

Finally, I went into the Supersized library source and modified it. To allow for the video slides to appear, I added the new condition and the slide type ‘YOUTUBE’

base._renderSlide = function(loadPrev, options) {
  var linkTarget = base.options.new_window ? ' target="_blank"' : '';
  var imageLink = (base.options.slides[loadPrev].url) ? "href='" + base.options.slides[loadPrev].url + "'" : "";
  var slidePrev = base.el + ' li:eq(' + loadPrev + ')';
  var imgPrev = $('<img src="' + base.options.slides[loadPrev].image + '"/>');

  if (base.options.slides[loadPrev].type == 'YOUTUBE') {
    imgPrev.load(function () {
      var video = $('<div class="player" id="player'+ base.options.slides[loadPrev].videoid + '"></div>');
      video.appendTo(slidePrev);
      var player = new YT.Player('player' + base.options.slides[loadPrev].videoid, {
        height: 390,
        width: 640,
        videoId: base.options.slides[loadPrev].videoid
      });
    });// End Load
  }
  else {
    imgPrev.appendTo(slidePrev).wrap('<a ' + imageLink + linkTarget + '></a>').parent().parent().addClass('image-loading ' + options['class']);

    imgPrev.load(function () {
      $(this).data('origWidth', $(this).width()).data('origHeight', $(this).height());
      base.resizeNow();// Resize background image
    });// End Load
  }
};

Final Result

This is how gallery looks with the customizations:

This is what a video slide looks like:

Hope you found this writeup useful!

Old Dog & New Tricks — Giving Interchange a New Look with Bootstrap

2015-09-02T00:00:00+00:00

Introduction

So your Interchange based website looks like it walked out of a disco… but you spent a fortune getting the back end working with all those custom applications…. what to do?

Interchange is currently being used in numerous very complex implementations. Trying to adapt another platform to replace Interchange is a formidable task, and in many cases the “problem” that users are trying to “solve” by replacing Interchange, can be remedied by a relatively simple face lift to the front end. One of the main attractions to Interchange in the past was its ability to scale from a small mom & pop eCommerce application, to a mid level support system for a larger company and its related back end systems. Once the connection to those back end systems has been created, and for as long as you use those related systems, Interchange will continue to be the most economic choice for the job. But that leaves the front end, the one that your customers see and use (with their phones and tablets) that becomes the most immediate target for “modernization”.

Granted, there are new and alternate ways of accessing and presenting data and views to users, but many of those alternatives are also accessible and inter-operable with Interchange. So while there are several topics that can be investigated at length, we will focus first on a popular front end framework that can help Interchange present a modern responsive theme to the end users. That framework is Bootstrap. Bootstrap is a good basic start for breathing new life into your Interchange application. Bootstrap uses a reasonably generic approach to HTML, CSS, and JavaScript frameworking. This blends nicely with the Interchange application approach: providing a basic, repeatable, broad based and well supported foundation that can then be crafted into whatever the developer and their client may need.

My intent in this post, is to give you links to the tools available to implement Bootstrap into your Interchange application, and in subsequent posts explain our development process which may help you in how you use the tools. Like any development, there are many ways to accomplish various tasks, and knowing why certain things were done, can help.

Alternatively, you may simply want to just download the “strap” catalog, and get started. At the time of this writing, Josh Lavin has been reviewing and refining the package, and the most recent version can be found at his Github account: Bootstrap template for Interchange. It will soon become the standard catalog template in Interchange. So, if you are not really interested in why and how this template was developed, feel free to go to the git repository in the link, clone a copy and get busy! The README is very informative, and if you are an Interchange developer you probably won’t have much trouble implementing this.

If you are interested in some of the major changes that we made to the old “standard” templating approach, and how you can apply those changes to an existing catalog without having to start from scratch, stay tuned in for my next post.

Angular Responsive Layout Directive

2015-01-13T00:00:00+00:00

To all of you window.onResize aficionados, I dedicate this blog post because today we will be doing a lot of dynamic resizing in JavaScript. All of it will be done completely and effortlessly with my one-page long Angular directive.

Why do I need to attach an expensive onResize handler to my already overloaded page, you ask. The answer is very simple. Our app layout is pixel-perfect. Each element has the predefined width and margins. Yet, the app needs to look good on all kind of devices, from regular PC to tablet to iPhone. That’s why I created the following Angular directive in /scripts/directives/tsResize.js:

angular.module('angularApp')
.directive('tsResize', function($window) {
 return function(scope, element) {
   var w = angular.element($window);
   scope.getWindowDimensions = function () {
     return {
       'h': $window.innerHeight,
       'w': $window.innerWidth
     };
   };
   scope.$watch(scope.getWindowDimensions,
              function (newValue, oldValue) {
     scope.windowHeight = newValue.h;
     scope.windowWidth = newValue.w;

     scope.mainContainerStyle = function () {
       if (newValue.w > 890) {
         return {};
       } else {
         val = newValue.w/890;
         return {
           '-webkit-transform': 'scale(' + val + ')',
           '-o-transform': 'scale(' + val + ')',
           '-ms-transform': 'scale(' + val + ')',
           'transform': 'scale(' + val + ')',
           'transform-origin': 'left -10px',
           '-webkit-transform-origin': 'left -10px'
         };
       }
     };

     scope.topBarStyle = function () {
       if (newValue.w > 890) {
         return {};
       } else {
         val = newValue.w/890;
         return {
           '-webkit-transform': 'scale(' + val + ')',
           '-o-transform': 'scale(' + val + ')',
           '-ms-transform': 'scale(' + val + ')',
           'transform': 'scale(' + val + ')',
           'transform-origin': '0 2px 0',
           '-webkit-transform-origin': '0 2px 0'
         };
       }
     };
    }, true);

   w.bind('resize', function () {
     scope.$apply();
   });
  }
})

As you can see all the magic is done with transform:scale CSS attribute on the two of my main page components: the navigation and the contents container.

They styles are cross-browser.

return {
  '-webkit-transform': 'scale(' + val + ')',
  '-o-transform': 'scale(' + val + ')',
  '-ms-transform': 'scale(' + val + ')',
  'transform': 'scale(' + val + ')'
};

It’s important to set transform-origin, or the elements will be weirdly positioned on the page.

return {
  'transform-origin': '0 top',
  '-webkit-transform-origin': '0 top'
};

The style calculations are attached to the changes of window dimensions.

scope.getWindowDimensions = function () {
  return {
    'h': $window.innerHeight,
    'w': $window.innerWidth
  };
};
scope.$watch(scope.getWindowDimensions,
             function (newValue, oldValue) {
...
});

Few other things. My layout was sliced to the fixed width of 890px, that’s why I took 890 as the pivotal point of my scale ratio formula. You should take the default width of the layout as the base of your calculation.

if (newValue.w > 890) {
  return {};
} else {
  val = newValue.w/890;
  return {
    '-webkit-transform': 'scale(' + val + ')',
  }
});

With the directive in place it’s time to plug it in:

<script src="scripts/directives/tsResize.js"></script>
  <nav ng-style="topBarStyle()" ts-resize=""></nav>
  <div ng-style="mainContainerStyle()" ng-view="" ts-resize=""></div>

Be sure to use style “display:block” or “display:inline-block” and “position:relative” for all the inside components of the scaled elements with the default display. Otherwise they do not obey the scaling enforcement and grow way too long prompting a scrollbar.

<div id="main-container"><div id="inner-block" style="position:relative; display:inline-block"></div></div>

It all worked nicely and I was able to enjoy the smoothly resizing layout.

Simplifying mobile development with Ionic Framework

2014-11-06T00:00:00+00:00

My high school math teacher used to say that mathematicians are the laziest people on Earth. Why? Because they always look for clever ways to simplify their work.

If you stop and think about it, all that technology is, is just simplification. It’s taking the infinitely complex world and turning it into something sterile and simple. It’s all about producing simple models with a limited number of elements and processes.

Today I’d like to walk you through creation of a mobile app that could be used on iOS, Android or Windows Phone. We’ll use a very cool set of technologies that allow us to switch from using multiple languages and frameworks (Objective-C for iOS, Java for Android and C# for Windows Phone) to just using HTML, CSS and JavaScript.

Let’s start turning complex into simple!

PhoneGap and Ionic Framework

Creating the project

In order to be able to start playing along, you need to get yourself a set of toys. Assuming that you’ve got NodeJS and Npm installed already, all you have to do is:

$ npm install -g cordova ionic

Now you should be able to create the project’s scaffold. We’ll be creating a simple app that will list all the latest cartoons from the xkcd blog. Let’s call it Cartoonic.

Ionic comes with a handy tool called ‘ionic’. It allows you to create a new project as well as perform some automated project-structure-management tasks. The project creation task accepts a ‘skeleton’ name that drives an initial layout of the app. Possible options are: ‘blank’, ‘tabs’ and ‘sidemenu’.

We’ll be creating an app from scratch so:

$ ionic start Cartoonic blank

The framework gives you an option of whether you want to use Sass or just plain old Css. To turn Sass on for the project run:

$ cd Cartoonic && ionic setup sass

All went well, but now let’s see if it works well. For this, Ionic gives you an ability to test your app in the browser, as if it were a screen of your mobile device. To run the app in the browser now:

$ ionic serve

Working with the app layout

We need to let all users know what a cool name we’ve chosen for our app. The default one provided by the scaffold wouldn’t work well. Also we’d like the color of the header to be blue instead of the default white.

In order to do so you can take a look at the CSS documentation for different aspects of the UI:

https://ionicframework.com/docs/components/#header

--- a/www/index.html
+++ b/www/index.html
@@ -21,8 +21,8 @@
     <ion-pane>
-      <ion-header-bar class="bar-stable">
-        <h1 class="title">Ionic Blank Starter</h1>
+      <ion-header-bar class="bar-positive">
+        <h1 class="title">Cartoonic</h1>
       </ion-header-bar>
       <ion-content>
       </ion-content>

So far so good, now let’s play with the list of cartoons:

--- a/scss/ionic.app.scss
+++ b/scss/ionic.app.scss
+.cartoon {
+  text-align: center;
+  box-shadow: 1px 1px 2px rgba(0, 0, 0, 0.2);
+  width: 96%;
+  margin-left: 2%;
+  margin-top: 2%;
+  margin-bottom: 2%;
+
+  img {
+    width: 90%;
+  }
+}

--- a/www/index.html
+++ b/www/index.html
+        <ion-list>
+          <ion-item class="item-divider">Where Do Birds Go</ion-item>
+          <ion-item class="cartoon">
+            <img src="http://imgs.xkcd.com/comics/where_do_birds_go.png" alt="">
+          </ion-item>
+          <ion-item class="item-divider">Lightsaber</ion-item>
+          <ion-item class="cartoon">
+            <img src="http://imgs.xkcd.com/comics/lightsaber.png" alt="">
+          </ion-item>
+        </ion-list>
       </ion-content>

Alright, we’ve got the list that’s looking quite nice. The data behind is static, but for now we just wanted to make sure the look&feel is good.

Using AngularJS to manage the app

Ionic is built around the fantastic AngularJS framework. That’s our means of developing the logic behind. We need to make the list of cartoons use real data from the Xckd blog RSS feed. We also need to enable tapping on images to see the picture in the browser (so it can be zoomed in).

Let’s start with making the UI use dynamically bound data that we can operate on with JavaScript. In order to do so, we need to add a controller for our view. We also need to specify the data binding between the markup we’ve created previously and the variable in the controller that we intend to use as our data store.

--- a/www/index.html
+++ b/www/index.html
     <script src="js/app.js"></script>
+    <script src="js/controllers.js"></script>
   </head>
-  <body ng-app="starter">
+  <body ng-app="starter" ng-controller="CartoonsCtrl">

(...)

       <ion-content>
         <ion-list>
-          <ion-item class="item-divider">Where Do Birds Go</ion-item>
-          <ion-item class="cartoon">
-            <img src="http://imgs.xkcd.com/comics/where_do_birds_go.png" alt="">
-          </ion-item>
-          <ion-item class="item-divider">Lightsaber</ion-item>
-          <ion-item class="cartoon">
-            <img src="http://imgs.xkcd.com/comics/lightsaber.png" alt="">
+          <ion-item class="item-divider" ng-repeat-start="cartoon in cartoons">{{ cartoon.title }}</ion-item>
+          <ion-item class="cartoon" ng-repeat-end>
+            <img ng-src="{{ cartoon.href }}" alt="">
           </ion-item>
         </ion-list>
       </ion-content>

--- a/www/js/app.js
+++ b/www/js/app.js
-angular.module('starter', ['ionic'])
+angular.module('starter', ['ionic', 'starter.controllers'])

--- /dev/null
+++ b/www/js/controllers.js
+angular.module('starter.controllers', [])
+
+.controller('CartoonsCtrl', function($scope) {
+  $scope.cartoons = [
+    {
+      href: "http://imgs.xkcd.com/comics/where_do_birds_go.png",
+      id: 1434,
+      title: "Where Do Birds Go"
+    },
+    {
+      href: "http://imgs.xkcd.com/comics/lightsaber.png",
+      id: 1433,
+      title: "Lightsaber"
+    }
+  ];
+});

You can notice that “ng-controller” directive has been added to the body element. It points at the newly created controller, which we’re loading with a script tag and making available to the rest of the app by including its module (starter.controllers) in the ‘starter’ module’s dependencies list.

Let’s implement opening the picture upon the tap:

--- a/www/index.html
+++ b/www/index.html
       <ion-content>
         <ion-list>
           <ion-item class="item-divider" ng-repeat-start="cartoon in cartoons">{{ cartoon.title }}</ion-item>
-          <ion-item class="cartoon" ng-repeat-end>
+          <ion-item class="cartoon" ng-repeat-end ng-click="openCartoon(cartoon)">
             <img ng-src="{{ cartoon.href }}" alt="">
           </ion-item>
         </ion-list>

--- a/www/js/controllers.js
+++ b/www/js/controllers.js
@@ -13,4 +13,8 @@ angular.module('starter.controllers', [])
       title: "Lightsaber"
     }
   ];
+
+  $scope.openCartoon = function(cartoon) {
+    window.open(cartoon.href, '_blank', 'location=no');
+  };
 });

That was simple wasn’t it? We’ve just added the ng-click directive making the click/tap event bound to the openCartoon function from the scope. This function in turn is using window.open passing ‘_blank’ as target. Et voilà!

Now, let’s implement loading images from the real feed:

--- a/www/index.html
+++ b/www/index.html
     <script src="cordova.js"></script>
+    <script type="text/javascript" src="https://www.google.com/jsapi"></script>
+    <script type="text/javascript">
+      google.load("feeds", "1");
+    </script>

     <!-- your app's js -->
     <script src="js/app.js"></script>
     <script src="js/controllers.js"></script>
+    <script src="js/services.js"></script>
   </head>
   <body ng-app="starter" ng-controller="CartoonsCtrl">

--- a/www/js/app.js
+++ b/www/js/app.js
-angular.module('starter', ['ionic', 'starter.controllers'])
+angular.module('starter', ['ionic', 'starter.controllers', 'starter.services'])

--- a/www/js/controllers.js
+++ b/www/js/controllers.js
-angular.module('starter.controllers', [])
+angular.module('starter.controllers', ['starter.services'])

-.controller('CartoonsCtrl', function($scope) {
-  $scope.cartoons = [
-    {
-      href: "http://imgs.xkcd.com/comics/where_do_birds_go.png",
-      id: 1434,
-      title: "Where Do Birds Go"
-    },
-    {
-      href: "http://imgs.xkcd.com/comics/lightsaber.png",
-      id: 1433,
-      title: "Lightsaber"
-    }
-  ];
+.controller('CartoonsCtrl', function($scope, cartoons) {
+  $scope.cartoons = [];

   $scope.openCartoon = function(cartoon) {
     window.open(cartoon.href, '_blank', 'location=no');
   };
+
+  $scope.$watch(function() {
+    return cartoons.list;
+  }, function(list) {
+    $scope.cartoons = list;
+  });
 });

--- /dev/null
+++ b/www/js/services.js
@@ -0,0 +1,26 @@
+angular.module('starter.services', [])
+
+.factory('cartoons', function($rootScope) {
+  var self = {
+    list: [],
+    url: "http://xkcd.com/rss.xml",
+
+    fetch: function() {
+      var feed = new google.feeds.Feed(self.url);
+      feed.load(function(result) {
+        $rootScope.$apply(function() {
+          if(result.status.code == 200) {
+            self.list = result.feed.entries.map(function(entry) {
+              return {
+                href: entry.content.match(/src="[^"]*/g)[0].substring(5, 100),
+                title: entry.title
+              }
+            });
+          }
+        });
+      });
+    }
+  };
+  self.fetch();
+  return self;
+});

Okay, a couple of comments here. You may wonder why have we loaded Google APIs? That’s because if we were to try to load the xml that comes from the blog’s feed, we would inevitably fail because of the “Same Origin Policy”. Basically, the Ajax request would not complete successfully and there’s nothing we can do locally about it.

Luckily, Google has created a service we can use as a middleman between our in-browser JavaScript code and blog’s web server. Long story made short: when you load the feed with Google’s Feed API - the data’s there and it’s also already parsed.

We’re also adding a custom service here. The service fetches the entries upon its initialization. And because the controller’s depending on this service - we’re guaranteed to get the data as soon as the controller is initialized. The controller is also using the $watch function to make sure it has the most recent copy of the entries list.

References:

CSS table-cells ::before and ::after

2014-11-05T00:00:00+00:00

When laying out HTML forms, instead of using a table (re: tables-are-only-for-tabular-data et al), I’ve had good results making use of the table family of values for the CSS display property. I find it a reliable way to ensure items line up in a wide range of situations, a change in the size of labels or a resize of the browser’s window for example.

Something simple like the following has worked well for me on several occasions:

.table {
  display: table;
}
.table>* {
  display: table-row;
}
.table>*>* {
  display: table-cell;
}

Occasionally though, I’ve wanted to leave a column empty for one reason or another. To accomplish this I found myself including empty HTML tags like:

<form class="table">
  <div>
    <div>A Cell</div>
    <div>A Cell</div>
  </div>
  <div>
    <div></div>
    <div>A Cell</div>
  </div>
</form>

The empty elements function well enough but they feel a little out of place. Recently I came up with a solution I like better. By using the CSS ::after and ::before selectors, you can insert an arbitrary element that can take the place of a missing cell. The following CSS rule can be used to replace the empty div above.

.table>*:nth-child(2)::before {
  content: " ";
  display: table-cell;
}

The nth-child(2) selector can be tailored to your given situation. You could replace it with something like a specific CSS class that you assign to the rows that you want to include empty columns.

Making use of CSS selectors instead of extra HTML elements can help you respect the separation of your document content from your document presentation. If at a later date, you decide you want to switch to a layout that doesn’t resemble a table, you can simply update the CSS rules to achieve a different look.

Laziness is a virtue

2014-06-23T00:00:00+00:00

Laziness is a virtue. Blessed Saint Larry told me so. And yet I am of little faith …

Here I was, banging my head on the keyboard, trying to solve a vertical alignment issue. (The following is a bit simplified for presentation here.)

<td>
<ul class="floaty">
<li> Item 1</li>
<li> Item 2</li>
</ul>
<div class="sticky">
blah blah blah
</div>
</td>

The <ul> element was supposed to float to the right of the cell, and its individual <li> elements also floated, so that the list would fill up from right to left as more items were added:

One item:

Two items:

Three items:

etc., while the “sticky” div was supposed to stay on the left. The challenge was when the div got too tall, or the number of list items caused it to wrap around to a new row; the vertical alignment to keep everything nice and centered is probably achievable in CSS, but I decided to be lazy:

<td style="vertical-align: middle">
<div class="sticky">
blah blah blah
</div>
</td>
<td style="vertical-align: middle">
<ul class="floaty">
<li> Item 1</li>
<li> Item 2</li>
</ul>
</td>

Duh. Seriously. Table cells do a bang-up job of vertical alignment under the worst of conditions. And I’m already in the middle of a table, so the work here was just a matter of adding the appropriate “colspans” elsewhere to account for my column’s bifurcation.

P.S.: I love the word “bifurcate” and work it in to conversation when I can.

CSS Conf US 2014 — Part Two

2014-06-04T00:00:00+00:00

More Thoughts on Getting Vertical, Testing and Icon Fonts

Without further ado I’ve written up another batch of my notes about three more great talks at CSS Conf US in Amelia Island, Florida last week.

Antoine Butler — Embrace the Vertical

Antoine shared his observation that vertical media queries are available to CSS developers but not often used. With the vast array of devices accessing the web today vertical media queries can be a useful tool to adapt your content effectively. Antoine walked us through a couple examples of how he applied this technique in a couple of his projects. The first was a prototype of WikiPedia. While they have gone with a separated mobile site (e.g. en.m.wikipedia.org/), he started with the HTML from the desktop site and applied some vertical media queries to make the content much more digestible. Take a look at his code to see how it works.

The second example Antoine demonstrated was for the navigation at Volkswagen. The client wanted to display an unlimited number of items in the secondary navigation. Once again Antoine applied vertical media queries to handle the varying number of navigation elements based on the device height. Check out his adaptive sticky vertical navigation code for a closer look.

Slides from this talk are available here: Embrace the Vertical.

Christophe Burgmer — If your CSS is happy and you know it…

This was a really interesting talk about testing your CSS visually with a tool Christophe has been developing called CSS Critic. Christophe covered some of the existing CSS/HTML testing tools like Selenium and found that while they worked well they didn’t meet his needs entirely. He wanted a way to visually diff the changes that were made and to be able to write tests for his UI code. For example, when the “accepted” version of the page changed visually, he wanted to be notified and decide whether or not to accept the proposed change.

Christophe demoed the tool for us and it was really cool to see a visual diff in the browser. For a change that was introduced, screenshots of the old, new and difference were displayed. The user then has the ability to accept / OK the change or reject it. You can view the tool in action on the CSS Critic site. Under the hood, CSS Critic uses some other nifty projects including Wraith, PhantomCSS, CasperJS and Hardy. Christophe also mentioned csste.st as a site which curates information on all of these topics and projects.

Slides from this talk are available here: If you CSS is happy and you know it…

Zach Leatherman — Bulletproof Icon Fonts

Zach wrote a great article on Bulletproof Accessible Icon Fonts earlier this year and his talk was along similar lines. He chronicled some of the challenges and pitfalls worth knowing about in order to support icon fonts in your sites and applications. Browser support varies a great deal and Zach cited John Holt Ripley’s Unify unicode support charts as a helpful reference. He works on the a-font-garde project which documents best (er. bulletproof) practices for working with icon fonts today.

Stay Tuned

Watch for one more post later this week with the last batch of talks from the conf!

CSSConf US 2014 — Part One

2014-05-28T00:00:00+00:00

Geeks in Paradise

Today I was very lucky to once again attend CSSConf US here in Amelia Island, Florida. Nicole Sullivan and crew did an excellent job of organizing and curating a wide range of talks specifically geared toward CSS developers. Although I work daily on many aspects of the web stack, I feel like I’m one of the (seemingly) rare few who actually enjoy writing CSS so it was a real treat to spend the day with many like-minded folks.

Styleguide Driven Development

Nicole Sullivan started things off with her talk on Style Guide Driven Development (SGDD). She talked about the process and challenges she and the team at Pivotal Labs went through when they redesigned the Cloud Foundry Developer Console and how they overcame many of them with the SGDD approach. The idea behind SGDD is to catalog all of the reusable components used in a web project so developers use what’s already there rather than reinventing the wheel for each new feature. The components are displayed in the style guide next to examples of the view code and CSS which makes up each component. The benefits of this approach include enabling a short feedback loop for project managers and designers and encouraging developers who may not be CSS experts to follow the “blessed” path to build components that are consistent and cohesive with the design. In Nicole’s project they were also able to significantly reduce the amount of unused CSS and layouts once they had broken down the app into reusable components.

Hologram is an interesting tool to help with the creation of style guides which Nicole shared and is definitely worth checking out.

Sara Soueidan — Styling and Animating Scalable Vector Graphics with CSS

Sara talked to us about using SVG with CSS and included some really neat demos. Adobe Illustrator, Inkscape and Sketch 3 are the commonly used tools used to create SVG images. Once you have your SVG image you can use the SVG Editor by Peter Collingridge or SVGO (node.js based tool) to clean up and optimize the SVG code. After the cleanup and optimization you can replace the generic CSS class names from your SVG creation app with more semantic CSS class names.

There are a variety of ways to include SVG on a page and Sara went over the pros and cons of each. The method that seemed most interesting to me was to use an <object> tag which allowed for a fallback image for browsers that do not support SVG. Sara mapped out the subset of CSS selectors which can be used to target SVG elements, how to “responsify” SVGs and to animate SVG paths. Be sure to check out her slides from the talk.

Lea Verou — The Chroma Zone: Engineering Color on the Web

Lea’s talk was about color on the web. She detailed the history of how color has been handled up to this point, how it works today and some of the interesting color-related CSS features which are coming in the future. She demonstrated how each of the color spaces have a geographical representation (e.g. RGB can be represented as a cube and HSL as a double-cone) which I found neat. RGB is very unintuitive when it comes to choosing colors. HSL is much more intuitive but has some challenges of its own. The new and shiny CSS color features Lea talked about included:

filters
blending modes
CSS variables
gray()
color() including tint, shade and other adjusters
the #rgba and #rrggbbaa notation
hwb()
named hues and in hsl()

Some of these new features can be used already via libs like Bourbon and Myth. Check out the Chroma Zone: Engineering Color on the Web slides to learn more.

C$$

I will write up more of the talks soon but wanted to thank Jenn Schiffer for keeping us all laughing throughout the day in her role as MC and topping it off with a hilarious, satirical talk of her own. Thanks also to Alex and Adam for curating the music and looking after the sound.

Fixed Navigation Bar: HTML, CSS, and JavaScript Breakdown

2013-09-02T00:00:00+00:00

Something that I’ve seen frequently these days on content rich sites are fixed navigation bars, or small abbreviated header in the form of a horizontal bar at the top of the screen that shows after a user has scrolled below the header. Here’s an example:

A live example of an abbreviated fixed navigation bar at the top of the articles at ABCNews.com. The background has a grey opaque layer for demonstration purposes only.

I recently implemented this functionality for H2O, and I’ll go through the tools needed to do this.

HTML Markup

First thing’s first, you need the HTML markup for this. The only tricky thing here is that the horizontal bar must be outside of any wrapping dividers on the page that are confining the content to a set width. For example, if your content is limited to 900 pixels in width, the horizontal bar markup must be outside that constraint. Here’s what the HTML might look like:

<div id="fixed_bar">
  <div class="wrapper">
    Links & content here.
  </div>
</div>

Note that in the above HTML, the “wrapper” div may be constraining the content width to match the remaining content, such as in the example above. This HTML may go at the beginning or end of the page HTML. I prefer to see it at the top of the page HTML. Another note is that other HTML elements may be used in place of the div, but I chose the div above because it defaults to a block element (an element where the CSS display default value is block).Finally, one more note here is that HTML5 elements can be used in place of the div as well (section or nav might make sense) if the site is HTML5 compliant.

CSS Settings

The secret to this interactive feature lies in the CSS settings. Here’s what the CSS for my example code above might look like:

body {
  margin: 0px;
  padding: 0px;
}
#fixed_bar {
  width: 100%;
  position: fixed;
  z-index: 100; //exceed z-index of other elements on the page
  display: none;
  background: transparent url(/images/fixed_bar.png) bottom repeat-x;
  top: 0px;
}
.wrapper {
  width: 900px;
  margin: 0px auto;
}

Here are the important bits of the CSS above:

The fixed positioning setting is what keeps the bar in one place as the user scrolls up and down (line 7).
The body must have margin and padding settings at 0px to ensure that the fixed bar is flush against the top of the screen (line 2 & 3).
The fixed bar spans the width of the browser, but in this case, the .wrapper element is constrained to 900 pixels wide (line 14).
The default state of the #fixed_bar element is none, which is hidden upon page load (line 9).
The background of the #fixed_bar can be a small image with a gradient to transparency, such as in the example above (line 10).

Scroll Event Listener

Finally, after the HTML and CSS markup is good to go, here’s what the interactive JavaScript (via jQuery) might look like:

var offset = 100; // some offset value for which when the header becomes hidden
jQuery(window).scroll(function() { //also an option: jQuery .on('scroll') method
  if(jQuery('#fixed_bar').is(':visible') && jQuery(window).scrollTop() < offset) {
    jQuery('#fixed_bar').fadeOut(200);
  } else if(!jQuery('#fixed_bar').is(':visible') && jQuery(window).scrollTop() > offset) {
    jQuery('#fixed_bar').fadeIn(200);
  }
});

The jQuery above checks for two scenarios:

a) If the #fixed_bar div is visible and the scroll position is less than the offset, fade the #fixed_bar div to a hidden state.
b) If the #fixed_bar div is not visible and the scroll position is greater than the offset, fade the #fixed_bar div to a visible state.

These two use cases will toggle the visibility of the fixed bar to a hidden and visible state. With these combined elements of HTML, CSS, and jQuery & JavaScript, a nice user interactivity feature adds to the usability of the site by providing valuable links and content as the user scrolls down the page.

JSConf US 2013 — Day One

2013-06-04T00:00:00+00:00

I attended JSConf in Amelia Island, FL last week. As you can see, the venue was pretty spectacular and the somewhat remote location lent itself very well to the vision set by the conference organizers. Many developers myself included, often find the line between work and play blurring because there is much work to be done, many new open source projects to check out, constant advancements in browser technology, programming languages, you name it. Keeping up with it all is fun but can be challenging at times. While the talks were amazing, the focus and ethos of JSConf as I experienced it was more about people and building on the incredible community we have. I highly recommend attending meetups or conferences in your field if possible.

Without further ado, I’ve written about some of the talks I attended. Enjoy!

Day One

Experimenting With WebRTC

Remy Sharp presented the first talk of the day about his experience building a Google Chrome Experiment with WebRTC and the peer to peer communication API. The game (headshots), was built to work specifically on Chrome for Android Beta. Because WebRTC is so young, the libraries supporting it (Peer.js, easyRTC, WebRTC.io, SimpleWebRTC) are very young as well and developing quickly. He found that “Libraries are good when you’re fumbling, bad when stuff doesn’t work”. The “newness” of WebRTC ate much more time than he had anticipated. Remi demoed the game and it looked like good fun. If you’re interested in checking out headshots further, the source code is up on GitHub.

JavaScript Masterclass

Angelina Fabbro gave a talk about levelling up your skills as a developer. She first broke everyone’s heart by telling us “we’re not special” and that nobody is a natural born programmer. She presented some data (studies etc) to support her point and argued that early exposure to the practice of logical thinking and practicing programming can make you seem like a natural.

She described several ways to know you’re not a beginner:

You can use the fundamentals in any language
You are comfortable writing code from scratch
You peek inside the libraries you use
You feel like your code is mediocre and you’re unsure what to do about it

…and ways to know you’re not an expert:

You don’t quite grok (understand) all the code you read
You can’t explain what you know
You aren’t confident debugging
You rely on references/docs too much

“Welcome to the ambiguous zone of intermediate-ness”.

Angelina suggested several ways to improve your skills. Ask “why?” obsessively, teach or speak at an event, work through a suggested curriculum, have opinions, seek mentorship, write in another language for a while etc. One book she specifically recommended was Secrets of the JavaScript Ninja by John Resig.

JavaScript is Literature is JavaScript

Angus Croll from Twitter presented a hilariously entertaining talk in which he refactored some JavaScript functions in the literary styles of Hemingway, Shakespeare, Bolaño, Kerouac, James Joyce and other literary figures. The talk was inspired by a blog post he’d written and had the entire conference hall erupting with laughter throughout.

Learning New Words

Andrew Dupont continued in the literary, language-oriented vein, giving a talk which drew a parallel between olde english purists who did not want to adopt any “new” words and the differing views surrounding the EcmaScript 6 specification process. Dupont’s talk was very thought-provoking especially in light of the resistance to some proposals in the works (e.g. ES6 modules). Check out his slides—the video will also be published in future.

Flight.js

Dan Webb spoke about Flight, a client-side framework developed by the team at Twitter and released this past January. They have been using it to run lots of twitter.com and most of tweetdeck as well. Webb got a laugh out of the room when he recalled the first comment on Hacker News after Flight was announced: “Why not use Angular?”. The motivation behind Flight’s design was to make a “system that’s easy to think about”. This aim was achieved by decoupling components (entirely self-contained).

A Flight component is just a JavaScript object with a reference to a DOM node. The component can be manipulated, trigger events and listen to events (from other components). Applications are constructed by attaching Flight components to pieces of the DOM. Keeping the components independent in this way makes testing very easy. Complexity can be layered on but does not require any additional mental overhead. Dan suggested that Flight’s design and architecture would work very well with Web Components and Polymer in future.

CSS Conf 2013 — When Bootstrap Attacks!

2013-06-03T00:00:00+00:00

I attended the inaugural CSS Conf last week at Amelia Island, Florida. The conference was organized by Nicole Sullivan, Brett Stimmerman, Jonathan Snook, and Paul Irish and put on with help from a host of volunteers. The talks were presented in a single track style on a wide range of CSS-related topics; there was something interesting for everyone working in this space. I really enjoyed the conference, learned lots and had great discussions with a variety of people hacking on interesting things with CSS. In the coming days I will be blogging about some of the talks I attended and sharing what I learned, so stay tuned!

When Bootstrap Attacks

Pamela Fox had the opening slot and spoke about the experiences and challenges she faced when upgrading Bootstrap to V2 in a large web app (Coursera). What she initially thought would be a quick project turned into a month-long “BOOTSTRAPV2ATHON”. Bootstrap styles were used throughout the project in dozens of PHP, CSS and JavaScript files. The fact that Bootstrap uses generic CSS class names like “alert”, “btn”, error etc made it very difficult to grep through the codebase for them. The Bootstrap classes were also used as hooks by the project’s JavaScript application code.

Lessons Learned

Fox offered some tips for developers facing a similar situation. The first of which was to prefix the Bootstrap CSS classes (e.g. .tbs-alert) in order to decouple Bootstrap from the customizations in your project. Some requests have been made to the Bootstrap team on this front but the issue has not been addressed yet. In the meantime, devs can add a task to their build step (e.g. Grunt, the asset pipeline in Rails etc) to automate the addition of prefixes to each of the CSS classes.

Another tip is to avoid using Bootstrap CSS classes directly. Instead, use the “extend” functionality in your preprocessor (Sass, Less, Stylus etc) of choice. For example:

  .ep-btn {
    @extend .btn
      &:hover {
          @extend .btn:hover
      }
  }

This way your project can extend the Bootstrap styles but keep your customizations separate and not closely coupled to the framework.

The same logic should also be applied to the JavaScript in your project. Rather than using the Bootstrap class names as hooks in your JavaScript code, use a prefix (e.g. js-btn) or use HTML5 data attributes. Separating the hooks used for CSS styles from those used in JavaScript is very helpful when upgrading or swapping out a client-side framework like Bootstrap.

Test All Of The Things

Pamela wrapped up the talk by explaining how testing front end code would ease the pain of upgrading a library next time. There are many testing libraries available today which address some of these concerns. She mentioned mocha, Chai, jsdom and Selenium which all look very helpful. In addition to testing front end code she offered up the idea of “diffing your front end” in a visual way. This concept was very interesting to someone who ensures designs are consistent across a wide array of browsers and devices on a daily basis.

Needle is a tool which allows you to do this automatically. Once you develop a test case, you can run Needle to view a visual diff of your CSS changes. I think this is an excellent idea. Pamela also noted that the combination of Firefox screenshots and Kaleidoscope could be used manually in much the same way.

Many thanks to Pamela for sharing this! The slides for this talk can be viewed here and the talk was recorded so the video will also be available sometime soon.

Ghost Table Cells in IE9

2013-02-08T00:00:00+00:00

What’s this about ghosts?

I recently came across an arcane layout issue in my work on a redesigned client site. The problem was specific to Internet Explorer 9 (IE9). The related CSS styles had been well tested and rendered consistently across a variety of browsers including IE7 and 8. Everything was fine and dandy until some new content was introduced into the page for a “Quickview” feature. While all of the other browsers continued to behave and render the page correctly, the layout would break in random and confusing ways in IE9.

The following screenshots compare the correct layout with an example of the broken layout in IE9.

Correct grid layout:

Broken layout in IE9:

The Stage

The following is a list of the factors at work on the page in question:

Internet Explorer 9
Browser mode: IE9, Document mode: IE9 standards
Some content manipulation performed via JavaScript (and jQuery in this case)
Lots of table cells

Debugging

The page included a list of products. The first “page” of twelve results was shown initially while JavaScript split the rest of the list into several additional pages. Once this JavaScript pagination function was complete, users could cycle through products in bite-sized pieces.

My first thought was that the issue may be related to CSS or JavaScript. I tested and debugged the styles thoroughly, tweaked styles and edited the underlying HTML structure to see if that might resolve the problem. I also tested the JavaScript and compared the original HTML with the parts which had been paginated via JavaScript. No dice.

When changes improved the paginated HTML, the bug appeared in the initial HTML. Other changes resolved the issue in the original HTML but it appeared in the paginated HTML.

I inspected the table with the Chrome Developer Tools console and also with the Developer Tools in IE9. There did not appear to be any differences between the rows which rendered properly and those which were skewed.

Bugging Out

At this point I began to research the issue and discovered it was a bug in the IE9 browser. A Microsoft forum post described the issue and included responses from Microsoft stating that it will not be fixed. It also included a sample application which demonstrated the issue. I tested and verified that the problem has been addressed and fixed in Internet Explorer 10, thankfully.

This explained the many, seemingly random ways I had seen the grid break. At times the cells were squished and pushed to the left. This was because the ghost cell had been added at the end of a row. Other times the cells were shifted to the right (as seen in the screenshot above). In this case, the ghost cell had been added to the middle of a row.

The Fix

Further digging revealed the the issue was related to whitespace between table cells. The solution was fairly simple: use a regular expression to remove all whitespace between the table elements:

$('#problem-table').html(function(i, el) {
  return el.replace(/>\s+</g, '><');
});

With all of the whitespace removed from the affected <table>, IE9 rendered the page correctly.

CSS sprites: The easy way?

2013-01-21T00:00:00+00:00

I’ve always been interested in the use of CSS sprites to speed up page load times. I haven’t had a real chance to use them yet but my initial reaction was that sprites would be quite painful to maintain. In my mind, you would have to load up the sprite into Gimp or Photoshop, add the new image and then create the css with the right coordinates to display the image. Being a guy with very little image editing skills, I felt that managing multiple images frequently would be quite time consuming. Recently, I was dealing with some page load times for a client and the use of sprites for the product listing pages came up as an option to speed them up. I knew the client wouldn’t have time to create sprites for this so I went searching for a command line tool that would allow me to create sprites. I was quite happy when I stumbled upon Glue.

Glue is free program that will take a directory of images and create a png sprite and a css file with the associated CSS classes. It has a ton of useful options. A few of the ones I thought were handy was being able to prefix the path to the image with a url instead of a relative path, being able to downgrade the png format to png8 to make the file sizes much smaller and being able to specify the start of the name of the class with something to help with being able to use them on a dynamic page.

The most basic use of the command is as follows:

glue blog output

In this example, blog is the directory where the images live that you want Glue to create a sprite of and output is the directory where it will generate the blog.png and blog.css file.

The output css file looks like this:

/* glue: 0.2.9.1 hash: f9c9d6aa5b */
.sprite-blog-product2,
.sprite-blog-product1{background-image:url('blog.png');background-repeat:no-repeat}
.sprite-blog-product2{background-position:0px 0px;width:159px;height:200px;}
.sprite-blog-product1{background-position:-159px 0px;width:200px;height:168px;}

The naming convention by default is sprite-$input_directory-$filename. You can override this with a few options. The version number and hash are used by Glue to ensure it doesn’t rebuild the sprite if none of the source images have changed. With these settings, I believe this could be a great program to run as a nightly routine to rebuild the sprites. This is the explanation from the documentation:

By default glue store some metadata inside the generated sprites in order to not
rebuild it again if the source images and settings are the same. Glue set two different
keys, glue with the version number the sprite was build and hash, generated using the 
source images data, name and all the relevant sprite settings like padding, margin 
etc...

I’m still tinkering with all the different options and thinking about how to include the use of this program in our work flow for this client. I’ll make sure to write a follow up with more information as I learn more.

If you have a different command line tool which helps manage sprites, don’t hesitate to leave a comment and let me know!

Keeping Your Apps Neat & Tidy With RequireJS

2012-05-17T00:00:00+00:00

RequireJS is a very handy tool for loading files and modules in JavaScript. A short time ago I used it to add a feature to Whiskey Militia that promoted a new section of the site. By developing the feature as a RequireJS module, I was able to keep all of its JavaScript, HTML and CSS files neatly organized. Another benefit to this approach was the ability to turn the new feature “on” or “off” on the site by editing a single line of code. In this post I’ll run through a similar example to demonstrate how you could use RequireJS to improve your next project.

File Structure

The following is the file structure I used for this project:

├── index.html
└── scripts
    ├── main.js
    ├── my
    │   ├── module.js
    │   ├── styles.css
    │   └── template.html
    ├── require-jquery.js
    ├── requirejs.mustache.js
    └── text.js

The dependencies included RequireJS bundled together with jQuery, mustache.js for templates and the RequireJS text plugin to include my HTML template file.

Configuration

RequireJS is included in the page with a script tag and the data-main attribute is used to specify additional files to load. In this case “scripts/main” tells RequireJS to load the main.js file that resides in the scripts directory. Require will load the specified files asynchronously. This is what index.html looks like:

<!DOCTYPE html><br/><html><br/><head><br/>    <title>RequireJS Example</title><br/></head><br/><body><br/>    <h1>RequireJS Example</h1><br/>    <!-- This is a special version of jQuery with RequireJS built-in --><br/>    <script data-main="scripts/main" src="scripts/require-jquery.js"></script><br/></body><br/></html><br/>

I was a little skeptical of this approach working on older versions of Internet Explorer so I tested it quickly with IE6 and confirmed that it did indeed work just fine.

Creating a Module

With this in place, we can create our module. The module definition begins with an array of dependencies:

define([
  "require",
  "jquery",
  "requirejs.mustache",
  "text!my/template.html"
  ],

This module depends on require, jQuery, mustache, and our mustache template. Next is the function declaration where our module’s code will live. The arguments specified allow us to map variable names to the dependencies listed earlier:

  function(require, $, mustache, html) { ... }

In this case we’re mapping the $ to jQuery, mustache to requirejs.mustache and, html to our template file.

Inside the module we’re using Require’s .toUrl() function to grab a URL for our stylesheet. While it is possible to load CSS files asynchronously just like the other dependencies, there are some issues that arise that are specific to CSS files. For our purposes it will be safer to just add a element to the document like so:

  var cssUrl = require.toUrl("./styles.css");
  $('head').append($('<link/>',
    { rel: "stylesheet", media: "all", type: "text/css", href: cssUrl }));

Next, we define a view with some data for our Mustache template and render it.

  var view = {
    products: [
      { name: "Apples", price: 1.29, unit: 'lb' },
      { name: "Oranges", price: 1.49, unit: 'lb'},
      { name: "Kiwis", price: 0.33, unit: 'each' }
    ],
    soldByPound: function(){
      return (this['unit'] === 'lb') ? true : false;
    },
    soldByEach: function() {
      return (this['unit'] === 'each') ? true : false;
    }
  }

  // render the Mustache template
  var output = mustache.render(html, view);

  // append to the HTML document
  $('body').append(output);
});

The Template

I really like this approach because it allows me to keep my HTML, CSS and JavaScript separate and also lets me write my templates in HTML instead of long, messy JavaScript strings. This is what our template looks like:

<ul class="hot-products"><br/>  {{#products}}<br/>  <li class="product"><br/>    {{name}}: ${{price}} {{#soldByEach}}each{{/soldByEach}}{{#soldByPound}}per lb{{/soldByPound}}<br/>  </li><br/>  {{/products}}<br/></ul><br/>

Including the Module

To include our new module in the page, we simply add it to our main.js file:

require(["jquery", "my/module"], function($, module) {
    // jQuery and my/module have been loaded.
    $(function() {

    });
});

When we view our page, we see that the template was was rendered and appended to the document:

Optimizing Your Code With The r.js Optimizer

One disadvantage of keeping everything separate and using modules in this way is that it adds to the number of HTTP requests on the page. We can combat this by using the the RequireJS Optimizer. The r.js script can be used a part of a build process and runs on both node.js and Rhino. The Optimizer script can minify some or all of your dependencies with UglifyJS or Google’s Closure Compiler and will concatenate everything into a single JavaScript file to improve performance. By following the documentation I was able to create a simple build script for my project and build the project with the following command:

node ../../r.js -o app.build.js

This executes the app.build.js script with Node. We can compare the development and built versions of the project with the Network tab in Chrome’s excellent Developer Tools.

Development Version:

Optimized with the RequireJS r.js optmizer:

It’s great to be able to go from 8 HTTP requests and 360 KB in development mode to 4 HTTP requests and ~118 KB after by running a simple command with Node! I hope this post has been helpful and that you’ll check out RequireJS on your next project.

Three Things: Rails, JOIN tip, and Responsiveness

2012-05-11T00:00:00+00:00

Here’s another entry in my Three Things series, where I share a few small tips I’ve picked up lately.

1. Rails and Dramas

Sometimes I think that since Rails allows you write code efficiently, [a few] members of the Rails community have time to overdramatize incidents that otherwise would go relatively unnoticed :) Someone with a good sense of humor created this website to track these dramas. While it’s probably a waste of time to get caught up on the personal aspects of the drama, some of the dramas have interesting technical aspects which are fiercely defended.

2. JOIN with concat

Recently I needed to perform a JOIN on a partial string match in MySQL. After some investigation, I found that I had use the CONCAT method in a conditional (in an implicit inner JOIN), which looked like this:

SELECT * FROM products p, related_items ri WHERE concat(p.sku, '%') = ri.id

In modern MVC frameworks with ORMs, databases are typically not designed to include data associations in this manner. However, in this situation, data returned from a third party service in a non-MVC, ORM-less application was only a substring of the original data. There may be alternative ways to perform this type of JOIN, and perhaps my fellow database experts will comment on the post with additional techniques ;)

3. Responsiveness

Responsive web design is all the rage lately from the increase in mobile web browsing and tablets. Here is a fun tool that that the ecommerce director at Paper Source pointed out to me recently. The website allows you to render a single URL at various widths for a quick review of the UI.

Firebug in Action: CSS Changes

2012-03-19T00:00:00+00:00

When I work with clients, I encourage them to use tools to improve efficiency for web development. Sometimes my clients want styling (CSS) adjustments like font-size, padding, or orientation changes, but they aren’t sure what they want before they’ve seen it applied to real content. I recommend embracing a tool such as Firebug for examining temporary on-page CSS edits. Here’s a quick video that demonstrates Firebug in action as I try out a few adjustments to End Point’s home page.

Some of the changes I test out in the video include:

Font-color changes
Deleting DOM elements
Padding, margin adjustments
Background color changes

Firebug offers a lot more functionality but the video covers interactive CSS changes only. Read more about Firebug’s features here. Chrome has similar functionality with the Developer Tools included in the core software. There are similar tools in the other browsers, but I develop in Chrome or Firefox and I’m not familiar with them.

Using esbuild and pnpm to Set Up Frontend Asset Bundling in an ASP.NET Core Web App

Installing pnpm and the necessary packages

Authoring JavaScript and SCSS source files

Bundling frontend assets with esbuild

Importing libraries as modules

Importing libraries via HTML tags

Summary

Comparison of Lightweight CSS Frameworks

Bulma

mini.css

Pure.css

Skeleton

Milligram

Making the most of your lightweight framework

Building responsive websites with Tailwind CSS

Atomic CSS

Shaking off the unused CSS

DRYing it up

Building a responsive page using Tailwind

Responsive variants

Conclusion

Catching CSS Regressions and Visual Bugs in Continuous Integration

Visual regression testing to the rescue

Integrating Percy

1. Register an account at percy.io

2. Integrate with the Rails project

3. Percy in Feature Specs

Adding Percy into the mix

4. Introduce visual changes and see how percy.io compares

5. What about style regressions?

6. Responsive design and cross-browser testing

Caveats

Conclusion

Other resources

Jamstack Conf Virtual 2020: Thoughts & Highlights

Welcome to Jamstack Conf Virtual 2020

Keynote

State of the Jamstack Survey results

Fireside chat with Harper Reed

Lightning Launch: Netlify ⚡

Lightning Launch: Prismic ⚡

Lightning Launch: RedwoodJS ⚡

The COVID Tracking Project: 0 to 2M API requests in 3 months

Jamstack for emerging markets

Managing diabetes with Jamstack

Selling tickets without servers. Or frameworks. Or cookies.

The business side of the Jamstack

Build plugin authors’ session

Videos from the conference

Winning with CSS Grid and Autoprefixer

Using CSS Grid Today

CSS Grid Basics

Autoprefixer + CSS Grid

Test Your Autoprefix’d Grid Styles

Learning More

React: Style Tips

CSS Modules

Material-UI and similar libraries

Vanilla CSS with Material-UI

Conclusion

CSSConf US 2016 — Day One

Sarah Drasner — Creativity in Programming for Fun and Profit

Brian Jordan — No Bugs in Sight: Continuous Visual Tesing at Code.org

Jessica Lord — Nativize is the new Normalize

Jen Kramer — CSS4 Grid: True Layout Finally Arrives

Pete Hunt — Component-Based Style Reuse

Keith J. Grant — Stop Thinking in Pixels

Will Boyd — Silky Smooth Animation with CSS

Lea Verou — CSS Variables var(–subtitle);

Zurb Foundation 5: Applying Styles Conditionally Based on Viewport Size

Full Screen Gallery with Supersized and video slides

Basic functionality

Customizing the toolbar

Customizing the screen image size

Introducing video (YouTube) slides

Final Result

Old Dog & New Tricks — Giving Interchange a New Look with Bootstrap

Introduction

Angular Responsive Layout Directive

Simplifying mobile development with Ionic Framework