Basics of CSS Blend Modes

CSS-Tricks

Basics of CSS Blend Modes

Bennett Feely has been doing a good job of showing people the glory of CSS blend modes. There are lots of designerly effects that we're used to seeing in static designs (thanks to Photoshop) that we don't see on the web much, with dynamic content. But that will change as CSS blend modes get more support. I'd like to look at the different ways of doing it, since it's not exactly cut and dry.

CSS Multiple Backgrounds Blend Modes

You can blend background-images together, or blend them with background-color. It's a simple as:

.blended {
  background-image: url(face.jpg);
  background-color: red;
  background-blend-mode: multiply;
}

See the Pen Background Blending by Chris Coyier (@chriscoyier) on CodePen.

Multiply is a nice and useful one, but there is also: screen, overlay, darken, lighten, color-dodge, color-burn, hard-light, soft-light, difference, exclusion, hue, saturation, color, and luminosity. And also normal which reset it.

Adobe (who works on the spec for this stuff, of course) created this Pen for playing with the different possiblities here:

See the Pen CSS Element Background Blend Modes by Adobe Web Platform (@adobe) on CodePen.

A single element can have more than one background, stacked up. Like:

.graphic-or-whatever {
  background:
    url(grid.png),
    url(building.jpg)
}

Those can blend too simply by adding a background-blend-mode.

See the Pen Multiple Background Blending by Chris Coyier (@chriscoyier) on CodePen.

Here's a cool and practical example by Bennett Feely:

See the Pen rxoAc by Bennett Feely (@bennettfeely) on CodePen.

Here's another, which cleverly re-combines a color image separated into Cyan / Magenta / Yellow / Black parts (CMYK). You know that's how offset lithography works in print, right? =)

See the Pen CMY/CMYK Color printing with background-blend-mode by Bennett Feely (@bennettfeely) on CodePen.

Arbitrary HTML Elements Blend Modes

Blending backgrounds together is pretty cool, but personally I'm less excited about that than I am about blending arbitrary HTML elements together. Like a <h1> title over a background, for example. Or even text over text.

I saw this at an airport the other day and snapped a pic because I thought it looked neat and figured I could figure out how to do it on the web:

My first attempt to recreate it, I used opacity. But opacity really dulls the colors and doesn't make those overlapping bits have the extra darkness they should have. CJ Gammon showed me there is a blending property precicely for this purpose: mix-blend-mode.

So to reproduce this:

<h1>hungry?</h1>

Then break it up into s with Lettering.js:

$("h1").lettering();

Then squeeze the letters together with negative letter-spacing, set the mix-blend-mode, and colorize:

h1 {
  font-size: 7rem;
  font-weight: 700;
  letter-spacing: -1.25rem;
}
h1 span {
  mix-blend-mode: multiply;
}
h1 span:nth-child(1) {
  color: rgba(#AB1795, 0.75);
}
/* etc, on coloring */

Compare:

See the Pen Overlapping Letters by Chris Coyier (@chriscoyier) on CodePen.

Like I mentioned, real web text over image is a pretty sweet use case if you ask me:

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

Canvas Blend Modes

The DOM blend mode stuff is most interesting to me, but it should be noted that <canvas> has blend modes as well and it has a bit deeper support (see below for all that).

You set it on the canvas context. So like:

var canvas = document.getElementById('canvas');
var ctx = canvas.getContext('2d');

ctx.globalCompositeOperation = 'multiply';

That value can be any of those I listed above. Here's a simple demo:

See the Pen canvas blend modes by Chris Coyier (@chriscoyier) on CodePen.

And a fancy one where you can see the blending give the demo life:

See the Pen sketch.js Demo by Justin Windle (@soulwire) on CodePen.

SVG Blend Modes

As you might suspect, SVG does have its own mechanism for doing this. One way to do it is to define it within the <svg> itself, and it's fairly complicated:

<svg>
  
  <defs>
    
    <filter id="f1" x="0" y="0" width="1" height="1">
      <feImage xlink:href="#p1" result="p1"/>
      <feImage xlink:href="#p2" result="p2"/>
      <feBlend mode="multiply" in="p1" in2="p2" />
    </filter>
    
    <path id="p1" d='M100 100 L200 100 L200 200 L100 200 Z' fill='#00FFFF'/>
    <path id="p2" d='M150 150 L250 150 L250 250 L150 250 Z' fill='#CC3300'/>
    
  </defs>
  
  <rect width="100%" height="100%" filter="url(#f1)"/>
  
</svg>

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

And a more complex example.

The good news is that mix-blend-mode will work on inline SVG. So if you're using SVG that way, you can target the shapes themselves with classes or whatever and give them whatever blend mode you want.

Here's an example by Bennet that does just that:

See the Pen KDkCj by Bennett Feely (@bennettfeely) on CodePen.

Browser Support

For canvas: Firefox 20+, Chrome 30+, Safari 6.1+, Opera 17+, iOS 7+, Android 4.4+. Worst bad news: No IE.

For HTML/CSS: Firefox 30+, Chrome 35+, Safari 6.1 (apparently not 7?). Not quite as supported as canvas.

At this second, for Chrome, you'll have to run Canary, go to chrome://flags/ and enable "experimental Web Platform features".

This actually it a bit more complicated, so if you really want to dig in and know about support, check out the Support Matrix from Adobe.

Progressive Enhancement

What is nice about blending is that the whole point is designerly effects. If they aren't supported, you can take care to make sure the fallback is still readable. E.g. the whole idea of progressive enhancement.

Here's a recent thought by Jeremy Keith:

It is entirely possible—nay, desirable—to use features long before they are supported in every browser. That’s how we move the web forward.

So one way to do support is to look at the design in a non-supporting browser and if it is still readable/usable, you're good, no further action required.

If the result ends up unreadable/unusable, you could tweak things around until they are, or run a test to determine support and do something specific in the case of non-support.

To test for support, I guess you could do test for the property you want to use:

var supportsMixBlendMode = window.getComputedStyle(document.body).mixBlendMode;

var supportsBackgroundBlendMode = window.getComputedStyle(document.body).backgroundBlendMode;

If the returned value is "normal" (or anything other than undefined) support is there, otherwise not. Then probably apply a class to the <html> element so you can know that and use it anywhere in your CSS to adjust things, Modernizr style. Perhaps they'll even do a test for it in the future.

Unless it's not that simple in which case let me know.

---

Need more ideas? Check out this collection. Happy blending!

---

Basics of CSS Blend Modes is a post from CSS-Tricks

more info...

Confused About REM and EM?

CSS-Tricks

Confused About REM and EM?

Jeremy Church:

While em is relative to the font-size of its direct or nearest parent, rem is only relative to the html (root) font-size.

Jeremy tends to favor em, because of the ability to control an area of a design. As in, scale the type in that specific area relatively. I have tended to like rem because of the ability to scale type across the entire page easily, but I've gotten into issues where that wasn't good enough control so I could see moving back to em for that reason.

Direct Link to Article — Permalink

---

Confused About REM and EM? is a post from CSS-Tricks

more info...

Float Labels with CSS

CSS-Tricks

Float Labels with CSS

You've probably seen this pattern going around. It's an input that appears as if it has placeholder text in it, but when you click/tap into that input, that text moves out of the way and allows you to type there. It's rather clever, I think. Brad Frost has a really good post on it, detailing the pros and cons and such.

Many of the demos I've seen involve JavaScript. The other day I was checking out at Nest.com, saw their technique for it, and I thought of a way I could pull that off without JavaScript. So here we are.

Here's how the Nest.com one looks:

And here's my take:

See the Pen Label Pattern with just CSS by Chris Coyier (@chriscoyier) on CodePen.

It's not quite as sexy as the Nest ones, were the text is fading out as the label is sliding up. Certainly possible with some JavaScript, but we're going to stick with pure CSS here. Still might be possible though. I'll leave that challenge up to you.

Some Quick Reminders

There are two reasons you might consider doing this:

1. It might be able to save space. Because the input and label are combined, it takes up less space. When an input is in focus, you do still need to show both the label and input, but you can get that space by either using some of the space the input was already using, or by growing the area temporarily only for the focused input.


2. It makes the input one big button. Not that inputs aren't already, and not that labels aren't when they have a proper for attribute, but there is something kinda nice about a big rectangle that tells you what it wants that you click/tap. Might make for a nice experience particularly on mobile.

I'd say, generally, that always-visible labels are probably "better" - but this is a clever idea and done right, may be useful occasionally. There is always a risk of screwing this up and hurting accessibility too, so take care. One downside to this pattern: we can't use placeholder in addition to the label, which can be helpful (e.g. a label of "Phone Number" and a placeholder hint of "(555) 555-5555").

The Trick (1 of 3) - The label is the placeholder

There is a <div> that contains both the <label> and <input> (which you need to do anyway because inputs within forms need to be in block level elements) that has relative positioning. That allows absolute positioning within it, which means we can position the label and input on top of each other. If we do that with the input on top, but with a transparent background, you'll be able to see the label right underneath it while still being able click into it.

  <div>
    <input id="name" name="name" type="text" required>
    <label for="name">Your Name</label>
  </div>

form > div {
  position: relative;
}
form > div > label {
  position: absolute;
}

The Trick (2 of 3) - the :focus state and the adjacent sibling combinator

The source order of the <label> and <input> wouldn't matter much here, since semantically they are tied together with the for attribute. But if we put the input first, that means we can leverage it's :focus state and an adjacent sibling combinator (+) to affect the label when it is focused. Similar in concept to the checkbox hack.

input:focus + label {
  /* do something with the label */
}

You can do whatever you want with the label. Just find a cool place to move it and style it that is out of the way of typing in the input. My example had two possibilities: one was making it smaller and moving toward the bottom of the input, the other was moving it to the far right side.

form.go-bottom label {
  position: absolute;
  top: 0;
  bottom: 0;
  left: 0;
  width: 100%;
  transition: 0.2s;
}
form.go-bottom input:focus + label
  top: 100%;
  margin-top: -16px;
}

