CSS-Tricks

Subscribe to CSS-Tricks feed
Tips, Tricks, and Techniques on using Cascading Style Sheets.
Updated: 4 hours 18 min ago

Gotchas When Publishing Modules in npm and Bower

Tue, 02/20/2018 - 14:21

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

The Red Reveal: Illusions on the Web

Mon, 02/19/2018 - 20:24

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

Mon, 02/19/2018 - 14:11

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

Fri, 02/16/2018 - 19:46

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

Fri, 02/16/2018 - 15:05

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

Your Sketch library is not a design system redux

Fri, 02/16/2018 - 01:31

I really like this post by Brad Frost about what is and isn’t a design system, particularly when he de-emphasizes the importance of tools when it comes to that sort of work :

...components living inside static design tools like Sketch isn’t itself a design system. Pardon my clickbait. Perhaps a better title would have been “Your Sketch library is not a(n entire) design system.”

No doubt tools like Sketch are super valuable, and having a set of reusable components inside them helps design teams establish thoughtful and consistent UIs. However, a Sketch library is just one piece of the design system puzzle. A design system also can include other puzzle pieces like:

  • Design principles
  • UX guidelines
  • Development guidelines
  • Coded UI components
  • Component guidelines, usage, and details
  • Page templates
  • User flows
  • Design tools
  • Dev tooling
  • Code repositories
  • Voice and tone guidelines
  • Implementation guides
  • Contribution processes
  • Team structure
  • Resources (internal and external)
  • Other guidelines/resources/tools/process

I’ve been mulling this post over the past couple of days and I’ve started to think of design systems as much more than a suite of tools. In fact, I’m starting to think that folks who work on design systems should start to de-emphasize how important specific tools are and focus much more on the community-building aspects of the work instead.

Direct Link to ArticlePermalink

Your Sketch library is not a design system redux is a post from CSS-Tricks

​Wix.com: Make the Web Your Playground

Thu, 02/15/2018 - 17:34

(This is a sponsored post.)

Here's something you should consider having: your own professional website. The only thing you'll need to get started is your imagination, a little free time, and an innovative website builder.

Wix is the world's most technologically advanced website builder. Sign up for Wix, choose a template, and start customizing it. Whether you’re a novice, a business owner, a sophisticated designer, or a professional website builder, you’ll have full control of your website - from design prototyping to production.

Wix takes care of all the heavy lifting. You get reliable, safe, secure hosting that you'll never need to worry about. You get a custom domain name and email. To get started, all you need is a computer and a little time.

Don't underestimate what you can do with Wix. There are all kinds of advanced design features and functionality if that's something you need. The web is your playground. We’ve come along way from the website building platforms of the 90s. Now, you can create any kind of website you want and even collaborate with friends or coworkers.

Save yourself some time and head over to Wix.com to get started.

Direct Link to ArticlePermalink

​Wix.com: Make the Web Your Playground is a post from CSS-Tricks

CSS Basics: Styling Links Like a Boss

Thu, 02/15/2018 - 14:45

The web was founded on links. The idea that we can click/tap a link and navigate from one web page to another is how surfin' the web become a household phrase.

Links in HTML even look different from regular text without any CSS styling at all.

See the Pen Default Link by CSS-Tricks (@css-tricks) on CodePen.

They are blue (purple if visited). They are underlined. That's a link in it's purest form.

But what if we want to change things up a bit? Perhaps blue doesn't work with your website's design. Maybe you have an aversion to underlines. Whatever the reason, CSS lets us style links just we can any other element. All we need to do is target the <a> element in our stylesheet.

Want to use a different font, change the color, remove the underline and make it all uppercase? Sure, why not?

a { color: red; text-decoration: none; text-transform: uppercase; }

See the Pen Link With Some Style by Geoff Graham (@geoffgraham) on CodePen.

Now we're cooking with gas! But why stop there? Let's look at a few other ways we can style links to complete the experience.

Style Each Link State

Links have different states, meaning they adapt when we interact with them on a webpage. There are three additional states of a link that are worth considering anytime we change the default style of links:

  • Hover (:hover): When the mouse cursor is place on top of the link without a click
  • Visited (:visited): The appearance of a link that the user has clicked on the page before when the mouse cursor is not on top of it
  • Active (:active): When the link is in the process of being clicked. It might be super quick, but this is when the mouse button has been depressed and before the click is over.

