Developer News

?No Joke…Download Anything You Want on Storyblocks

Css Tricks - Thu, 09/21/2017 - 4:27am

(This is a sponsored post.)

Storyblocks is giving CSS-Tricks followers 7 days of complimentary downloads! Choose from over 400,000 stock photos, icons, vectors, backgrounds, illustrations, and more from the Storyblocks Member Library. Grab 20 downloads per day for 7 days. Also, save 60% on millions of additional Marketplace images, where artists take home 100% of sales. Everything you download is yours to keep and use forever—royalty-free. Storyblocks regularly adds new content so there’s always something fresh to see. All the stock your heart desires! Get millions of high-quality stock images for a fraction of the cost. Start your 7 days of complimentary downloads today!

Direct Link to ArticlePermalink

?No Joke…Download Anything You Want on Storyblocks is a post from CSS-Tricks

The All-New Guide to CSS Support in Email

Css Tricks - Wed, 09/20/2017 - 10:06am

Campaign Monitor has completely updated it's guide to CSS support in email. Although there was a four-year gap between updates (and this thing has been around for 10 years!), it's continued to be something I reference often when designing and developing for email.

Calling this an update is underselling the work put into this. According to the post:

The previous guide included 111 different features, whereas the new guide covers a total of 278 features.

Adding reference and testing results for 167 new features is pretty amazing. Even recent features like CSS Grid are included — and, spoiler alert, there is a smidgeon of Grid support out in the wild.

This is an entire redesign of the guide and it's well worth the time to sift through it for anyone who does any amount of email design or development. Of course, testing tools are still super important to the over email workflow, but a guide like this helps for making good design and development decisions up front that should make testing more about... well, testing, rather than discovering what is possible.

Direct Link to ArticlePermalink

The All-New Guide to CSS Support in Email is a post from CSS-Tricks

The Modlet Workflow: Improve Your Development Workflow with StealJS

Css Tricks - Wed, 09/20/2017 - 4:59am

You've been convinced of the benefits the modlet workflow provides and you want to start building your components with their own test and demo pages. Whether you're starting a new project or updating your current one, you need a module loader and bundler that doesn't require build configuration for every test and demo page you want to make.

StealJS is the answer. It can load JavaScript modules in any format (AMD, CJS, etc.) and load other file types (Less, TypeScript, etc.) with plugins. It requires minimum configuration and unlike webpack, it doesn't require a build to load your dependencies in development. Last but not least, you can use StealJS with any JavaScript library or framework, including CanJS, React, Vue, etc.

In this tutorial, we're going to add StealJS to a project, create a component with Preact, create an interactive demo page, and create a test page.

Article Series:
  1. The Key to Building Large JavaScript Apps: The Modlet Workflow
  2. Improve Your Development Workflow with StealJS (You are here!)
1. Creating a new project

If you already have an existing Node.js project: great! You can skip to the next section where we add StealJS to your project.

If you don't already have a project, first make sure you install Node.js and update npm. Next, open your command prompt or terminal application to create a new folder and initialize a `package.json` file:

mkdir steal-tutorial cd steal-tutorial npm init -y

You'll also need a local web server to view static files in your browser. http-server is a great option if you don't already have something like Apache installed.

2. Add StealJS to your project

Next, let's install StealJS. StealJS is comprised of two main packages: steal (for module loading) and steal-tools (for module bundling). In this article, we're going to focus on steal. We're also going to use Preact to build a simple header component.

npm install steal preact --save

Next, let's create a `modlet` folder with some files:

mkdir header && cd header && touch demo.html demo.js header.js test.html test.js && cd ..

Our `header` folder has five files:

  • demo.html so we can easily demo the component in a browser
  • demo.js for the demo's JavaScript
  • header.js for the component's main JavaScript
  • test.html so we can easily test the component in a browser
  • test.js for the test's JavaScript

Our component is going to be really simple: it's going to import Preact and use it to create a functional component.

Update your `header.js` file with the following:

import { h, Component } from "preact"; export default function Header() { return ( <header> <h1>{this.props.title}</h1> </header> ); };

Our component will accept a title property and return a header element. Right now we can't see our component in action, so let's create a demo page.

3. Creating a demo page

The modlet workflow includes creating a demo page for each of your components so it's easier to see your component while you're working on it without having to load your entire application. Having a dedicated demo page also gives you the opportunity to see your component in multiple scenarios without having to view those individually throughout your app.

Let's update our `demo.html` file with the following so we can see our component in a browser:

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Header Demo</title> </head> <body> <form> <label> Title <input autofocus id="title" type="text" value="Header component" /> </label> </form> <div id="container"></div> <script src="../node_modules/steal/steal.js" main="header/demo"></script> </body> </html>

There are three main parts of the body of our demo file:

  • A form with an input so we can dynamically change the title passed to the component
  • A #container for the component to be rendered into
  • A script element for loading StealJS and the demo.js file

We've added a main attribute to the script element so that StealJS knows where to start loading your JavaScript. In this case, the demo file looks for `header/demo.js`, which is going to be responsible for adding the component to the DOM and listening for the value of the input to change.

Let's update `demo.js` with the following:

import { h, render } from 'preact'; import Header from './header'; // Get references to the elements in demo.html const container = document.getElementById('container'); const titleInput = document.getElementById('title'); // Use this to render our demo component function renderComponent() { render(<Header title={titleInput.value} />, container, container.lastChild); } // Immediately render the component renderComponent(); // Listen for the input to change so we re-render the component titleInput.addEventListener('input', renderComponent);