The Trick (3 of 3) - the :valid state

Once there is actual text in the input, and the input goes back out of focus, it would be very weird (bad) to see the label and the input text on top of each other. Fortunately in CSS there is a :valid selector that works on inputs when they are in a valid state. That valid state can be "any text at all", assuming the only thing that makes it valid is having any value at all, which can be achieved like:

<input type="text" required>

Then remember the only reason you could see the label at all was because the input has a transparent background. To hide it, we can use an opaque background instead:

form input:valid {
  background: white;
}

The rest of this is just fiddling around with design details until you have it just how you like it.

More

The idea originally came from Matt D. Smith, with this design:

• Remember to read Brad Frost's article that covers the pros and cons well.


• A number of people have tackled this with JavaScript: Jeremy Fields, Jim Nielsen, and maman


• As I was looking around for links to put down here, I discovered David Bushell did just about exactly what I've done here.


• Here's a collection of Float Label examples on CodePen.

---

Float Labels with CSS is a post from CSS-Tricks

more info...

Stackicons: Doing More with Icon Fonts

CSS-Tricks

Stackicons: Doing More with Icon Fonts

The following is a guest post by by Parker Bennett. While icon fonts are efficient and easy to use and scaleable and all that, one of the classic "strikes" against them is that the icon can only be one color. Parker has a brand new project that solves that issue in a simple and clever way. I'll let him introduce it for you.

Even though the future of icons will likely be SVG, here in the present, icon fonts still offer a compelling alternative — with super easy styling of color, size, text-shadows, hover effects and more using just CSS. Icon fonts are still awesome.

One big advantage SVG has over icon fonts is full color. But icon fonts don’t have to be limited to just a single color. By overlapping two or more elements we can create unique “multi-color” icons with a contemporary flat look. If you’ve ever done any two-color or screen printing, it’s a similar idea.

I call them Stackicons.

→Dribbble

→Github

For each color, we use a separate pseudo element, then use absolute positioning to stack them on top of each other. (If you want more than two colors, it will cost you a non-semantic span.)

/* @font-face to load icon font... */

/* horizontal button row: inline-block vs float makes positioning easier using text-align */

/* any class that starts with "st-icon-" */
[class^="st-icon-"] {
  display: inline-block;
  vertical-align: top;
  white-space: nowrap;
  /* child elements absolute */
  position: relative;
  /* remove inline-block white-space */
  margin-right: -.16em; /* 5px */
  /* if not already universally applied */
  -moz-box-sizing: border-box;
  -webkit-box-sizing: border-box;
  box-sizing: border-box;
  /* padding here for text, icons replicate this using size and position:absolute - padding makes touch-target bigger */
  padding: 0.143em;
  /* units used in font: 1em = 2048, icons 2400 wide, so icons are 1.171875em (2400/2048). Add padding x2 to get size: */
  height: 1.45788em;
  width: 1.45788em;
  font-size: 1.815em;
  /* text hidden old-school */
  text-align: left;
  text-indent: -9999px; }

/* position:absolute stacks pseudo elements - extra <span> in markup = 2 extra pseudo elements */
[class^="st-icon-"]:before,
[class^="st-icon-"]:after,
[class^="st-icon-"] span:before,
[class^="st-icon-"] span:after {
  display: block;
  position: absolute;
  white-space: normal;
  /* match padding above */
  top: 0.143em;
  left: 0.143em;
  /* undo text hidden */
  text-indent: 0;
  /* inherits size from parent, ems cascade */
  font-size: 1em;
  font-family: "Stackicons-Social";
  font-weight: 400 !important;
  font-style: normal !important;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  font-smoothing: antialiased;
  /* screenreaders */
  speak: none;
  /* transitions here */ }