Here is the same link we have been looking at. First, try hovering your mouse on top of it without clicking and notice that it becomes underlined. Then, click on the link, but leave your mouse button clicked down for a little bit to see how the active style changes the color of the link to black. Finally, let up on the mouse button and the link should turn purple before it's technically been visited.

See the Pen Link With Styled States by Geoff Graham (@geoffgraham) on CodePen.

Links seem like a simple concept, but boy do they have a lot going on—and CSS gives us some incredible power to customize the experience!

Links as Buttons

While there is some debate about it, we can use CSS to make a text link look like a button.

Like other HTML elements, CSS can add background colors and padding to links that allow us to create the appearance of a button. Here's our link using those techniques:

a { background-color: red; color: white; padding: 1em 1.5em; text-decoration: none; text-transform: uppercase; }

See the Pen Link as a Button by CSS-Tricks (@css-tricks) on CodePen.

Great! Now, let's use the state-altering powers we learned in the last section to make our faux-button more interactive. We'll make the button dark gray on hover, black on active, and light gray on visit:

a { background-color: red; color: white; padding: 1em 1.5em; text-decoration: none; text-transform: uppercase; } a:hover { background-color: #555; } a:active { background-color: black; } a:visited { background-color: #ccc; }

See the Pen Link as a Button With Styled States by Geoff Graham (@geoffgraham) on CodePen.

Styling a link as a button and taking advantage of the states allows us to make some pretty cool effects. For example, let's create a button with some depth that appears to get pressed when it's active and pop back up when the click is done.

See the Pen Link as a 3D Button by Geoff Graham (@geoffgraham) on CodePen.

Oh, and Cursors!

We've gone into pretty great depth on style links, but there is one more component to them that we cannot ignore: the cursor.

The cursor indicates the position of the mouse on the screen. We're pretty used to the standard black arrow:

The standard mouse cursor arrow

We can change the arrow to a hand pointer on it's hover (:hover) state so that it's easier to see that the link indicates it is an interactive element:

Using cursor:
pointer; provides an interactive cue. a:hover { cursor: pointer; }

See the Pen Link as a 3D Button With Pointer by Geoff Graham (@geoffgraham) on CodePen.

Whew, that's much nicer! Now, we have a pretty fancy link that looks like a button with proper interactive cues.

Leveling Up

We've covered quite a bit of ground here, but it merely scratches the surface of how we can control the style of links. If you're ready to level up, then here are a few resources you can jump into from here:

  • Mailto Links - A good reference for linking up email addresses instead of webpages.
  • The Current State of Telephone Links - Did you know you can link a phone number? Well, here's how.
  • Cursor - The CSS-Tricks reference guide for customizing the cursor.
  • When to Use the Button Element - If you're wondering about the difference between a link button and a traditional form button, then this is a good overview with suggestions for which is better for specific contexts.
  • Button Maker - A free resource for generating the CSS for link buttons.

CSS Basics: Styling Links Like a Boss is a post from CSS-Tricks

CSS Basics: Using Multiple Backgrounds

Wed, 02/14/2018 - 20:53

With CSS, you can control the background of elements. You can set a background-color to fill it with a solid color, a background-image to fill it with (you guessed it) an image, or even both:

body { background-color: red; background-image: url(pattern.png); }

Here's an example where I'm using an SVG image file as the background, embedded right in the CSS as a data URL.

See the Pen background color and image together by Chris Coyier (@chriscoyier) on CodePen.

That's just a single image there, repeated, but we can actually set multiple background images if we want. We do that by separating the values with commas.

body { background-image: url(image-one.jpg), url(image-two.jpg); }

If we leave it like that, image-one.jpg will repeat and entirely cover image-two.jpg. But we can control them individually as well, with other background properties.

body { background-image: url(image-one.jpg), url(image-two.jpg); background-position: top right, /* this positions the first image */ bottom left; /* this positions the second image */ background-repeat: no-repeat; /* this applies to both images */ }

See how background-position also has comma-separated values? Those will apply individually to each image respectively. And then how background-repeat has only one value? We could have done two values in the same way, but by using just one value, it applies to both.

Here's an example using four separate images, one in each corner, offset by a smidge:

See the Pen Example of multiple backgrounds by Chris Coyier (@chriscoyier) on CodePen.

It's too bad you can't rotate or flip background images or else we could have used just one. We can rotate and flip entire elements (or psuedo elements) though, so in cases like that, we can get away with using a single image!

See the Pen Flipping Image So You Can Use Just One by Chris Coyier (@chriscoyier) on CodePen.

Just a few other things to be aware of here:

  1. The stacking order of multiple background is "first is on top."
  2. Gradients are applied through background-image, so they can be used as part of all this. For example, you could set a transparent gradient over a raster image.

See the Pen Tinted Image w/ Multiple Backgrounds by Chris Coyier (@chriscoyier) on CodePen.

CSS Basics: Using Multiple Backgrounds is a post from CSS-Tricks

CSS Basics: The Second “S” in CSS

Wed, 02/14/2018 - 14:14

CSS is an abbreviation for Cascading Style Sheets.

While most of the discussion about CSS on the web (or even here on CSS-Tricks) is centered around writing styles and how the cascade affects them, what we don't talk a whole lot about is the sheet part of the language. So let's give that lonely second "S" a little bit of the spotlight and understand what we mean when we say CSS is a style sheet.

The Sheet Contains the Styles

The cascade describes how styles interact with one another. The styles make up the actual code. Then there's the sheet that contains that code. Like a sheet of paper that we write on, the "sheet" of CSS is the digital file where styles are coded.

If we were to illustrate this, the relationship between the three sort of forms a cascade:

The sheet holds the styles.

There can be multiple sheets all continuing multiple styles all associated with one HTML document. The combination of those and the processes of figuring out what styles take precedence to style what elements is called the cascade (That first "C" in CSS).

The Sheet is a Digital File

The sheet is such a special thing that it's been given its own file extension: .css. You have the power to create these files on your own. Creating a CSS file can be done in any text editor. They are literally text files. Not "rich text" documents or Word documents, but plain ol' text.

If you're on Mac, then you can fire up TextEdit to start writing CSS. Just make sure it's in "Plain Text" mode.

If you're on Windows, the default Notepad app is the equivalent. Heck, you can type styles in just about any plain text editor to write CSS, even if that's not what it says it was designed to do.

Whatever tool you use, the key is to save your document as a .css file. This can usually be done by simply add that to your file name when saving. Here's how that looks in TextEdit:

Seriously, the choice of which text editor to use for writing CSS is totally up to you. There are many, many to choose from, but here are a few popular ones:

You might reach for one of those because they'll do handy things for you like syntax highlight the code (colorize different parts to help it be easier to understand what is what).

Hey look I made some files completely from scratch with my text editor:

Those files are 100% valid in any web browser, new or old. We've quite literally just made a website.

The Sheet is Linked Up to the HTML

We do need to connect the HTML and CSS though. As in make sure the styles we wrote in our sheet get loaded onto the web page.

A webpage without CSS is pretty barebones:

See the Pen Style-less Webpage by Geoff Graham (@geoffgraham) on CodePen.

Once we link up the CSS file, voila!

See the Pen Webpage With Styles by Geoff Graham (@geoffgraham) on CodePen.

How did that happen? if you look at the top of any webpage, there's going to be a <head> tag that contains information about the HTML document:

<!DOCTYPE html> <html> <head> <!-- a bunch of other stuff --> </head> <body> <!-- the page content --> </body> </html>

Even though the code inside the <head> might look odd, there is typically one line (or more, if we're using multiple stylesheets) that references the sheet. It looks something like this:

<head> <link rel="stylesheet" type="text/css" href="styles.css" /> </head>

This line tells the web browser as it reads this HTML file:

  1. I'd like to link up a style sheet
  2. Here's where it is located

You can name the sheet whatever you want:

  • styles.css
  • global.css
  • seriously-whatever-you-want.css

The important thing is to give the correct location of the CSS file, whether that's on your web server, a CDN or some other server altogether.

Here are a few examples:

<head> <!-- CSS on my server in the top level directory --> <link rel="stylesheet" type="text/css" href="styles.css"> <!-- CSS on my server in another directory --> <link rel="stylesheet" type="text/css" href="/css/styles.css"> <!-- CSS on another server --> <link rel="stylesheet" type="text/css" href="https://some-other-site/path/to/styles.css"> </head> The Sheet is Not Required for HTML

You saw the example of a barebones web page above. No web page is required to use a stylesheet.

Also, we can technically write CSS directly in the HTML using the HTML style attribute. This is called inline styling and it goes a little something like this if you imagine you're looking at the code of an HTML file:

<h1 style="font-size: 24px; line-height: 36px; color: #333333">A Headline</h1> <p style="font-size: 16px; line-height: 24px; color: #000000;">Some paragraph content.</p> <!-- and so on -->

While that's possible, there are three serious strikes against writing styles this way:

  1. If you decide to use a stylesheet later, it is extremely difficult to override inline styles with the styles in the HTML. Inline styles take priority over styles in a sheet.
  2. Maintaining all of those styles is tough if you need to make a "quick" change and it makes the HTML hard to read.
  3. There's something weird about saying we're writing CSS inline when there really is no cascade or sheet. All we're really writing are styles.

There is a second way to write CSS in the HTML and that's directly in the <head> in a <style> block:

<head> <style> h1 { color: #333; font-size: 24px; line-height: 36px; } p { color: #000; font-size: 16px; line-height: 24px; } </style> </head>

That does indeed make the HTML easier to read, already making it better than inline styling. Still, it's hard to manage all styles this way because it has to be managed on each and every webpage of a site, meaning one "quick" change might have to be done several times, depending on how many pages we're dealing with.

An external sheet that can be called once in the <head> is usually your best bet.

The Sheet is Important

I hope that you're starting to see the importance of the sheet by this point. It's a core part of writing CSS. Without it, styles would be difficult to manage, HTML would get cluttered, and the cascade would be nonexistent in at least one case.

The sheet is the core component of CSS. Sure, it often appears to play second fiddle to the first "S" but perhaps that's because we all have an quiet understanding of its importance.

Leveling Up

Now that you're equipped with information about stylesheets, here are more resources you jump into to get a deeper understanding for how CSS behaves:

CSS Basics: The Second “S” in CSS is a post from CSS-Tricks

Observable

Tue, 02/13/2018 - 20:05

Observable launched a couple of weeks ago. As far as I understand, it’s sort of like a mix between CodePen and Medium where you create "notebooks" for exploring data, making nifty visualizations.

Check out this collection of visualizations using map integrations as an example. The entries are not only nice demos of the libraries or technology being used (i.e. D3, Google Maps, Leaflet, etc.), but also make for some interesting infographics in themselves.

In a note about this interesting new format, founder Mike Bostock describes a notebook as “an interactive, editable document defined by code. It’s a computer program, but one that’s designed to be easier to read and write by humans.”

All of this stuff riffs on a lot of Mike’s previous work which is definitely worth exploring further if you’re a fan of complex visualizations on the web.

Direct Link to ArticlePermalink

Observable is a post from CSS-Tricks

CSS Grid Layout Module Level 2

Tue, 02/13/2018 - 20:05

The second iteration of CSS Grid is already in the works and the public editor's draft was released last week! While it is by no means the final W3C recommendation, this draft is the start of discussions around big concepts many of us have been wanting to see since the first level was released, including subgrids:

In some cases it might be necessary for the contents of multiple grid items to align to each other. A grid container that is itself a grid item can defer the definition of its rows and columns to its parent grid container, making it a subgrid. In this case, the grid items of the subgrid participate in sizing the grid of the parent grid container, allowing the contents of both grids to align.

The currently defined characters of subgrid items are particularly interesting because they illustrate the differences between a subgrid and its parent grid. For example:

The subgrid is always stretched in both dimensions in its subgridded dimension(s): the align-self/justify-self properties on it are ignored, as are any specified width/height constraints.

In addition to subgrids, aspect-ratio-controlled gutters and conformance are also defined in the draft and worth a read. It's great to see so much momentum around grids!

Direct Link to ArticlePermalink

CSS Grid Layout Module Level 2 is a post from CSS-Tricks

CSS Basics: Using Fallback Colors

Tue, 02/13/2018 - 14:25

Something you very much want to avoid in web design is unreadable text. That can happen when the background color of an element is too close or exactly the color of the text. For instance:

.header { background-color: white; color: white; }

Which could lead to text that's there, but invisible.

This is ... very bad.

You'd never do that on purpose of course! The trouble is it can sneak up on you. For one thing, the default background-color is transparent, so without setting any background the background of an element is probably white.

More commonly, you're using a background-image that makes the background a different color, and you're setting white text on top of that.

header { background-image: url(plants.jpg); color: white; }

Under perfect circumstances, this is all good:

But let's take a look at what it looks like while the website is loading over a very common "Slow 3G" internet connection:

There's no reason our dear visitor needs to wait to discover the incredible savings awaiting them this Sunday! Fortunately, a tiny bit of CSS solves this.

header { background-color: black; background-image: url(plants.jpg); color: white; }

The black background color will ensure the white text will be visible while the image loads (or if it never loads at all!). Getting slightly fancier, we could use a color used in the image. I like a little app called Frank DeLoupe for helping me pluck a color from anywhere on my screen. Then I'll use that color as the fallback color using the shorthand syntax for backgrounds:

header { background: #334C23 url(plants.jpg); color: white; }

Much much better.

This kind of thing takes very little effort, improves your design's resiliency and UX, and I think you'll find becomes are part of your CSS muscle memory the more you write CSS.

Another related topic here, since we're working with a photograph, is the idea of a "Progressive JPG." Photoshop has the ability to save a JPG in this format. This changes how the displays as it's coming across the network. Here's a comparison video:

A low-res version of the image loads into place first, and it becomes higher quality as more of the image loads.

Perhaps a more desirable loading experience, but not a replacement for a fallback color.

Leveling up!

Images are one of the heaviest parts of websites, and loading techniques for them are a big topic in web performance. Here are some more related to things to think about:

CSS Basics: Using Fallback Colors is a post from CSS-Tricks

Web Animation Workshops Dates for 2018 Announced

Mon, 02/12/2018 - 17:38

"I'm getting a raise!"

This was my favorite quote from last year's Web Animation Workshops, as Val and I covered performance, tooling, and creating animations for SVG, CSS, JS and React.

Now we're gearing up for another round of Web Animation Workshops in 2018! But we're only offering two workshops this time since both of us have moved away from full-time consulting.

The aim of these workshops is to level up your animation skills in just two days and equip you with a full understanding of animation concepts without having to rely on copying and pasting code from other people in your web applications.

These are the dates and locations:

  • Chicago: March 19 - 20
  • Brighton, UK: July 9 - 10

We're already out of early bird tickets for Chicago and space is limited, so grab yours quickly before they sell out.

We'll see you there!

Direct Link to ArticlePermalink

Web Animation Workshops Dates for 2018 Announced is a post from CSS-Tricks

CSS Basics: The Syntax That Matters & The Syntax That Doesn’t

Mon, 02/12/2018 - 14:28

When you're starting to play around with CSS at the very beginning, like any other language, you have to get used to the syntax. Like any syntax, there are a bunch of little things you need to know. Some characters and the placement of them is very important and required for the CSS to work correctly. And some characters are more about clean looking code and generally followed standards but don't matter for the CSS to work.

First, so we have the terminology down:

A CSS ruleset consists of a selector and delcaration(s) wrapped in curly braces. Important: Braces

All CSS rulesets must have opening and closing curly braces:

braces.header { padding: 20px;}.header padding: 20px;}.header { padding: 20px;}.header padding: 20px;

If you miss the opening brace, CSS will keep reading as if the next bit of text is still part of the selector. Then it's likely to find a character like : which are invalid as part of a selector and break. Breaking likely means it will screw up itself and the next ruleset, and recover after that.

Missing a closing brace is a bit worse in that it's likely to mess up the rest of the entire CSS file unless it somehow finds a double closing brace and can resolve that first missing one.

Overall point: braces are very important!

Preprocessing languages like Sass and Less offer a syntax feature called nesting. This can be convenient, but note that when these preprocessors run and produce CSS, that nesting is removed because CSS by itself doesn't support that. If you copy nested CSS into regular CSS, you'll have problems with the braces.

Sometimes Important: Spaces

There are just a few places that spaces are important in CSS. One of the most imortant is in selectors. One space in a selector means you're selecting descendants of the previous part of the selector. The selector body p means "select p elements that are descendants of the body element". That space means a lot. Hopefully it's clearly different than bodyp which won't select anything (there is no <bodyp> element). But it's not different from body p. Multiple spaces mean the same as one space.

spacesbody ul libodyulli.header .title.header .title.header .title.header.title≠≠=

You can't put spaces in properties, function names, or anywhere you name things. Adding spaces in those situations effectively changes the names, breaking them.

spaces-3background-image: url(tiger.jpg);background - image: url(tiger.jpg);background-image: url (tiger.jpg);@keyframes goRoundAndRound { }@keyframes go-round-and-round { }@keyframes go round and round { }:root { --theme main: red; --theme-second: red;}body { background: var(--theme main); background: var(--theme-second);}

Other than that, spacing doesn't matter much in CSS.

spaces_1.header { padding: 20px;}.header { padding:20px; } .header {padding: 20px; }.header{padding: 20px; }.header{ padding: 20px;}.header{padding:20px;}

I'd encourage you to be consistent with your spacing, and produce clean and readable CSS. You might want to reference some CSS style guides out there for some formatting best practices.

Even the !important rule in CSS, which comes after a the value in a delcaration like body { background: white !important; } doesn't have any spacing requirements. It could have any amount of space before it, or none.

The removing of space in CSS is actually a best practice for performance, so you might notice that when peeking at the raw CSS of websites in production.

You're better off leaving that minification of CSS to a tool that processes your CSS for you, leaving the original alone. We'll have to cover the options for that in other post.

Mostly Important: Semicolons

Each declaration in a ruleset (a property and value pair) ends in a semicolon. That semicolon is required, otherwise CSS will keep reading the next property as if it's part of the value of the previous declaration.

semicolons.header { padding: 20px; max-width: 600px; background: black; color: white}.header { padding: 20px; max-width: 600px background: black; color: white;}

You can leave off the semicolon on the last declaration in a ruleset. I'd warn that doing so manually will cause more trouble than it's worth, and best left to minification tools.

Important: Avoiding Stray Characters

This is important in any language. Every character in code matters, so random other characters will almost certainly break things.

extra-chars.header { padding: 20px;}.header { { padding: 20px;}.header { padding: ~20px;}.header { /padding: 20px;}

Not Important: Line Breaks

A line break is treated like any other white space in CSS, so feel free to use them as needed, as long as it doesn't break any other spacing rule like we talked about above.

line-breaks.bar { background-image: url(texture.png), url(tiger.jpg); }.button::after { content: ">";} .header { box-shadow: 0 0 5px rgba(0, 0, 0, 0.5), 20px 2px 5px -5px rgba(0, 0, 0, 0.5);}

All in all, CSS syntax isn't so hard. Good luck!

CSS Basics: The Syntax That Matters & The Syntax That Doesn’t is a post from CSS-Tricks

Stimulus

Sat, 02/10/2018 - 23:32

A modest JavaScript framework for the HTML you already have.

This will appeal to anyone who is apprehensive about JavaScript being required to generate HTML, yet wants a modern framework to help with modern problems, like state management.

I wonder if this would be a good answer for things like WordPress or CraftCMS themes that are designed to be server side but, like any site, could benefit from client-side JavaScript enhancements. Stimulus isn't really built to handle SPAs, but instead pair with Turbolinks. That way, you're still changing out page content with JavaScript, but all the routing and HTML generation is server side. Kinda old school meets new school.

Direct Link to ArticlePermalink

Stimulus is a post from CSS-Tricks

Article Performance Leaderboard

Sat, 02/10/2018 - 14:30

A clever idea from Michael Donohoe: pit websites against each other in a performance battle! Donohoe is a long-time newsroom guy, so this is specifically about article pages for major publications.

Lets state the obvious, this is an imperfect and evolving measure and the goal is to foster discussion and rivalry in making our pages better, faster, and lighter. Bear in mind this was built as an internal tool at Hearst Newspapers to track changes as we rollout our new Article template on mobile for SFGate and eventually all sites (SF Chronicle, Houston Chronicle, Times Union, etc).

Developers, designers, and product need to talk more on how to achieve this. A 1,700 word article might weigh 10KB but by the time you load HTML, JS, CSS, images, 3rd-parties, and ads, it can range between 2MB to 8MB depending on the web site. Bear in mind, the first Harry Potter ebook is 1.1MB and that includes cover art.

Interested in how it works? Learn about how to use the WebPageTest API or even spin up a service of your own.

Direct Link to ArticlePermalink

Article Performance Leaderboard is a post from CSS-Tricks

PixelSnap

Fri, 02/09/2018 - 15:06

Forever I've used the macOS Command-Shift-4 screenshot utility to measure things. Pressing it gets you a little crosshairs cursor which you can click-and-drag to take a screenshot but, crucially, has little numbers that tell you the width/height of the selection in pixels. It's crude, but ever so useful.

See those teeny-tiny numbers in the bottom-right? So useful, even if they are tough to read.

PixelSnap is one of those apps that, once you see it, you're like OMG that's the best idea ever. It's the same kind of interaction (key command, then mouse around), but it's drawing lines between obvious measurement points in any window at all. Plus it has this drag around and area and snap to edges thing that's just as brilliant. Instant purchase for me.

The Product Hunt newsletter said:

Two teenage makers launched PixelSnap, a powerful design tool to measure every pixel on your screen. Hit #1 on Product Hunt, and over $5,000 in sales within 24 hours of their launch. &#x1f4dd;✨

Hey, even cooler!

Direct Link to ArticlePermalink

PixelSnap is a post from CSS-Tricks

Direction Aware Hover Effects

Fri, 02/09/2018 - 14:24

This is a particular design trick that never fails to catch people's eye! I don't know the exact history of who-thought-of-what first and all that, but I know I have seen a number of implementations of it over the years. I figured I'd round a few of them up here.

Noel Delagado

See the Pen Direction-aware 3D hover effect (Concept) by Noel Delgado (@noeldelgado) on CodePen.

The detection here is done by tracking the mouse position on mouseover and mouseout and calculating which side was crossed. It's a small amount of clever JavaScript, the meat of which is figuring out that direction:

var getDirection = function (ev, obj) { var w = obj.offsetWidth, h = obj.offsetHeight, x = (ev.pageX - obj.offsetLeft - (w / 2) * (w > h ? (h / w) : 1)), y = (ev.pageY - obj.offsetTop - (h / 2) * (h > w ? (w / h) : 1)), d = Math.round( Math.atan2(y, x) / 1.57079633 + 5 ) % 4; return d; };

Then class names are applied depending on that direction to trigger the directional CSS animations.

Fabrice Weinberg

See the Pen Direction aware hover pure CSS by Fabrice Weinberg (@FWeinb) on CodePen.

Fabrice uses just pure CSS here. They don't detect the outgoing direction, but they do detect the incoming direction by way of four hidden hoverable boxes, each rotated to cover a triangle. Like this:

Codrops Demo

In an article by Mary Lou on Codrops from 2012, Direction-Aware Hover Effect with CSS3 and jQuery, the detection is also done in JavaScript. Here's that part of the plugin:

_getDir: function (coordinates) { // the width and height of the current div var w = this.$el.width(), h = this.$el.height(), // calculate the x and y to get an angle to the center of the div from that x and y. // gets the x value relative to the center of the DIV and "normalize" it x = (coordinates.x - this.$el.offset().left - (w / 2)) * (w > h ? (h / w) : 1), y = (coordinates.y - this.$el.offset().top - (h / 2)) * (h > w ? (w / h) : 1), // the angle and the direction from where the mouse came in/went out clockwise (TRBL=0123); // first calculate the angle of the point, // add 180 deg to get rid of the negative values // divide by 90 to get the quadrant // add 3 and do a modulo by 4 to shift the quadrants to a proper clockwise TRBL (top/right/bottom/left) **/ direction = Math.round((((Math.atan2(y, x) * (180 / Math.PI)) + 180) / 90) + 3) % 4; return direction; },

It's technically CSS doing the animation though, as inline styles are applied as needed to the elements.

John Stewart

See the Pen Direction Aware Hover Goodness by John Stewart (@johnstew) on CodePen.

John leaned on Greensock to do all the detection and animation work here. Like all the examples, it has its own homegrown geometric math to calculate the direction in which the elements were hovered.

// Detect Closest Edge function closestEdge(x,y,w,h) { var topEdgeDist = distMetric(x,y,w/2,0); var bottomEdgeDist = distMetric(x,y,w/2,h); var leftEdgeDist = distMetric(x,y,0,h/2); var rightEdgeDist = distMetric(x,y,w,h/2); var min = Math.min(topEdgeDist,bottomEdgeDist,leftEdgeDist,rightEdgeDist); switch (min) { case leftEdgeDist: return "left"; case rightEdgeDist: return "right"; case topEdgeDist: return "top"; case bottomEdgeDist: return "bottom"; } } // Distance Formula function distMetric(x,y,x2,y2) { var xDiff = x - x2; var yDiff = y - y2; return (xDiff * xDiff) + (yDiff * yDiff); } Gabrielle Wee

See the Pen CSS-Only Direction-Aware Cube Links by Gabrielle Wee ✨ (@gabriellewee) on CodePen.

Gabrielle gets it done entirely in CSS by positioning four hoverable child elements which trigger the animation on a sibling element (the cube) depending on which one was hovered. There is some tricky stuff here involving clip-path and transforms that I admit I don't fully understand. The hoverable areas don't appear to be triangular like you might expect, but rectangles covering half the area. It seems like they would overlap ineffectively, but they don't seem to. I think it might be that they hang off the edges slightly giving a hover area that allows each edge full edge coverage.

Elmer Balbin

See the Pen Direction Aware Tiles using clip-path Pure CSS by Elmer Balbin (@elmzarnsi) on CodePen.

Elmer is also using clip-path here, but the four hoverable elements are clipped into triangles. You can see how each of them has a point at 50% 50%, the center of the square, and has two other corner points.

clip-path: polygon(0 0, 100% 0, 50% 50%) clip-path: polygon(100% 0, 100% 100%, 50% 50%); clip-path: polygon(0 100%, 50% 50%, 100% 100%); clip-path: polygon(0 0, 50% 50%, 0 100%); Nigel O Toole Demo

Raw JavaScript powers Nigel's demo here, which is all modernized to work with npm and modules and all that. It's familiar calculations though:

const _getDirection = function (e, item) { // Width and height of current item let w = item.offsetWidth; let h = item.offsetHeight; let position = _getPosition(item); // Calculate the x/y value of the pointer entering/exiting, relative to the center of the item. let x = (e.pageX - position.x - (w / 2) * (w > h ? (h / w) : 1)); let y = (e.pageY - position.y - (h / 2) * (h > w ? (w / h) : 1)); // Calculate the angle the pointer entered/exited and convert to clockwise format (top/right/bottom/left = 0/1/2/3). See https://stackoverflow.com/a/3647634 for a full explanation. let d = Math.round(Math.atan2(y, x) / 1.57079633 + 5) % 4; // console.table([x, y, w, h, e.pageX, e.pageY, item.offsetLeft, item.offsetTop, position.x, position.y]); return d; };

The JavaScript ultimately applies classes, which are animated in CSS based on some fancy Sass-generated animations.

Giana

A CSS-only take that handles the outgoing direction nicely!

See the Pen CSS-only directionally aware hover by Giana (@giana) on CodePen.

Seen any others out there? Ever used this on something you've built?

Direction Aware Hover Effects is a post from CSS-Tricks

A Lifetime of Nerdery (Video)

Fri, 02/09/2018 - 13:40

I converted my slides into an article for this talk not too long ago. The video is up now, if that's more your speed:

A Lifetime of Nerdery (Video) is a post from CSS-Tricks

Pages