In the demo code above, we get references to the #container and input elements so we can append the component and listen for the input's value to change. Our renderComponent function is responsible for re-rendering the component; we immediately call that function when the script runs so the component shows up on the page, and we also use that function as a listener for the input's value to change.

There's one last thing we need to do before our demo page will work: set up Babel and Preact by loading the transform-react-jsx Babel plugin. You can configure Babel with StealJS by adding this to your `package.json` (from Preact's docs):

... "steal": { "babelOptions": { "plugins": [ ["transform-react-jsx", {"pragma": "h"}] ] } }, ...

Now when we load the `demo.html` page in our browser, we see our component and a form to manipulate it:

Great! With our demo page, we can see how our component behaves with different input values. As we develop our app, we can use this demo page to see and test just this component instead of having to load our entire app to develop a single component.

4. Creating a test page

Now let's set up some testing infrastructure for our component. Our goal is to have an HTML page we can load in our browser to run just our component's tests. This makes it easier develop the component because you don't have to run the entire test suite or litter your test code with .only statements that will inevitably be forgotten and missed during code review.

We're going to use QUnit as our test runner, but you can use StealJS with Jasmine, Karma, etc. First, let's install QUnit as a dev-dependency:

npm install qunitjs --save-dev

Next, let's create our `test.html` file:

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width"> <title>Header Test</title> </head> <body> <div id="qunit"></div> <div id="qunit-fixture"></div> <script src="../node_modules/steal/steal.js" main="header/test"></script> </body> </html>

In the HTML above, we have a couple of div elements for QUnit and a script element to load Steal and set our `test.js` file as the main entry point. If you compare this to what's on the QUnit home page, you'll notice it's very similar except we're using StealJS to load QUnit's CSS and JavaScript.

Next, let's add this to our `test.js` file:

import { h, render } from 'preact'; import Header from './header'; import QUnit from 'qunitjs'; import 'qunitjs/qunit/qunit.css'; // Use the fixture element in the HTML as a container for the component const fixtureElement = document.getElementById('qunit-fixture'); QUnit.test('hello test', function(assert) { const message = 'Welcome to your first StealJS and React app!'; // Render the component const rendered = render(<Header title={message} />, fixtureElement); // Make sure the right text is rendered assert.equal(rendered.textContent.trim(), message, 'Correct title'); }); // Start the test suite QUnit.start();

You'll notice we're using Steal to import QUnit's CSS. By default, StealJS can only load JavaScript files, but you can use plugins to load other file types! To load QUnit's CSS file, we'll install the steal-css plugin:

npm install steal-css --save-dev

Then update Steal's `package.json` configuration to use the steal-css plugin:

{ ... "steal": { "babelOptions": { "plugins": [ ["transform-react-jsx", {"pragma": "h"}] ] }, "plugins": [ "steal-css" ] }, ... }

Now we can load the test.html file in the browser:

Success! We have just the tests for that component running in our browser, and QUnit provides some additional filtering features for running specific tests. As you work on the component, you can run just that component's tests, providing you earlier feedback on whether your changes are working as expected.

Additional resources

We've successfully followed the modlet pattern by creating individual demos and test pages for our component! As we make changes to our app, we can easily test our component in different scenarios using the demo page and run just that component's tests with the test page.

With StealJS, a minimal amount of configuration was required to load our dependencies and create our individual pages, and we didn't have to run a build each time we made a change. If you're intrigued by what else it has to offer, has information on more advanced topics, such as building for production, progressive loading, and using Babel. You can also ask questions on Gitter or the StealJS forums!

Thank you for taking the time to go through this tutorial. Let me know what you think in the comments below!

Article Series:
  1. The Key to Building Large JavaScript Apps: The Modlet Workflow
  2. Improve Your Development Workflow with StealJS (You are here!)

The Modlet Workflow: Improve Your Development Workflow with StealJS is a post from CSS-Tricks

Deploying ES2015+ Code in Production Today

Css Tricks - Tue, 09/19/2017 - 9:13am

Philip Walton suggests making two copies of your production JavaScript. Easy enough to do with a Babel-based build process.

<!-- Browsers with ES module support load this file. --> <script type="module" src="main.js"></script> <!-- Older browsers load this file (and module-supporting --> <!-- browsers know *not* to load this file). --> <script nomodule src="main-legacy.js"></script>

He put together a demo project for it all and you're looking at 50% file size savings. I would think there would be other speed improvements as well, by using modern JavaScript methods directly.

Direct Link to ArticlePermalink

Deploying ES2015+ Code in Production Today is a post from CSS-Tricks

The Key to Building Large JavaScript Apps: The Modlet Workflow

Css Tricks - Tue, 09/19/2017 - 4:20am

You're a developer working on a "large JavaScript application" and you've noticed some issues on your project. New team members struggle to find where everything is located. Debugging issues is difficult when you have to load the entire app to test one component. There aren't clean API boundaries between your components, so their implementation details bleed one into the next. Updating your dependencies seems like a scary task, so your app doesn't take advantage of the latest upgrades available to you.

One of the key realizations we made at Bitovi was that "the secret to building large apps is to never build large apps." When you break your app into smaller components, you can more easily test them and assemble them into your larger app. We follow what we call the "modlet" workflow, which promotes building each of your components as their own mini apps, with their own demos, documentation, and tests.