.st-icon-amazon:before {
  /* character code - unicode private use area */
  content: "\e079"; /* black "a" */
  color: black; }

.st-icon-amazon:hover:before {
  color: #626262; }

.st-icon-amazon:after {
  content: "\e080"; /* orange smile */
  color: #ff9900; }

.st-icon-amazon:hover:after {
  color: #ffbd59; }

Using rgba values, we can even do some color mixing to give us more colors. If we really want to push the limits, we can use -webkit-background-clip: text to give icons a -webkit-linear-gradient background.

Yes, it’s a bit on the hacky side: It takes some design forethought, and the ability to generate an icon font. There are more moving parts to manage. But it also offers a lot of flexibility, especially using Sass variables.

Stackicons

This :hover effect would be hard to do in SVG

Stackicons-Social

To show how it works, I made a free, open source icon font, Stackicons-Social, and created a Sass “Construction Kit” to generate the CSS for both single color icons and “multi-color” versions of over 60 social brands.

Stackicons-Social

icon-onlysquarerounded1rounded2rounded3circle

multi-color

Add This Alt.net Amazon Android Apple Behance Blogger Codepen Delicious Deviant Art Digg Dribbble Dribbble Dropbox Ebay Email Email Evernote Facebook Facebook Flattr Flickr Forrst Foursquare Github Github Gittip Gmail Gmail Google Google+ IMDb Instagram Kickstarter last.fm LinkedIn Microsoft Myspace Pandora Paypal Paypal Picasa Pinboard Pinterest Rdio Reddit RSS ShareThis Skype Slideshare Soundcloud Spotify Stumbleupon Stack Overflow Tumblr Twitter Vimeo Vine Windows Windows 7 WordPress Xing Yahoo Yelp YouTube YouTube YouTube Zerply Search Search Menu Menu Menu More… More

View Stackicons-Social

I also created a range of button shapes in the font, from square to circle (plus icon-only), and have classes that override the shape on the fly. Want circular icons? Just add the .st-shape-circle class. iOS style? .st-shape-rounded3.

Try it on CodePen

Putting It Together with Sass

Behind the scenes, there is a group of .scss _partial files that Sass compiles. If you’re comfortable using Sass you can customize things extensively just by changing variables in this "construction kit":

• fonts-stackicons-social - Path to stackicons-social font.


• colors-social–2014 - Color variables for social brands.


• unicodes-stackicons-social - Font unicode characters abstracted into variables.


• construction-kit-stackicons-social - This is where we generate default values for icon size, margin, padding, shape, color, hover-style, etc. (Play here.)


• css-defaults-stackicons-social - This does the CSS grunt work to create each .st-icon-($brand) class.*


• override-shapes-stackicons-social - Let’s you override the button shape on single-color icons using classes: st-shape-square to st-shape-circle, plus st-shape-icon.*


• override-colors-stackicons-social - Some examples of “color-styles” for single-color icons to demo different options. Lots of extra CSS, so it’s commented out by default.*


• multi-color-kit-stackicons-social.scss - Like “construction-kit” above, but for the .st-multi-color class: generates default shape, color-style, etc.


• multi-color-css-stackicons-social.scss - Like “css-defaults” above, this does the CSS grunt work to generate each multi-color .st-icon-($brand) class.*


• multi-color-override-shapes-stackicons-social - This allows you to change icon shapes using classes on multi-color icons.*

* Because Sass doesn’t allow us to use variables within variables, this uses a lot of @if statements to generate the .st-icon-($brand) classes. Ugly, but marginally maintainable. There are several @each statements, listing the brands to output. Ideally, you would go through and edit these lists to limit the CSS output to only the brands you need.

Rolling Your Own

There are some great free resources for creating icon fonts, including icomoon.io and fontello.com. I use Adobe Illustrator and Glyphs on the Mac. (Glyphs Mini is a lower cost option that limits the units per em to 1000. They also offer student pricing.) To generate the web font versions, I recommend FontPrep, which Brian Gonzalez just made open source. FontSquirrel is another good free option. (If you’re interested in more workflow details, let me know in the comments.)

You should also check out some random dude (P.J. Onori) and his iconic project. He also has some helpful tips on using icon fonts.

As always, if you have any questions, comments, or corrections you can email me at parker@parkerbennett.com.

---

Stackicons: Doing More with Icon Fonts is a post from CSS-Tricks

more info...

How SVG Line Animation Works

CSS-Tricks

How SVG Line Animation Works

I bet all of you have seen that little trick where an SVG path is animated to look like it's drawing itself. It's super cool. Jake Archibald pioneered the technique and has a super good interactive blog post on how it works. Brian Suda wrote about it on 24 Ways. Polygon used it to great effect on a custom designed article and wrote about it. Codrops has some neat examples.

I have very little to add, except my brain just kinda figured it out, so I thought I would explain it one more time the way it clicked for me.

1. You have an SVG shape

2. The shape must have a stroke

3. Strokes can be dashed

We could do that from Illustrator, but we can also do it programatically. Let's target the path with CSS (assuming we're using inline SVG here, or via an <object>) and apply the dash that way.

<svg ...>
  <path class="path" stroke="#000000" ... >
</svg>

.path {
  stroke-dasharray: 20;
}

That gives us dashes of 20px in length.

4. Those dashes could be longer...

.path {
  stroke-dasharray: 100;
}

5. We can also "offset" the stroke, which moves the position of those dashes

Watch as we animate the offset of those long strokes:

That was a simple as:

.path {
  stroke-dasharray: 100;
  animation: dash 5s linear;
}

@keyframes dash {
  to {
    stroke-dashoffset: 1000;
  }
}

6. Imagine a dash so long it covers the entire shape

Nothing really to see, it looks just like the complete shape if it wasn't dashed at all. You just need to make stroke-dasharray a longer value than the length of the stroke.

7. Now offset that stroke so that instead of covering the entire shape, it NOT covers the entire shape.

It will look like the shape isn't there at all.

8. Now animate the stroke offset back to 0

If doing it with CSS, you'll want the animation to have animation-fill-mode of forwards so the final state remains how the animation ends.

.path {
  stroke-dasharray: 1000;
  stroke-dashoffset: 1000;
  animation: dash 5s linear forwards;
}

@keyframes dash {
  to {
    stroke-dashoffset: 0;
  }
}

Tada!

Live Example

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

So why all the JavaScript?

Most of the examples you see of SVG line animations use JavaScript. That's because it's hard to know what the length of that stroke actually is. We just used 1000 in our example because that happens to be about the right length.

You can get that length in JavaScript like:

var path = document.querySelector('.path');
var length = path.getTotalLength();

Then use it however you will. Those articles I linked to at the top go far more into all this, so I'll let you consult those for more fancy stuff. I just wanted to cover the concept so perhaps it can click for you too.

---

How SVG Line Animation Works is a post from CSS-Tricks

more info...

CSS-Tricks Chronicle XVI

CSS-Tricks

CSS-Tricks Chronicle XVI

It's been too long since I've done a Chronicle. I'm going to try and get in the habit again.

---

It's been a pretty rough winter here in Wisconsin. Relentlessly cold and plenty of snow. It's been my first winter back in a number of years and it's as much of a slog as I remember it being. There was some crazy days with a high of like -15°F. I hope to plan more escapes next year than I did this year. My only escape so far has been out to Bend, Oregon for skiing, which was incredibly fun but it sure wasn't much warmer.

---

Fortunately next week I get an escape. I'm headed down for my third trip to Hilton Head Health to keep the weight loss going. I'm kind hoping this will be the last time for me as some much healthier habits are starting to take hold. This time I'm going with my dad, and I hope this kicks off a good journey for him too.

---

After that, the next time I get on a plane will be to An Event Apart Seattle. I've been working on a new talk for this, which I'll use in the rest of my handful of talks in 2014, refining it along the way. It's going to be all about SVG and the simple and practical ways I've been using it.

---

ShopTalk has been going strong this year. We had our 100th episode! We didn't do anything super special, but had Rachel Andrew on and she was a great guest. The next week we had John Resig on and people loved that one.

We have guests and sponsors lined up for months to come so chug'a'lug.

---

As always my primary job is working on CodePen. We've been steadily working on that and have crossed some notable milestones like 100k registered users. We have so many ideas for CodePen. They will all happen in time. I'm finding it interesting how much more effort it takes to maintain software than to build it. Truth be told, new features slow down a bit when so much of our time is spent on maintenance and as those new features touch so many other aspects of the app.

We've released plenty of stuff recently though, including a WordPress plugin, an infastructural change we call Boomerang that helped fix a slew of bugs, and a feature to see details right from the editor.

---

Here on CSS-Tricks, I've actually started tinkering with a new design. Like most design iterations around here (but unlike the last huge one), it will be very incremental. Mostly a simplification both of content presentation and aesthetic. I'd guess I'll have it out within a month or two. Stay tuned!

---

CSS-Tricks Chronicle XVI is a post from CSS-Tricks

more info...

Posting Code Blocks on a WordPress Site

CSS-Tricks

Posting Code Blocks on a WordPress Site

So you've installed WordPress and want to blog about code. Yay! You're a hero and I thank on behalf of myself an coders everywhere. Here's what you'll need to do and think about to actually get publishing blocks of code.

The HTML for a "code block"

There is an element specifically for code: <code>. I'd say it's semantically correct to wrap any and all code in it. Browser's default stylesheets leave it as inline element, and I'd recommend you leave it that way so you can use it within sentences like I did in the last sentence.

But you'll want to use a block-level element to wrap a block of code. <pre> is the perfect element for that, as it naturally retains spacing. "Pre" as in "Preformatted text". Multiple spaces will render as multiple spaces instead of collapsing into a single space as normally happens in HTML. That's perfect for code, because you'll likely want to use indentation in a block of code and you don't want to resort to any   shenanigans.

So:

<pre><code>Your 
   
   block
  
       of

   code
 
 here.</​code></​pre>

Turn off the "Visual" editor

By default, WordPress lets you switch between Visual and Text tabs in the editor.

For you, the Visual editor has to go. You will never use it. You want full control of the text you are writing and want it to stay just how you write it when you save it.

Turn it off under Users > Your Profile

Are you going to blog in Markdown or not?

Here on CSS-Tricks I do not, but if I could go back in time to the beginning I probably would. On most subsequent blogs I've done, I do use Markdown and prefer it. To post a block of code in Markdown, you'll need to indent that code four spaces on every single like, like this:

Yadda yadda yadda. I'm a *paragraph* in Markdown. Here's a [link to Google](http://google.com). Here's a block of code:

    <div>
       <p>I'm some code.</p>
    <div>

Another paragraph here.

Manually doing that is going to get old very fast. So you'll want to replace your editor buttons with Markdown buttons. It looks like the plugin Markdown Quicktags can do that.

What's cool about using Markdown is that you don't have to worry about escaping the code. So those angle-brackets are no rendering threat, Markdown will escape them for you. In other words, all those angle brackets (<) in the HTML example above will be turned into < and thus display on the screen as an angle-bracket, not attempt to be rendered by the browser.

That Markdown example above will be turned into this before it hits the browser:

<p>Yadda yadda yadda. I'm a <em>paragraph</em> in Markdown. Here's a <a href="http://google.com">link to Google</a>. Here's a block of code:</p>

<pre><code>&lt;div&gt;
   &lt;p&gt;I'm some code.&lt;/p&gt;
&lt;div&gt;

<p>Another paragraph here.</p>

If you're interested in blogging in Markdown, you have some options. Jetpack, the Automattic-created and maintained plugin, now offers it as part of it's mega-pack of offerings. At the time being I use WP-Markdown here on CSS-Tricks (I know I said I don't use Markdown, but I do for the Forums and comments, just not blogging).

Two I haven't personally tried are Typewriter and Markdown on Saved Improved.

There is a fairly major limitation here though. Notice that the four-spacing indentation converts into a <pre><code> block, but there was no opportunity there to add attributes to those tags. Attributes (like classes and data-* attributes) are a common need. You might want to use a syntax highlighter (we'll talk about those later) that requires some attributes to do it's thing. Or you might want to identify the code block somehow by language.

GitHub is a big user of Markdown, and they solved this issue by adding the triple-backtick style of code blocks, like this:

```
<div>
  <p>I'm some code.</p>
<div>
```

I'd call this straight up better. It's easier to jump into a code block while writing without having to worry about the indentation thing. Plus code has it's own indentation going on so it's nice to start flush-left with that.

Beyond that, GitHub-flavored Markdown allows you to specify the language right in the Markdown syntax. So our example could be:

```html
<div>
  <p>I'm some code.</p>
<div>
```

Which gives:

<div class="highlight highlight-html">
  <pre>
     <span class="nt">&lt;div&gt;</span>
     hi
     <span class="nt">&lt;/div&gt;</span>
  </pre>
</div>

I'm not sure why it skips the <code> tag and it looks like it does the syntax highlighting server-side with those spans. Just be aware of all that I suppose.

I was able to find wp-gfm which is a GitHub-flavored Markdown plugin for WordPress.

If you go no-Markdown, you'll need to escape the code.

CSS rarely needs escaping, but HTML for sure does, and JavaScript sometimes has HTML in it as well as just about all backend languages, so you might as well just assume you need to escape all code.

You could do it manually by converting all <'s into &lt;'s, but you'll go nutty doing that. You could use a tool like Postable to copy-and-paste blocks to be escaped, but that's slow and tedious too.

I prefer using a plugin called Code Markup for this. It just auto-escaped anything it finds within <code> tags so you just never have to think about it.

Because I use that plugin on this site, I can do stuff like:

<pre data-lang="HTML"><code class="language-markup"><div>
  <p>I'm some code.</p>
<div></​code></​pre>

And it works great. No escaping. Full attribute control.

Handling Syntax Highlighting

Remember that one option for syntax highlighting blocks of code is not syntax highlighting. Certainly that would be the fastest and easiest way. But you might want it. Personally I like it. I like the way it looks. Here's a few options.

What essentially happens with any syntax highlighter is bits of code end up getting wrapped in <span>s with class names that you colorize with CSS. Choosing is a matter of features.

Prism.js

Here on CSS-Tricks, I use (and recommend) Prism by Lea Verou as it works with those right out of the box. It's small, fast, and (my favorite) as rational class names for styling. You choose which languages you want it to support as you download it.

I also use that escaping plugin, meaning I don't need to escape HTML inside code tags, so again that looks like this:

<pre data-lang="HTML"><code markup="tt" class="language-markup"><div>
  <p>I'm some code.</p>
<div></​code></​pre>

That class="language-markup" on the code tag is what Prism picks up on to syntax highlight. It works automatically on all code it finds with that class name pattern by default, but you can use the API instead if you want to do your own thing.

The data-lang attribute on the <pre> tag isn't required, but I might use that in CSS to style the look (and label) the code as HTML. The markup attribute you see in there relates to the escaping plugin. By default it still renders things like <span> and <a> elements, but if you use that attribute with an element-as-value that you don't really plan to use, it will escape those too.

Prettify

An extremely popular one is google-code-prettify. To syntax highlight a block, you put class="prettyprint" on either the code or pre tag.

It's a larger file size than Prism, but one advantage is that it auto-detects language (and supports a ton of languages), so it should work on just about anything without you having to specify it.

Others

Digging around a little, there are plenty more that I can't vouch for but seem like they'll do the trick: Rainbow, SyntaxHighlighter, Chili (jQuery), JSHighlighter, jQuery.Syntax (jQuery), GeSHi, Lighter (MooTools), highlight.js, SHJS, and Pygments (Python).

Deciding

To decide amongst these, you might think about these things:

• What languages do I mostly need to support?


• Do I want to show line numbers?


• Do I need to put links within the code?


• Do I want to be able to highlight parts of the code or lines?


• Do I have legacy code blocks I need to support? What format are they in?


• Is the code easy to copy and paste? Do I want features to help with that?


• Is client-side syntax highlighting OK or do I want it to happen server-side?

Dealing with Legacy Code

If you have a bunch of code blocks on a site already, I'd still recommend choosing a syntax highlighter that you like the features of for current and future use. Then finding a way to make it work for the older blocks.

For instance, let's say I have a legacy code block that is marked up like this:

<pre><code class="javascript">
  var thing = document.getElementById("thing");
</​code></​pre>

That's not the right class name for Prism. So I might use jQuery to do something like:

$("code.javascript")
  .removeClass("javascript")
  .addClass("language-javascript");

And make sure that JavaScript runs before Prism does. I might also take the opportunity to $.trim() the code because, as written above, there is an extra return at the top and bottom which might affect the styling of the code block.

I mean this just as an example. The overall point is: you can manipulate the legacy code blocks as needed to fit the new format.

Third Party Help

When creating the Embedded Pens feature on CodePen, we knew that displaying demos and code in blog posts is kind of a pain in the butt, so we set out to make that easier.

Here's an example of some CSS (complete with a demo) that I'm embedding into this post:

* {
  @include box-sizing(border-box); 
}

section {
  background: #eee;
  max-width: 600px;
  margin: 0 auto;
  padding: 20px;
  overflow: hidden;
}

.module {
  width: 48%;
  min-height: 200px;
  background: white;
  position: relative;
  float: left;
  padding: 20px;
  margin-right: 4%;
  margin-bottom: 4%;
  &:nth-child(even) {
    margin-right: 0;
  }
  box-shadow: 0 1px 3px rgba(black, 0.2);
}

body {
  background: url(http://s.cdpn.io/3/blurry-blue.jpg);
  background-size: cover;
  padding: 30px;
}
 
.come-in {
  transform: translateY(150px);
  animation: come-in 0.8s ease forwards;
}
.come-in:nth-child(odd) {
  animation-duration: 0.6s;
}
.already-visible {
  transform: translateY(0);
  animation: none;
}

@keyframes come-in {
  to { transform: translateY(0); }
}

See the Pen Slide in from bottom boxes by Chris Coyier (@chriscoyier) on CodePen.

I don't need to worry about syntax highlighting, escaping, or anything, and get the benefit of showing the rendered demo as well. Plus, if you choose, we embed the code of your choice right in there so in the case JavaScript doesn't run (e.g. an RSS reader) the code will still be present in semantic tags.

Many of the other code editor sites offer embedded code as well like JSFiddle and JSBin. GitHub Gists can be useful for this too. Perhaps my favorite reason for using third-party tools for this is that you can go update the demo there and the blog post automatically has the new code. You don't have to update stuff in two places. Although I often just plop code directly into posts as well.

---

Do you have your own way of handling code blocks on a WordPress site? Do share.

---

Posting Code Blocks on a WordPress Site is a post from CSS-Tricks

more info...

Sticking Around

CSS-Tricks

Sticking Around

I'll be danged if I can find it but someone tweeted to @CodePen the other day something like: "Is it worth it for me to go PRO? Or are you going to up and shut down one day like so many startups do?" It was a hard question to answer, and not because I'm not sure what the answer is.

It was hard because saying something like "Don't worry, we aren't going away" is a weak and lame answer. Like I looked up how to respond in Corporate Social Media for Dummies!

So instead of a lame answer, I made a note to write up my feelings on the matter. This is that attempt.

CodePen isn't a fly-by-night operation. My plan is to build a business by building and maintaining a good product that is useful to people - and do right by those people.

There will be bugs. We'll screw up sometimes. But we'll always be working toward a better product and a better business. One that the Archiveteam doesn't need to worry about.

I know the only way to prove this is by proving it over time, so day by day we'll be doing that. But I can tell you this isn't some new revelation for me. Over many years I've focused the things I work on. I've stopped working on so many projects and have avoided picking up any new ones. I outsource as much as I can. Long-term work on a just a few things is what feels right to me. I wrote on The Pastry Box "Mediocre ideas, showing up, and persistence."

Don’t get distracted by some other idea and prance away to that tomorrow. Keep doing it until you’ve done everything you set out to do and everyone and their mom knows it.

Persistence is kinda my thing.

---

You're excited about it now, but what happens when the passion fades and you get bored of a project? Historically that tends to not happen to me for the things I work on that I care deeply about. But I suppose it could, in which case I would take care that the project is in good shape to be sustained with minimal effort and otherwise in good hands.

What if you sell it? There are no plans for that and I can't see it happening anytime soon. It could happen someday though, and my top priority would be ensuring a healthy future for it. I have been a part of an acquisition before with Wufoo and now, many years later, Wufoo is still going strong.

---

I was compelled to finally write this as I read Protecting Against Link Rot While Embracing the Future by Tim Murtaugh on A List Apart. Tim lays out a plan to keep embedded code demos healthy in the event that CodePen were to go away. He is 100% right and I'm glad A List Apart is approaching things in that smart future-proof way. It was just weird to read about the theoretical demise of my own project when I feel so strongly about it's own future-proof-ness. So here we are =).

---

Sticking Around is a post from CSS-Tricks

more info...

Test for Support of SVG as img

CSS-Tricks

Test for Support of SVG as img

Browser support for SVG isn't quite as simple as yes or no. In addition to some quirks on how that support plays out, it depends on how that SVG is being used. One common way is right within an image tag, like <img src="image.svg" alt="description">.

How can you detect if a browser supports SVG use in that way?

It's one thing to just know which browsers do. The only real danger zones are IE 8- and Android 2.3. You could do user agent detection, and while I wouldn't want to get too judgey about that, it's generally a bad idea.

I was looking at SVGeezy, a mini JavaScript plugin specifically for helping with SVG-as-img fallbacks. Of course, in order for it to work, it needs to do a feature detect. In the source code, it's a simple a one liner:

supportsSvg: function() {
  return document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Image", "1.1");
}

I had never seen document.implementation.hasFeature ever before, so I asked around a bit, as it seemed a little too good to be true for something I'd never even heard of. Most documentation out there is pretty generic and suggest great browser support, making me even more skeptical.

The deal is: it's pretty much useless. It almost always returns true for everything. Except, apparently, in the case of SVG-as-img, when it's correct. As a skeptic, I went about creating a test to see if this was really true.

The first thing I did was check how Modernizr detects it, as the go-to source for feature detects. Important note here: Modernizr's default SVG test (Modernizr.svg) is not testing SVG-as-img support, it's testing SVG support as an <object> or <embed>. Just be aware of that when using it for fallbacks. Test the right thing (they have tests for all the ways you can use SVG).

They have a test specifically for SVG-as-img that was like this:

Modernizr.addAsyncTest(function () {
  var img = new Image();

  img.onerror = function () {
    addTest('svgasimg', false);
  };
  img.onload = function () {
    addTest('svgasimg', img.width == 1 && img.height == 1);
  };

  // 1px x 1px SVG; must be base64 or URI encoded for IE9... base64 is shorter
  img.src = 'data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==';
});

This creates an new image element, injects a Data URI of a 1x1 SVG image then either waits for it to fail or load correctly.

Obviously different than the hasFeature test, so I created a Pen that showed the results of both methods. Then I tested in all kinds of different browsers. A mixture of those which are known to support SVG-as-img and those that do not. In all cases, the results were identical. Weird, but pretty cool!

The original Modernizr test is what they call an "async" test, meaning it relies upon callback functions to give an answer. Modernizr generally prefers "sync" tests in which as soon as the test is defined it has the right answer.

So, after talking about it with the Modernizr team, it is now the default test for SVG-as-img. It's not quite out in a release yet, so for now you'd have to just run it.

Modernizr.addTest('svgasimg', document.implementation.hasFeature('http://www.w3.org/TR/SVG11/feature#Image', '1.1'));

I'll update this post (and the version we run on CodePen) as soon as it's out.

Thanks to Patrick Kettner for overseeing it getting into Modernizr, Stu Cox for the feedback and OKing the replacement of his original method, Ben Howdle for knowing about the cool hasFeature() and using it in SVGeezy and Mike Taylor for verifying it's usefulness.

Oh, and if you you detect the browser doesn't support SVG-as-img, you'll want to flip out the src for an image format that is supported. Probably the-same-image.png either automatically based on a naming convention or selectively based on a data-* attribute.

---

Test for Support of SVG as img is a post from CSS-Tricks

more info...

Multiple Simultaneous Ajax Requests (with one callback) in jQuery

CSS-Tricks

Multiple Simultaneous Ajax Requests (with one callback) in jQuery

Let's say there is a feature on your website that only gets used 5% of the time. That feature requires some HTML, CSS, and JavaScript to work. So you decide that instead of having that HTML, CSS, and JavaScript on the page directly, you're going to Ajax that stuff in when the feature is about to be used.

We'll need to make three Ajax requests. Since we don't want to show anything to the user until the feature is ready to go (plus they all kinda rely on each other to work right) we need to wait for all three of them to be complete before proceeding.

What's the best way to do that?

Ajax calls in jQuery provide callbacks:

$.ajax({
  statusCode: {
    url: "/feature",
    success: function() {
      // Ajax success
    }
  }
});

Or the "Deferred" way, this time using a shorthand $.get() method:

$.get("/feature/").done(function() {
  // Ajax success
});

But we have three Ajax requests we're needing to perform, and we want to wait for all three of them to finish before doing anything, so it could get pretty gnarly in callback land:

// Get the HTML
$.get("/feature/", function(html) {

  // Get the CSS
  $.get("/assets/feature.css", function(css) {
    
    // Get the JavaScript
    $.getScript("/assets/feature.js", function() {

       // All is ready now, so...

       // Add CSS to page
       $("<style />").html(css).appendTo("head");

       // Add HTML to page
       $("body").append(html);

    });

  });

});

This successfully waits until everything is ready before adding anything to the page. So by the time the user sees anything, it's good to go. Perhaps that makes some of you feel nauseated, but I've done things that way before. At least it makes sense and works. The problem? It's slow.

One request ... wait to be done ... another request ... wait to be done ... another request ... wait to be done ... go.

It would be faster if we could do:

All three requests in parallel ... wait for all three to be done ... go.

We can use a bit of Deferred / Promises action to help here. I'm sure this is some JavaScript 101 stuff to some of you but this kind of thing eluded me for a long time and more complex Promises stuff still does.

In our simple use case, we can use jQuery's $.when() method, which takes a list of these "Deferred" objects (All jQuery Ajax methods return Deferred objects) and then provides a single callback.

$.when(

  // Deferred object (probably Ajax request),

  // Deferred object (probably Ajax request),

  // Deferred object (probably Ajax request)

}.then(function() {

  // All have been resolved (or rejected), do your thing

});

So our callback-hell can be rewritten like:

$.when(
  // Get the HTML
  $.get("/feature/", function(html) {
    globalStore.html = html;
  }),

  // Get the CSS
  $.get("/assets/feature.css", function(css) {
    globalStore.css = css;
  }),

  // Get the JS
  $.getScript("/assets/feature.js")

).then(function() {

  // All is ready now, so...

  // Add CSS to page
  $("<style />").html(globalStore.css).appendTo("head");

  // Add HTML to page
  $("body").append(globalStore.html);

});

Another use case: mustard cutting

My use-case example above is a 5% feature. Keep the page lighter for the 95% of users who don't use the feature, and have it be a relatively quick add-on for those that do.

Another situation might be a cut-the-mustard situation where you add in additional features or content to a page in certain situations, as you decide. Perhaps do a matchMedia test on some media queries and determine the device's screen and capabilities are such that you're going to include some extra modules. Cool, do it up with some parallel Ajax calls!

---

Multiple Simultaneous Ajax Requests (with one callback) in jQuery is a post from CSS-Tricks

more info...

Getting started with Gulp

CSS-Tricks

Getting started with Gulp

I followed this guide by Mark Goodyear to try Gulp (a Grunt competitor) out. I don't use either of them at a level where I'm qualified to have a strong opinion about betterness. They both work for me. I do enjoy the piping in Gulp how you say "take this, do this, this, and this, then put it here" - rather than configuring a source and destination on each thing like in Grunt.

One hiccup I faced: I was running Node 0.8 something locally, which was too old for Gulp. Might as well get yourself upgrade to 0.10 something.

Direct Link to Article — Permalink

---

Getting started with Gulp is a post from CSS-Tricks

more info...

You Might Not Need jQuery

CSS-Tricks

You Might Not Need jQuery

I'm of the opinion that you probably usually do need jQuery (I explain why many times in my latest course on it).

But I'm also of the opinion that reference guides like this a super cool and useful for those of us who came into the world of JavaScript through jQuery. I'll probably reference this thing a zillion times.

Direct Link to Article — Permalink

---

You Might Not Need jQuery is a post from CSS-Tricks

more info...

Force Quit a Tab in Google Chrome

CSS-Tricks

Force Quit a Tab in Google Chrome

Normally Google Chrome is very good at allowing you to close misbehaving tabs. Each tab is like its own little universe so if it crashes it doesn't affect other tabs. That's the whole "multi process" thing that Chrome brought to the WebKit party and was part of the reason for the Blink break-up.

But let's say there is a tab that just won't close. You click the closing ✕ and nothing happens. Try using ⌘W to close it, nothing. File > Close Tab, nothing.

It happens to me maybe once a week as I'm browsing around different Pens on CodePen. Perhaps there is an infinite-loop in the JS or some other madness and the tab just won't crash, it just hangs.

You can get that tab closed by using the Task Manager.

Window > Task Manager

Find the tab in the list. They are listed by <title> so hopefully you either recognize it or can drag the window wide enough to see the name in the tab itself. Then click the End Process button in the lower right. That'll close that tab no matter how stubborn it's being (in my experience).

---

Force Quit a Tab in Google Chrome is a post from CSS-Tricks

more info...

Boxes That Fill Height (Or More) (and Don’t Squish)

CSS-Tricks

Boxes That Fill Height (Or More) (and Don’t Squish)

It's hard to sum up all the awesome that is flexbox in a little ol' blog post. Although we gave it a shot here. Here, let's just try and focus on one thing that flexbox solves very nicely: the ability to have an arbitrary set of boxes fill up all the available height of a parent box. And not only that, but expand beyond that if needed (not squish them to fit).

By "box", I just mean block level element. Div, section, article, whatever.

By default those boxes height is determined by the content inside them. They will stack on top of each other. Their parent boxes height might also be determined by their height combined, but it could be different (e.g. it's set explicitly or it's something variable like the browser window). If the parent box has a larger height, there will just be empty space below.

Can't we force the boxes to split up the space evenly amongst that space? We can with flexbox.

Left: default; Right: what we wanna do

Say the HTML is like:

<section class="fill-height-or-more">
  <div>
    <!-- stuff -->
  </div>
  <div>
    <!-- stuff -->
  </div>
  <div>
    <!-- stuff -->
  </div>
</section>

Then we kick off flexbox with the parent box:

.fill-height-or-more {
  display: flex;
}

and make the boxes up-and-down (column) rather than left-and-right (row) as is the default:

.fill-height-or-more {
  display: flex;
  flex-direction: column;
}

With just that, it will look no different than it did if we did nothing. But now we apply the flex property to the children and they will fill the space:

.fill-height-or-more > div {
  /* these are the flex items */
  flex: 1;
}

Annnnd done =).

As a detail here, flex: 1; is the same as saying flex: 1 1 auto; It is shorthand for three different properties:

flex-grow: 1;
flex-shrink: 1;
flex-basis: auto;

Just so happens that giving them the ability to grow on an equal basis the most common need so flex: 1; is a nice way to write that.

One of the nice things about flexbox is this will work with an arbitrary number of boxes. Could be a single box! Could be 100 boxes! Doesn't matter. If there is extra room, the space will be divided and filled. If not, no big deal.

In a pre-flexbox world, we might have tried to know/find out how many boxes there were, and then set their heights with percentages. That works to fill extra space, but if there were too many boxes, you'd get squished. That's another nice thing about flexbox, it won't squish those boxes to the point of them not being able to fit their content. So...

Left: if we were to use percentages; Right: Normal desired behavior

If we wanted to take this a step further, we could use flexbox to center the content within those boxes too (!). This is where people get mad at CSS though. Vertical centering is kinda hard. Even with flexbox here, we'll need to make each of those flex item children we have into flex containers as well. Then use an internal wrapper which becomes the flex item we center. So yeah, an extra element still. Update: Tedmotu did it without the extra element, which is really straightforward

To center it, we make the direction up-and-down again (column) and use another flexbox property, justify-content, to center it.

.fill-height-or-more > div {
  flex: 1;

  display: flex
  justify-content: center;
  flex-direction: column;
}

This is where the reference guide comes in handy... finding out which property does what quickly.

Then we get this:

See the Pen Boxes That Fill Height (or more) by Chris Coyier (@chriscoyier) on CodePen.

Browser Support

I've only used the latest syntax here in this post. Current versions of Chrome, Opera support it just like that. Near-future versions of Firefox and Android will be supporting it just like that as well. Safari and iOS support the new syntax, just with -webkit- prefixes. Can I Use has the whole story.

IE is weird. IE 10 supports the tweener version of flexbox (e.g. display: -ms-flexbox;). IE 11 supports the latest flexbox. With this particular demo though, something is broken. While the height of .fill-height-or-more renders at full height by using min-height, the boxes are squished.

If you use height instead of the flex container, it "works" - but the point here was using min-height to avoid squishing. Seems like an implementation bug to me.

It's understandable that you might need to go back a bit further with browser support. Firefox 27, iOS 6, and Safari 6 are pretty legit browser support targets and all those use some variation of the older syntax, sometimes prefixed and sometimes not.

Just our little example looks like this when as fleshed out as it can be for support:

.fill-height-or-more {
  display: -webkit-box;
  display: -webkit-flex;
  display: -moz-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-box-orient: vertical;
  -webkit-box-direction: normal;
  -webkit-flex-direction: column;
  -moz-box-orient: vertical;
  -moz-box-direction: normal;
  -ms-flex-direction: column;
  flex-direction: column;
} 

.fill-height-or-more > div {
  -webkit-box-flex: 1;
  -webkit-flex: 1;
  -moz-box-flex: 1;
  -ms-flex: 1;
  flex: 1;
  display: -webkit-box;
  display: -webkit-flex;
  display: -moz-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-box-pack: center;
  -webkit-justify-content: center;
  -moz-box-pack: center;
  -ms-flex-pack: center;
  justify-content: center;
  -webkit-box-orient: vertical;
  -webkit-box-direction: normal;
  -webkit-flex-direction: column;
  -moz-box-orient: vertical;
  -moz-box-direction: normal;
  -ms-flex-direction: column;
  flex-direction: column;
}

Yeesh. My recommendation? Write it in the modern syntax like I have above and let Autoprefixer deal with it, which not only deals with the prefixing but the older syntax as well.

Video Screencast

Might as well hey? I published it here and I'll embed it also:

---

Oh and just for the record, the real-world scenario that brought this on for me was this page.

---

Boxes That Fill Height (Or More) (and Don’t Squish) is a post from CSS-Tricks

more info...

CSS Regions Matter

CSS-Tricks

CSS Regions Matter

On the heels of Håkon Wium Lie's condemning of CSS regions, Sara Soueidan writes about all their benefits. Having read both now carefully, I think Hakon is wrong on each point and CSS regions are quite useful.

Paramount to the discussion:

CSS Regions are not a layout feature — they're a fragmentation feature

Whatever any of us think, Blink is going to yank out early support for regions, mainly citing performance reasons. Weird to me: why was this reported on big sites with negative "dump" and "rejects" headlines?

Direct Link to Article — Permalink

---

CSS Regions Matter is a post from CSS-Tricks

more info...

Play and Pause Buttons for YouTube and Vimeo Videos (via Their APIs)

CSS-Tricks

Play and Pause Buttons for YouTube and Vimeo Videos (via Their APIs)

Sometimes you just need to start a video playing by some user interaction on the page other than clicking right on that video itself. Perhaps a "Play Video" button of your own creation lives on your page and you want to start that video when that button is clicked. That's JavaScript territory. And if that video is a YouTube or Vimeo video, we'll need to make use of the APIs they provide. No problem.

For these examples, we'll assume you've already picked out a video and you're going to put it on the page in an

For YouTube

1. Make sure the iframe src URL has ?enablejsapi=1 at the end

Like this:

<iframe src="//www.youtube.com/embed/FKWwdQu6_ok?enablejsapi=1" frameborder="0" allowfullscreen id="video"></iframe>

I also put an id attribute on the iframe so it will be easy and fast to target with JavaScript.

2. Load the YouTube Player API

You could just link to it in a <script>, but all their documentation shows loading it async style, which is always good for third-party scripts, so let's do that:

// Inject YouTube API script
var tag = document.createElement('script');
tag.src = "//www.youtube.com/player_api";
var firstScriptTag = document.getElementsByTagName('script')[0];
firstScriptTag.parentNode.insertBefore(tag, firstScriptTag);

3. Create a global function called onYouTubePlayerAPIReady

This is the callback function that the YouTube API will call when it's ready. It needs to be named this.

function onYouTubePlayerAPIReady() {

}

It's likely you have some structure to your JavaScript on your page, so generally I'd recommend just having this function call another function that is inside your organizational system and get going on the right track right away. But for this tutorial, let's just keep it soup-y.

4. Create the Player object

This is the object that has the ability to control that video. We'll create it using the id attribute on that iframe in our HTML.

var player;

function onYouTubePlayerAPIReady() {
  // create the global player from the specific iframe (#video)
  player = new YT.Player('video', {
    events: {
      // call this function when player is ready to use
      'onReady': onPlayerReady
    }
  });
}

Another callback!

5. Create the "player ready" callback and bind events

We named this function when we created the player object. It will automatically be passed the event object, in which event.target is the player, but since we already have a global for it let's just use that.

Here we bind a simple click event to an element on the page with the id #play-button (whatever custom button you want) and call the player object's playVideo method.

function onPlayerReady(event) {
  
  // bind events
  var playButton = document.getElementById("play-button");
  playButton.addEventListener("click", function() {
    player.playVideo();
  });
  
  var pauseButton = document.getElementById("pause-button");
  pauseButton.addEventListener("click", function() {
    player.pauseVideo();
  });
  
}

All Together Now

And that'll do it! Here's a demo:

See the Pen Play Button for YouTube by Chris Coyier (@chriscoyier) on CodePen.

I used a little SVG templating in there for the buttons just for fun.

For Vimeo

1. Make sure the iframe src URL has ?api=1 at the end

<iframe src="//player.vimeo.com/video/80312270?api=1" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen id="video"></iframe>

I also put an id attribute on the iframe so it will be easy and fast to target with JavaScript.

2. Load the "froogaloop" JS library

The Vimeo player API actually works by sending commands through postMessage right to the iframe. You don't need the froogaloop library to do that, but postMessage has some inherent complexities that this library (by Vimeo themselves) makes way easier. Plus it's only 1.8kb so I'd recommend it.

<script src="froogaloop.min.js"></script>

3. Create the player object

var iframe = document.getElementById('video');

// $f == Froogaloop
var player = $f(iframe);

We target the iframe by the id attribute we added. Then we create the player using the special froogaloop $f.

4. Bind events

All we have to do now is call methods on that player object to play and pause the video, so let's call them when our play and pause buttons are clicked.

var playButton = document.getElementById("play-button");
playButton.addEventListener("click", function() {
  player.api("play");
});

var pauseButton = document.getElementById("pause-button");
pauseButton.addEventListener("click", function() {
  player.api("pause");
});

All Together Now

That'll do it for Vimeo. Here's a demo:

See the Pen Pause / Play Buttons for Vimeo Videos by Chris Coyier (@chriscoyier) on CodePen.

---

You can do much more with the APIs for both of these services. It can be pretty fun, just dive in!

• Vimeo APIs


• YouTube APIs

---

Play and Pause Buttons for YouTube and Vimeo Videos (via Their APIs) is a post from CSS-Tricks

more info...