Article Series:
  1. The Key to Building Large JavaScript Apps: The Modlet Workflow (You are here!)
  2. The Modlet Workflow: Improve Your Development Workflow with StealJS

Following this pattern will:

  • Ease the on-boarding process for new developers
  • Help keep your components' docs and tests updated
  • Improve your debugging and testing workflow
  • Enforce good API design and separation of concerns
  • Make upgrades and migrations easier

Let's talk about each of these benefits one by one to see how the modlet workflow can help your development team be more effective.

Ease the onboarding process for new developers

When a new developer starts on your project, they might be intimidated by the amount of files in your app's repository. If the files are organized by type (e.g. a CSS folder, a JS folder, etc.), then they're going to be searching across multiple folders to find all the files related to a single component.

The first step to following the modlet workflow is to create folders for each of your components. Each folder, or modlet, should contain all of the files for that component so anyone on your team can find the files they need to understand and develop the component, without having to search the entire project.

Additionally, we build modlets as their own mini apps by including at least the following files in their folders:

  • The main source files (JavaScript, stylesheets, templates, etc.)
  • A test JavaScript file
  • A markdown or text file for docs (if they're not inline with your code)
  • A test HTML page
  • A demo HTML page

Those last two files are crucial to following the modlet workflow. First, the test HTML page is for loading just the component's tests in your browser; second, the demo HTML page lets you see just that component in your browser without loading the entire app.

Improve your debugging and testing workflow

Creating demo and test HTML pages for each component might seem like overkill, but they will bring some great improvements to your development workflow.

The demo HTML page:

  • Lets you quickly see just that component without loading the entire app
  • Gives you a starting place for reproducing bugs (and reduces the surface area)
  • Offers you an opportunity to demo the component in multiple scenarios

That last item can be leveraged in a couple ways. I've worked on projects where we've:

  • Had multiple instances of the same component on a single page so we could see how it behaved in a few key scenarios
  • Made the demo page dynamic so we could play with dozens of variables to test a component

Last but not least, debugging issues will be easier because the component is isolated from the rest of the app. If you can reproduce the issue on the component's demo page, you can focus your attention and not have to consider unrelated parts of your app.

The test HTML page gives you similar benefits to the demo HTML page. When you can run just a single component's tests, you:

  • Don't need to litter your test code with .only statements that will inevitably be forgotten and missed during code review
  • Can make changes to the component and focus on just that component's tests before running the app's entire test suite
Enforce good API design and separation of concerns

The modlet workflow also promotes good API design. By using each component in at least two places (in your app and on the demo page), you will:

  1. Consider exactly what's required by your component's API
  2. Set clear boundaries between your components and the rest of your app

If your component's API is intuitive and frictionless, it'll be painless to create a demo page for your component. If too much "bootstrapping" is required to use the component, or there isn't a clean separation between the component and how it's used, then you might reconsider how it's architected.

With your component's API clearly defined, you set yourself up for being able to take your component out of its original repository and make it available in other applications. If you work in a large company, a shared component library is really helpful for being able to quickly develop projects. The modlet workflow encourages you to do that because each of your components already has its own demos, docs, and tests!

Help keep your components' docs and tests updated

A common issue I've seen on projects that don't follow the modlet workflow is that docs and tests don't get updated when the main source files change. When a team follows the modlet workflow, everyone knows where to look for each component's docs and tests: they're in the same folder as the component's source code!

This makes it easier to identify missing docs and tests. Additionally, the files being in the same folder serve as a reminder to every developer on the team to update them when making changes to that component.

This is also helpful during code review. Most tools list files by their name, so when you're reviewing changes for a component, you're reminded to make sure the docs and tests were updated too. Additionally, flipping between the implementation and tests is way easier because they'll be close to each other.

Make upgrades and migrations easier

Last but not least, following the modlet workflow can help you upgrade your app to new versions of your dependencies. Let's consider an example!

A new major version of your JavaScript framework of choice is released and you're tasked with migrating your app to the new version. If you're following the modlet workflow, you can start your migration by updating the components that don't use any of your other components:

The individual demo and test pages are crucial to making this upgrade. You can start by making the tests pass for your component, then double check it visually with your demo page.

Once those components work, you can start upgrading the components that depend on those:

You can follow this process until you get all of your app's components working. Then, all that's left is to test the actual app, which will be far less daunting because you know the individual components are working.

Large-scale migrations are easier when components are contained and well defined. As we discussed in an earlier section, the modlet workflow encourages clear API boundaries and separation of concerns, which makes it easier to test your components in isolation, making an entire app upgrade less intimidating.

Start using the modlet workflow in your app today

You can get started with the modlet workflow today—first, if your team is still organizing files by type, start grouping them by component instead. Move the test files to your component folders and add some HTML pages for demoing and testing your component. It might take your team a little bit of effort to transition, but it'll be worth it in the long run.

Some of the suggestions in this article might seem intimidating because of limitations in your tooling. For example, if you use a module loader & bundler that requires you to create a separate bundle for each individual page, adding two HTML pages per component would require an intimidating amount of build configuration.

In the next article in this series, we'll discuss how you can use a module loader and bundler called StealJS to load the dependencies for each of your components without a separate build for each HTML page.

Let me know what you think in the comments! If you follow a similar organization technique, then let me know what's worked well and what hasn't worked for you.

Article Series:
  1. The Key to Building Large JavaScript Apps: The Modlet Workflow (You are here!)
  2. The Modlet Workflow: Improve Your Development Workflow with StealJS

The Key to Building Large JavaScript Apps: The Modlet Workflow is a post from CSS-Tricks

Chrome to force .dev domains to HTTPS via preloaded HSTS

Css Tricks - Tue, 09/19/2017 - 4:15am

Mattias Geniar:

A lot of (web) developers use a local .dev TLD for their own development. ... In those cases, if you browse to, you'll be redirect[ed] to, the HTTPS variant.

That means your local development machine needs to;

  • Be able to serve HTTPs
  • Have self-signed certificates in place to handle that
  • Have that self-signed certificate added to your local trust store (you can't dismiss self-signed certificates with HSTS, they need to be 'trusted' by your computer)

This is probably generally A Good Thing™, but it is a little obnoxious to be forced into it on Chrome. They knew exactly what they were doing when they snatched up the .dev TLD. Isn't HSTS based on the entire domain though, not just the TLD?

Direct Link to ArticlePermalink

Chrome to force .dev domains to HTTPS via preloaded HSTS is a post from CSS-Tricks

React + Dataviz

Css Tricks - Mon, 09/18/2017 - 6:20am

There is a natural connection between Data Visualization (dataviz) and SVG. SVG is a graphics format based on geometry and geometry is exactly what is needed to visually display data in compelling and accurate ways.

SVG has got the "visualization" part, but SVG is more declarative than programmatic. To write code that digests data and turns it into SVG visualizations, that's well suited for JavaScript. Typically, that means D3.js ("Data-Driven Documents"), which is great at pairing data and SVG.

You know what else is good at dealing with data? React.

The data that powers dataviz is commonly JSON, and "state" in React is JSON. Feed that JSON data to React component as state, and it will have access to all of it as it renders, and notably, will re-render when that state changes.

React + D3 + SVG = Pretty good for dataviz

I think that idea has been in the water the last few years. Fraser Xu was talking about it a few years ago:

I like using React because everything I use is a component, that can be any component writen by myself in the project or 3rd party by awesome people on NPM. When we want to use it, just import or require it, and then pass in the data, and we get the visualization result.

That components thing is a big deal. I've recently come across some really good libraries smooshing React + D3 together, in the form of components. So instead of you leveraging these libraries, but essentially still hand-rolling the actual dataviz components together, they provide a bunch of components that are ready to be fed data and rendered.


nivo provides a rich set of dataviz components, built on top of the awesome d3 and Reactjs libraries.


Victory is a set of modular charting components for React and React Native. Victory makes it easy to get started without sacrificing flexibility. Create one of a kind data visualizations with fully customizable styles and behaviors. Victory uses the same API for web and React Native applications for easy cross-platform charting.


[react-vis is] a composable charting library


A composable charting library built on React components

React D3

A Javascript Library For Building Composable And Declarative Charts. A new solution for building reusable components for interactive charts.

React + Dataviz is a post from CSS-Tricks

A Rube Goldberg Machine

Css Tricks - Mon, 09/18/2017 - 5:39am

Ada Rose Edwards takes a look at some of the newer browser APIs and how they fit together:

These new APIs are powerful individually but also they complement each other beautifully, CSS custom properties being the common thread which goes through them all as it is a low level change to CSS.

The post itself is a showcase to them.

Speaking of new browser APIs, that was a whole subject on ShopTalk a few weeks back.

Direct Link to ArticlePermalink

A Rube Goldberg Machine is a post from CSS-Tricks

Basic grid layout with fallbacks using feature queries

Css Tricks - Mon, 09/18/2017 - 3:53am

I often see a lot of questions from folks asking about fallbacks in CSS Grid and how we can design for browsers that just don’t support these new-fangled techniques yet. But from now on I'll be sending them this post by HJ Chen. It digs into how we can use @supports and how we ought to ensure that our layouts don't break in any browser.

Direct Link to ArticlePermalink

Basic grid layout with fallbacks using feature queries is a post from CSS-Tricks

“The Notch” and CSS

Css Tricks - Sat, 09/16/2017 - 9:54am

Apple's iPhone X has a screen that covers the entire face of the phone, save for a "notch" to make space for a camera and other various components. The result is some awkward situations for screen design, like constraining websites to a "safe area" and having white bars on the edges. It's not much of a trick to remove it though, a background-color on the body will do. Or, expand the website the whole area (notch be damned), you can add viewport-fit=cover to your meta viewport tag.

<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">

Then it's on you to account for any overlapping that normally would have been handled by the safe area. There is some new CSS that helps you accommodate for that. Stephen Radford documents:

In order to handle any adjustment that may be required iOS 11's version of Safari includes some constants that can be used when viewport-fit=cover is being used.

  • safe-area-inset-top
  • safe-area-inset-right
  • safe-area-inset-left
  • safe-area-inset-bottom

This can be added to margin, padding, or absolute position values such a top or left.

I added the following to the main container on the website.

padding: constant(safe-area-inset-top) constant(safe-area-inset-right) constant(safe-area-inset-bottom) constant(safe-area-inset-left);

There is another awkward situation with the notch, the safe area, and fixed positioning. Darryl Pogue reports:

Where iOS 11 differs from earlier versions is that the webview content now respects the safe areas. This means that if you have a header bar that is a fixed position element with top: 0, it will initially render 20px below the top of the screen: aligned to the bottom of the status bar. As you scroll down, it will move up behind the status bar. As you scroll up, it will again fall down below the status bar (leaving an awkward gap where content shows through in the 20px gap).

You can see just how bad it is in this video clip:

Fortunately also an easy fix, as the viewport-fit=cover addition to the meta viewport tag fixes it.

If you're going to cover that viewport, it's likely you'll have to get a little clever to avoid hidden content!

I think I’ve fixed the notch issue in landscape &#x1f37e; #iphoneX

— Vojta Stavik (@vojtastavik) September 13, 2017

“The Notch” and CSS is a post from CSS-Tricks

Design Tooling is Still Figuring Itself Out

Css Tricks - Thu, 09/14/2017 - 1:20pm

It probably always will be, to be fair.

At the moment, there are all kinds of things that design software is struggling to address. The term "screen design" is common, referring to the fact that many of us are designing very specifically for screens, not print or any other application and screens have challenges unique to them. We have different workflows these days than in the past. We have different collaboration needs. We have different technological and economic needs.

Let's take a peak at all this weirdness.

Design tooling is still figuring out Responsive Design

It's almost taken for granted these days that any given new web project (or redesign) will be responsive design. Responsive design is the answer for screens of different sizes and different capabilities. So we can't just design a 1280px wide version and call it a day.

Software like Sketch has made multiple artboards of arbitrary sizes a first class citizen to help with this.

This doesn't completely solve the idea that we're designing for screens that can be of wildly different sizes, dimensions, and densities, but it certainly helps communicate a lot more than just one size does.

But how do you create all the different artboards you want to create? Copy and paste, resize stuff, and drag stuff around? You could, but design tooling is starting to figure itself out here a little. Here's a Sketch plugin called Constraints that is trying to make this easier:

Figma has this idea of constraints built right in:

Webflow is a unique design tool in that you aren't quite dragging things around as totally arbitrarily as you would in something like Sketch or Illustrator. Instead, you're manipulating things that are actually 1-to-1 representations of real web layout properties like margin, padding, and even things like flexbox and grid. They've made working with the Webflow editor naturally responsive, and you can see it immediately as you work.

Design tooling is still figuring out Collaboration

Imagine you do your designing with Photoshop. You have `.psd` files that are your designs. How do you deliver them? Email? Maybe, but that's a little messy for teams. Perhaps you have a shared Dropbox folder?

Adobe knows design teams need this. They have "Creative Cloud", which does everything from managing the actual software you have access to, to getting you access to design assets like fonts and stock photography, to helping you share files:

Sure, but that doesn't do anything besides giving everyone access to those files. There is even merge conflict danger, if multiple people are working on the same file.

The files themselves are only part of the story of collaboration. What about version history? What about notes and feedback? What about approval?

Invision is a big player in design tooling, and I would guess mostly because of the collaborative features. You don't create your designs in InVision, for the most part, you just upload them there and then do more with them, like talk about them:

Talking about designs overtop the designs themselves in Invision.

What if there wasn't really "files" at all to deal with? When your design software is a web app, the design documents aren't really documents you need to deal with yourself, they just kinda exist within the app. Figma is like this:

Plus, Figma offers teams, meaning collaboration amongst a team is just a matter of logging in and having shared access to everything.

Taking collaboration even further, Figma has realtime designing features. As in, Google-docs (or CodePen Collab Mode) style editing-at-the-same-time action:

Image from here.

As a testament to design tooling still figuring itself out, I don't think Figma pushes this feature very heavily anymore, marketing-wise. I think they have found that despite it being a showy feature, actual design teams don't really like it. Who knew.

This is an interesting read by Meng To comparing Figma and Sketch.

Design tooling is still figuring out Assets and Versions

Design can be more than screen mockups. A design team might need access to an icon set, a branding system, a color palette, a set of flat graphics...

Take a look at Lingo, which is an app explicitly for this. Collaboration is a key feature, but its team collaboration is based on assets.

I can imagine a tool like that not only making the sharing of assets easier but keeping the version of assets everyone is using up to date. As in, preventing people from keeping a "folder full of icons" on their local machine and having it go stale.

And speaking of versions... I'm sure we've all experienced (and heard the jokes) about files named things like:


Developers don't really have this problem thanks to version control. Where is version control for designers? Apps like Abstract are trying to help with that.

Abstract doesn't only help with collaboration, but version management as well.

Everything is saved. Nothing is lost. Version control you can trust.

Design tooling is still figuring out Design Systems

As I recently said:

We're not building pages, we're building systems. Style guides. Design systems. Pattern libraries. These things are becoming a standard part of the process for web projects. They will probably become the main deliverable.

We've seen design software slowly start to accommodate this kind of thinking over the years. Even things as simple as type styles took their sweet time making their way from places like InDesign (where they couldn't be lived without) over to Illustrator and Photoshop. They are so clearly needed that newer design tools always seem to have them.

Yet, if type is specifically what you are doing, there are tooling options specifically for that. Tools like Typecast are for that:

Or TypeNugget, which we've covered here:

One web app design tool, UX Pin, is focusing heavily on being a design tool for design systems.

We've covered that before, and you can see more about what they mean here:

Design tooling is still figuring out Interactivity

As much advancement as we're seeing with design tooling, we're also seeing that it's very hard for single tools to do it all. Interaction design is a great example of this.

Hover states! Swiping and gestures! Page transitions! Animations! Tap feedback!

As good as Sketch is at certain things, there is next to nothing there for handling interactivity. One one hand, it's a shame. Screen design is loaded with interactivity. It's definitely on designers minds and a must for their job. On the other hand, I might worry about bloat and lack of focus if all design tools tried to pack in interactivity tools.

Check out Framer, who are tackling interaction design head-on:

Framer is a visual design tool, with all the familiar styling tools (including some interesting constraint-based responsive stuff), but approach the interactive stuff literally through coding within the tool:

Design tooling is still figuring out Platforms

I feel just a smidge guilty every time I talk about Sketch, because I know it's macOS only. That excludes a huge chunk of people who work on websites. They don't even plan on it. Familiar players like Adobe generally make their products cross-platform, but even that is limited compared to the web-based tools, which work on any platform. I'd say web based tools like Figma and UX Pin have a strong advantage with the inherent collaboration and sharing abilities along with the cross-platform ability.

But desktop machines, regardless of platform, aren't the only story here. Certainly Apple had designers in mind with the iPad Pro:

What kind of design software is available on that? Affinity Designer seems to be working on it:

It's quiet in the office today and I'm feeling mischievous... Who fancies a bit of #affinitydesigner #ipad #shakycam teaser? &#x1f431;

— Matt Priestley (@mattp4478) July 12, 2017

And tools like Graphic:

Design tooling is still figuring out Trends

You can fill a box with noise in Sketch:

I'm not entirely sure why, but I imagine it might influence designers to use noise in a design. There is no one-click option to fill an area with tiny beetles, but I imagine if there was we'd see more divs filled with tiny beetles.

Adobe Experience Design has a "background blur" feature, no doubt inspired by recent Apple designs.

Heck, I can distort and object by "Polar Coordinates" in Photoshop.

Design tools influence design, and design influences design tooling. Whatever the default opacity settings are will influence design. Whatever the default gradient colors are. Whatever the default easing values are.

Design tooling is still figuring out Data

I imagine you've heard some full throated arguments both for and against lorem ipsum text. "It doesn't reflect real design!", you might hear. Whatever you think, it sure is interesting to see design tooling try to take on designing with real data.

Adobe Experience Design has some interesting features along these lines. Take their Repeat Grid tool, which is an interesting prototyping tool in it's own right, and can also help fill in real text and images:

Webflow helps with designing with data quite a bit too. They've said:

Designing with real data gives us a deeper understanding of how a page will function. In part because it surfaces all the “problems” designers strive to avoid in their mockups, such as long headlines, low-quality images, etc.

Designing with real content gives both writers and designers better insight into what they need to do.

They have an in-built CMS to store structured data, then design tools to help get that data onto designs:

Design tooling is still figuring out Pricing Models

I bet many of you remember when Adobe software was an (expensive) one-off cost. Now the transformation is complete and we're looking at anywhere from 10 to 50 dollars monthly to use the software, which I suppose makes it more accessible to some and less accessible to some.

Web apps are almost always a monthly cost. Figma is $12/month/user for teams. Business wise, for the creators of software, that seems to be the smart move. My own experience echoes that. But I can see how that can be a turn off for a native software product. Sketch is a flat $99, which I admit feels nice.

This will never shake out, surely, and it's not just one-off cost vs. monthly. There are free trials, freemium models, in-app purchases, and add-on models that all could and are being experimented with across the tooling landscape.

Wrapping Up

There is so much more to this, and I'm hardly the person to cover it.

For instance, I didn't talk too much about designing in the browser, but there is certainly tooling there. Aside from those few typography-focused apps, we didn't focus on the proliferation of tiny single-feature apps out there. Coolors is an example of that that I quite like. Not to mention the loads of design resource sites. We also didn't talk about wild crossover projects like React-Sketchapp.

Let's end with an interesting related article. Colm Tuite recently wrote "Design tools are running out of track. Here’s how we can fix them." Here's one of his points that I think is salient:

Why can’t designers just design the actual product?! Ultimately, all mockups are disposable, yet designers spend months tweaking them to perfection. That time would be much better spent tweaking the actual product.

Design Tooling is Still Figuring Itself Out is a post from CSS-Tricks

?Deliver exceptional customer experiences in your product

Css Tricks - Thu, 09/14/2017 - 6:12am

(This is a sponsored post.)

Pendo delivers the only complete platform for Product Teams that helps companies create great products. The Pendo Product Experience Platform enables Product Teams to understand product usage, collect user feedback, measure NPS, assist users in their apps and promote new features in product - all without requiring any engineering resources. This unique combination of capabilities is all built on a common infrastructure of product data and results in improved customer satisfaction, reduced churn, and increased revenue.

Pendo is the proven choice of innovative product leaders at Salesforce, Proofpoint, Optimizely, Citrix, BMC and many more leading companies.

Request a demo of Pendo today.

Direct Link to ArticlePermalink

?Deliver exceptional customer experiences in your product is a post from CSS-Tricks

Is there any value in people who cannot write JavaScript?

Css Tricks - Thu, 09/14/2017 - 6:07am

Mandy Michael:

If all you do in your job is write JS, that is fantastic and you are awesome, just like all the people that write CSS or have a focus in a particular area like accessibility, SVG, animation etc.

What I am very concerned about is that many still don’t see value in being skilled in CSS & HTML. This attitude is something I just don’t understand. All of us working together provide value in our industry.

+1 on all Mandy's points.

I suspect HTML and CSS skill will swing back higher in desirability a bit as design trends swing toward more complicated looks. More interesting layouts being one of those things. I tend to find those developers who only dabble in HTML/CSS fall over quickly when it comes to from-scratch work that involves layout. There is a lot of gray area here too. For example, I write Ruby code, but I fall over quickly when it comes to even moderately complex things.

I also suspect this conversation is rooted in the fact that HTML, CSS, and JavaScript are so intertwined, it tickles some people the wrong way to see other people stop at the first two.

Direct Link to ArticlePermalink

Is there any value in people who cannot write JavaScript? is a post from CSS-Tricks

Design Resource Sites

Css Tricks - Wed, 09/13/2017 - 6:34am

Sometimes when you're designing something, you need little helping hands. Perhaps a nice stock photo. Perhaps a happy little color palette. Perhaps a bleep or bloop sound. Perhaps the perfect icon.

There are tons and tons of sites that do those things. There are fewer sites that curate these design resource sites into manageable, high-quality groups. So allow me to abstract that yet another step and provide a selected list of those types of sites.

The Stocks

This is the one I was trying to remember the other day that spurred the idea for this little post. I quite like how you can just hang out on this site and click around to what you need by the type of resource, and the resource sites themselves just come up iframed.

Sans Francisco

Sans Francisco is a colorful and organize list of design resources by Robinson Greig.

Design Resources (.party!)

The winner of the best-named and best-TLD goes to Jessica Paoli. Similar to Sans Francisco, it's a big long curated one-pager full or resources organized by type.


More of what we're looking for!

A hand-picked directory of the best free resources for creatives.


I suspect this is the one that inspired The Stocks, as it also does the iframe thing. You click the site you want along the persistent left sidebar, and it loads the resource site on the right.

Design Resource Sites is a post from CSS-Tricks

Do you put anything in your code specifically for “Find in Project”?

Css Tricks - Tue, 09/12/2017 - 4:07am

During a having a team meeting the other day, a code formatting idea came up that I thought was super interesting. It had to do with formatting code in a such a way that made it easier to find what you were looking for later with any code editors "Find in Project" feature.

Here's what it was.

When declaring a function in JavaScript, put a space after the function name and before the opening parenthesis, like...

function doSomething () { }

That space between doSomething and () is perfectly fine. Then when you call the function, don't use a space, like this:


It's just a syntax convention.

But now, "Find in Project" is more useful. If we want to quickly find where that function was defined, we can search for "doSomething ()", and if we want to find instances of where it is used, we can look for "doSomething()".

You could extend the idea to classes or whatever too:

class myThing { constructor () { } doThing () { } } let example = new myThing(); example.doThing();

I'd say that's worth doing.

It reminds me of when I need to where a Ruby method is definied, I can always search for "def foo" since that "def " is required for creating the method.

I can imagine a scenario where it might be useful to define base classes in CSS like .module { but then if it's a variation or nested or used again for any other reason... .module{.

Here's a classic:

// TODO: &#x1f605;

— Charlotte Dann (@charlotte_dann) September 10, 2017

Leaving TODO comments throughout your code base turns a "Find in Project" for "TODO" an instant list of things you need to work on. Surely that could be even more nuanced, incorporating things like priority levels and assignments. Perhaps even emoji's to help like Charlotte suggested!

Here's an interesting one:

Use long classes/variables, mark future refactor points with comments. What are you looking for?

— Chris Pauley (@ChrisPauley) September 10, 2017

I like the idea of "long names". I suppose the longer and more descriptively you name things, the easier they are to search for and get specific results (avoiding repetitive matches like you would with very simple names).

Comments are a great place to leave things to search for. I often use a convention where I put my own name in the comment if I want people to know it was me leaving the comment, but it's not necessarily for me.

.thing { overflow: hidden; /* [Chris]: ugkghk this fixed a layout thing but I didn't have time to figure out exactly why. */ }

A smattering of responses:

At top of each template I add "<!-- Start [name of template] -->", at bottom, same but "End." Helps FIP and in browser-rendered code.

— Dale Henry Geist (@dalehenrygeist) September 10, 2017

I use consistent and natural language to name things, so when documentation goes stale, at least the code itself is still easy to stab at.

— John James Jacoby (@JJJ) September 10, 2017

Not in the code itself but in Sublime settings folder_exclude_patterns you can pass in an array of folders to exclude from all searches

— Ian C Woodward (@IanCWoodward) September 10, 2017

// TODO &#x1f615;
// FIXME &#x1f632;
// WT* &#x1f624;&#x1f4a3;

— Kamran Ahmed (@kamranahmedse) September 10, 2017

ctags is a lifesaver.

— Harry Roberts (@csswizardry) September 10, 2017

Naming conventions mate! BEM-esque those classes up `--thing` is always easier to find than `thing`

— James Bosworth (@fltwhte) September 11, 2017

Do you put anything in your code specifically for “Find in Project”? is a post from CSS-Tricks

HTML Templates via JavaScript Template Literals

Css Tricks - Mon, 09/11/2017 - 4:43am

You know those super cool backticks-for-strings in new JavaScript?

let emotion = `happy`; let sentence = `Chris is feeling ${emotion}`;

Besides the variable interpolation in there being mighty handy, the do multi-line strings wonderfully, making them great for chunks of HTML:

const some_html = ` <div class="module"> <h2>${data.title}</h2> <p>${data.content}</p> </div> `;

That doesn't look overly different than JSX does it?! Maybe we'd do something like that as a React component:

class MyModule extends React.Component { render() { return <div class="module"> <h2>{this.props.title}</h2> <p>{this.props.content}</p> </div>; } }

But what if we don't really need React, or any other fairly-large-ish JavaScript framework?

What if the only thing we want is the ability to render HTML templates and also really efficiently re-render them when we need to, like React is known for?

As far as I understand it, that's what projects like lit-html are for. As I write, it's a pretty new library from Google and the Polymer folks.

It allows you to define an HTML template with regular template literals, like this:

import { html, render } from './lit-html.js'; const helloTemplate = (data) => html` <div class="module"> <h2>Hello ${}!</h2> <p>${data.content}</p> </div> `;

Then you call the render function, passing it that template, the data, and where you want it rendered:

let data = { name: "Chris", content: "Just trying to figure stuff out." } render(helloTemplate(data), document.body);

Then say the data changes... you call render again: = "Sammy"; render(helloTemplate(data), document.body);

And this is where lit-html shines. It's smart enough to only update the parts of the DOM it needs to.

Here's a little comparison where some data is changed, then the templates re-rendered. If we innerHTML the whole thing, well, the entire DOM is changed. With lit-html it just changes smaller inner parts.

Here's a little video where you can see the DOM-updating difference:

lit-html on the left, "regular" on the right. Demo project.

There is another project along these lines too. I don't know quite enough to judge, but it's a bit older and I believe it's a bit more robust. It's called HyperHTML.

HyperHTML also allows you to create templates and render them. And most importantly rerender them efficiently.

Here's a demo where the data comes from the Quotes on Design API and inserted into a template:

See the Pen Trying HyperHTML by Chris Coyier (@chriscoyier) on CodePen.

Kinda cool that these mini-libraries exist that do useful things for us, so when situations arise that we want a feature that a big library has, but don't want to use the whole big library, we got smaller options.

HTML Templates via JavaScript Template Literals is a post from CSS-Tricks

Css Tricks - Sun, 09/10/2017 - 10:34am

This little website pulls in all the main stories from CNN and strips almost everything from the design; styles, images, fonts, ads, colors. Nada, zilch, gone. At first it looks like nothing but hypertext and it feels like an extraordinary improvement but Sam Saccone made a thread about potential improvements that the team could use to make that experience even faster such as server side rendering and replacing the React framework with something smaller, like Preact.

Either way this approach to news design is refreshing. However, I can’t find anything more about the the motivations for building this version of besides the announcement on Twitter. It would certainly be fascinating to learn if CNN built this specifically for people caught in disastrous situations where battery life and load time might be a serious matter of life and death.

Direct Link to ArticlePermalink is a post from CSS-Tricks

Compilers are the New Frameworks

Css Tricks - Sat, 09/09/2017 - 11:33am

Tom Dale:

Increasingly, the bytes that get shipped to browsers will bear less and less resemblance to the source code that web developers write.

Indeed. I suspected the same:

Because performance matters so much and there is so much opportunity to get clever with performance, we'll see innovation in getting our code bases to production. Tools like webpack (tree shaking, code splitting) are already doing a lot here, but there is plenty of room to let automated tools work magic on how our code ultimately gets shipped to browsers.

Tom also says:

This is a loss in some ways (who else got their web development start with View Source?) but is a huge win for users, particularly in emerging markets.

It seems to me today's world of GitHub, StackOverflow, and the proliferation of learning resources more than make up for learning via our own website spelunking, not to mention how insightful today's DevTools are, even if what they are looking at isn't hand-authored.

Direct Link to ArticlePermalink

Compilers are the New Frameworks is a post from CSS-Tricks

6 Months of Working Remotely Taught Me a Thing or Ten

Css Tricks - Fri, 09/08/2017 - 1:08pm

Peter Anglea writes up his key takeaways after six months on the job with a new front-end position. His points ring true to me as a remote worker and the funny thing is that each one of the suggestions is actually applicable to anyone in almost any front-end job, whether it happens to be in-house or remote.

The full post is worth reading, though the list breaks down to:

  1. Be as available as possible
  2. Communicate clearly
  3. Go out of your way to be human
  4. Offer praise and positive sentiments early and often
  5. Create a comfortable space conducive to productivity
  6. Put your pants on
  7. Go outside
  8. Turn on your camera
  9. Work on more than one project at a time
  10. Take advantage of the perks… and be responsible

One item I would add to the list is to manage up in day-to-day conversations. In other words, give frequent and regular updates with examples of progress so that your client/boss/whomever has no doubt that you are being productive from afar. I suppose that goes along with "communicate clearly" but takes it one step further.

Direct Link to ArticlePermalink

6 Months of Working Remotely Taught Me a Thing or Ten is a post from CSS-Tricks

The average web page is 3MB. How much should we care?

Css Tricks - Fri, 09/08/2017 - 1:07pm

Tammy Everts with a deep dive into the average page size, which seems to grow year in and year out.

It's a little perplexing that the average page size trends up each year as performance has become a growing concern on the forefront of our minds, but Tammy has keen insights that are worth reading because she suggests that user experience isn't always about page size and that bloat is far from the only metric we should be concerned.

Correlating page size with user experience is like presenting someone with an entire buffet dinner and assuming that it represents what they actually ate. To properly measure user experience, we need to focus on the content – such as the navbar or hero product image – that users actually want to consume. The best performance metric for measuring user experience is one that measures how long the user waits before seeing this critical content.

Spot on. There is such a thing as making intentional use of file size, depending on whether or goal is super fast load times or communicating an idea. Not that the two are mutually exclusive, but the trade-off can certainly exist.

Direct Link to ArticlePermalink

The average web page is 3MB. How much should we care? is a post from CSS-Tricks

Syndicate content
©2003 - Present Akamai Design & Development.