calc() is a native CSS way to do simple math right in CSS as a replacement for any length value (or pretty much any number value). It has four simple math operators: add (+), subtract (-), multiply (*), and divide (/). Being able to do math in code is nice and a welcome addition to a language that is fairly number heavy.

But is it useful? I've strained my brain in the past trying to think of obviously useful cases. There definitely are some though.

Can't Preprocessors Do Our Math?

All CSS Preprocessors do have math functions and they are pretty useful. But they aren't quite as powerful as native math. The most useful ability of calc() is it's ability to mix units, like percentages and pixels. No Preprocessor will ever be able to do that. It is something that has to happen at render time.

Syntax

.thing {
      width: 90%; /* fallback if needed */
      width: calc(100% - 3em);
    }

There must be spaces surrounding the math operator. You can nest.

Browser Support

It is surprisingly good. Can I use... is always great for checking out the details there. On desktop the concerns would be it's IE 9+, Safari 6+, and won't be in Opera until it is on Blink in 15+. On mobile, Android and Opera Mini don't support it at all yet and iOS just on 6.0+.

You'll have to make the call there. I've been able to actually use it in production in certain scenarios already.

Use Case #1: (All The Height - Header)

A block level child element with height: 100% will be as tall as it's block level parent element. It can be nice to make a colored module as tall as the parent element in some cases.

But now let's say the parent element becomes too small to contain all the content in the module. You want the content to scroll, but you want just the content to scroll, not the entire module. Just set overflow-y: auto; right? Not quite, because overflow-y is only useful if the content element itself has a set height that can be overflowed. We can't make the content element 100% high because with the header there, that will be too high. We need 100% minus the height of the header. If we know that header height, it's doable!

* {
      /* So 100% means 100% */
      box-sizing: border-box;
    }
    html, body {
      /* Make the body to be as tall as browser window */
      height: 100%;
      background: #ccc;
      padding: 20px;
    }
    body {
      padding: 20px;
      background: white;  
    }
    .area-one {
      /* With the body as tall as the browser window
         this will be too */
      height: 100%;
    }
    .area-one h2 {
      height: 50px;
      line-height: 50px;
    }
    .content {
      /* Subtract the header size */
      height: calc(100% - 50px);
      overflow: auto;
    }

You might gripe that the header shouldn't have a fixed size. Might be cool someday if calc() could subtract measured sizes of elements, but that's not possible yet. You could set the header to overflow with ellipsis.

Check out this Pen!

Use Case #2: X Pixels From Bottom Right Corner

We can position background-image X pixels from the top-left corner easily.

background-image: url(dog.png);
    background-position: 50px 20px;

That would put the dog 50px from the left and 20px from the top of the elements box. But what if you want it 50px from the right and 20px from the bottom? Not possible with just straight length values. But calc() makes it possible!

background-image: url(dog.png);
    background-position: calc(100% - 50px) calc(100% - 20px);

Check out this Pen!

Use Case #3: Fixed Gutters Without Parents

Let's say you want two columns next to each other. The first 40% wide, the second 60%, but with a fixed 1em gap between the columns. Don't Overthink It Grids have fixed gutters, but they aren't true gutters in a sense. The columns themselves bump right into each other and the columns are made by internal padding inside those columns.

Using calc(), we can make the first column 40% wide with a right margin of 1em, then make the second column 60% wide minus that 1em.

.area-one {
      width: 40%;
      float: left;
      margin-right: 1em;
    }
    
    .area-two {
      width: calc(60% - 1em);
      float: right;
    }

You could remove half the gutter from both if you wanted to keep the proportion more accurate. Now you have two true columns separated by fixed space without needing parent elements or using the internal padding.

Check out this Pen!

Use Case #4: Showing Math Is Easier To Understand

Speaking of columns, sometimes division math gets messy. Let's say you wanted a 7-column grid, you might have classes like:

.column-1-7 {
       width: 14.2857%
    }
    .column-2-7 {
       width: 28.5714%
    }
    .column-3-7 {
       width: 42.8571%
    }

Not exactly magic numbers, but difficult to understand at a glance.

.column-1-7 {
       width: calc(100% / 7);
    }
    .column-2-7 {
       width: calc(100% / 7 * 2);
    }
    .column-3-7 {
       width: calc(100% / 7 * 3);
    }

Check out this Pen!

Use Case #5: Kinda Crappy box-sizing Replacement

I'm a fan of universal box-sizing: border-box; because it means you don't have to do much math to figure out how big an element actually is, our adjust that math when things like border and padding change.

If you want to replicate what box-sizing does, you could use calc() to subtract the values as needed.

.module {
      padding: 10px;
    
      /* Same as box-sizing: padding-box */
      width: calc(40% - 20px);
    
      border: 2px solid black;
    
      /* Same as box-sizing: border-box */
      width: calc(40% - 20px - 4px);
    }

box-sizing has far better browser support than calc() though, so this would be rarely used.

The Future?

I think it will be interesting when we can use the attr() function in places other than the content property. With that, we could yank the value from HTML elements, run calculations on them, and use the new numbers to do design-y things. Like colorize inputs based on the numbers they contain.

Perhaps we could even use it to do fancy things with the <progress> elements like turn it into a speedometer like on this page. Perhaps something like:

/* Not real */
    progress::progress-bar {
      transform: rotate(calc(!parent(attr(value))*18)) + deg);
    }

Need a new look for your portfolio? Check out the Snap WordPress theme from The Theme Foundry. Sass files and Compass config are included!

A Couple of Use Cases for Calc() is a post from CSS-Tricks

Whoops is a small library, available as a Composer package, that helps you handle errors and exceptions across your PHP projects.

Out of the box, you get a sleek, intuitive and informative error page each time something goes pants-up in your application. Even better, under all that is a very straight-forward, but flexible, toolset for dealing with errors in a way that makes sense for whatever it is that you’re doing.

The library’s main features are:

• Detailed and intuitive page for errors and exceptions
• Code view for all frames
• Focus on error/exception analysis through the use of custom, simple middle-ware/handlers
• Support for JSON and AJAX requests
• Included providers for Silex and Zend projects through the bundled providers, and included as part of the Laravel 4 core
• Clean, compact, and tested code-base, with no extra dependencies

Whoops achieves this through a system of stacked handlers. You tell Whoops which handlers you want to use (you can choose from the included handlers or make your own), and if something happens, all the handlers are given, in order, a chance do to something – this can be anything from analyzing the error (Whoops makes it easier to extract meaningful information from an error or exception), to displaying helpful error screens (like the built-in PrettyPageHandler, which gives you the cool looking page pictured above).

Let’s give it a try, first, by looking at the basics, and then by having a go at building our own handler with Whoops and the Laravel framework. For this short guide, I’ll assume that you’re moderately comfortable with PHP, and that you’ve heard of Composer. If this is not the case, read-up on it here at Nettuts+.

Installing Whoops

Create a directory for your project, change into it, create a composer.json file with the Whoops requirement, and install it. Whoops (as of version 1.0.5) has no dependencies, so this will only take a second.

$ cd /path/to/your/project
    $ composer require filp/whoops 1.*
    $ composer install
    

Using Whoops: The Basics

To see that sleek error page in action, let’s setup Whoops and ensure that something breaks by throwing an exception within our code. Create a file within your project’s directory; for this guide, let’s say that it’s called, index.php.

$ cd /path/to/your/project
    $ your-favorite-editor index.php
    

Because we installed Whoops with Composer, and it is PSR-0 compliant, all we need to do is require the Composer autoloader and we’re ready to start using the library within our own code!

<?php
    # index.php
    require __DIR__ . "/vendor/autoload.php";
    
    $whoops = new Whoops\Run();
    $whoops->pushHandler(new Whoops\Handler\PrettyPageHandler());
    
    // Set Whoops as the default error and exception handler used by PHP:
    $whoops->register();  
    
    throw new RuntimeException("Oopsie!");
    ?>
    
    

If you already have a web-server running, go ahead and access the file that you just created. Don’t forget: if you’re using PHP 5.4, you can leverage the built-in development server, like so:

$ cd /path/to/your/project
    $ php -S localhost:8080
    

This is what you’ll get:

Pretty neat, right? Handlers, themselves, can expose options to modify or augment their behavior. For example, among other things, you can set the title of the default error page, and even insert extra information:

<?php
    # index.php
    $whoops = new Whoops\Run();
    
    // Configure the PrettyPageHandler:
    $errorPage = new Whoops\Handler\PrettyPageHandler();
    
    $errorPage->setPageTitle("It's broken!"); // Set the page's title
    $errorPage->setEditor("sublime");         // Set the editor used for the "Open" link
    $errorPage->addDataTable("Extra Info", array(
          "stuff"     => 123,
          "foo"       => "bar",
          "useful-id" => "baloney"
    ));
    
    $whoops->pushHandler($errorPage);
    $whoops->register();
    
    throw new RuntimeException("Oopsie!");
    ?>
    

Also, since this is simply a regular Whoops handler, we can mix-and-match with other handlers to achieve more dynamic results. Let’s imagine that you’re working on an AJAX+JSON-driven website. Right now, if your application were to fail somehow, you would get a bunch of nasty HTML coming down the pipe, when you were expecting JSON. No big deal:

<?php
    # index.php
    $whoops->pushHandler(new Whoops\Handler\PrettyPageHandler());
    $whoops->pushHandler(new Whoops\Handler\JsonResponseHandler());
    
    $whoops->register();
    
    throw new RuntimeException("Oopsie!");
    

That’s it. Now, if something fails during an AJAX request, Whoops will respond with a JSON response detailing the error. If it’s NOT an AJAX request, you will continue to see the regular error page. If an error ocurrs, Whoops will filter through each of the registered handlers (starting at the last handler to be registered), and give them a chance to analyze, modify and respond to the request.

Now that you have a general idea of how Whoops works, let’s have a go at building our own handler with Whoops and the Laravel 4 framework.

Whoops and Laravel 4

Laravel 4 bundles Whoops as a core exception handler, enabled by default in development mode, including a custom color-scheme by Dayle Rees:

If you haven’t installed Laravel yet, head on over and follow the installation steps. Laravel is covered extensively on Nettuts+ and Tuts+ Premium, so you’ll find plenty of training here, if you’d like to dig in further.

For the next steps, I’ll assume that you are somewhat comfortable with the basics of Laravel 4. However, even if you aren’t, it should still be easy to follow.

If you’re in development (debug) mode, Whoops is available through the IoC container as whoops, and pre-set with one of two handlers: PrettyPageHandler or JsonResponseHandler, as whoops.handler (the same two we just talked about). Both of these handlers expose useful additional methods, as you’ve seen above with the PrettyPageHandler. By accessing these services, we can start customizing our Whoops experience within the framework.

For simplicity’s sake, in your app/routes.php file, let’s hook into the Whoops service and set a custom page title for our error pages:

<?php
    #app/routes.php
    
    /*
    |--------------------------------------------------------------------------
    | Application Routes
    |--------------------------------------------------------------------------
    */
    
    use Whoops\Handler\PrettyPageHandler;
    
    // Use the Laravel IoC container to get the Whoops\Run instance, if whoops
    // is available (which will be the case, by default, in the dev
    // environment)
    if(App::bound("whoops")) {
        // Retrieve the whoops handler in charge of displaying exceptions:
        $whoopsDisplayHandler = App::make("whoops.handler");
    
        // Laravel will use the PrettyPageHandler by default, unless this
        // is an AJAX request, in which case it'll use the JsonResponseHandler:
        if($whoopsDisplayHandler instanceof PrettyPageHandler) {
    
            // Set a custom page title for our error page:
            $whoopsDisplayHandler->setPageTitle("Houston, we've got a problem!");
    
            // Set the "open:" link for files to our editor of choice:
            $whoopsDisplayHandler->setEditor("sublime");
        }
    }
    
    Route::get('/', function()
    {
        // Force the execution to fail by throwing an exception:
        throw new RuntimeException("Oopsie!");
    });
    ?>
    
    

Tip: Whoops supports a few editors by default, and allows you to implement support for your own as you wish. Read more about it here.

If you now access your Laravel application, you’ll be greeted with an error message with your custom page title. If you click the file path above the code box, it should open the referenced file right in your editor or IDE of choice. How cool is that? Also, since we can reach the handler already setup by the Laravel core, we can put to use the other features we’ve learned about above. For example, we can add custom tables (with PrettyPageHandler::addDataTable) with useful information about our application.

Let’s have a go at one more example. This will be our first attempt at writing our own custom handler. We want to get all the stack frames for an exception, and remove anything that’s not part of our application code. Sounds simple enough, right?

<?php
    #app/routes.php
    
    /*
    |--------------------------------------------------------------------------
    | Application Routes
    |--------------------------------------------------------------------------
    */
    
    use Whoops\Handler\Handler;
    
    // Use the Laravel IoC to get the Whoops\Run instance, if whoops
    // is available (which will be the case, by default, in the dev
    // environment)
    if(App::bound("whoops")) {
        $whoops = App::make("whoops");
    
        $whoops->pushHandler(function($exception, $exceptionInspector, $runInstance) {
            // Get the collection of stack frames for the current exception:
            $frames = $exceptionInspector->getFrames();
    
            // Filter existing frames so we only keep the ones inside the app/ folder
            $frames->filter(function($frame) {
                $filePath = $frame->getFile();
    
                // Match any file path containing /app/...
                return preg_match("/\/app\/.+/i", $filePath);
            });
    
            return Handler::DONE;
        });
    }
    
    Route::get('/', function()
    {
        // Force the execution to fail by throwing an exception:
        throw new RuntimeException("Oopsie!");
    });
    ?>
    
    

Tip: You don’t actually have to return Handler::DONE – this serves only a semantic purpose. If you want Whoops to stop running any extra handlers after yours, write return Handler::LAST_HANDLER. If you want Whoops to exit the script execution after your handler, return Handler::QUIT.

You can see that it’s remarkably concise. Whoops\Run‘s pushHandler method accepts a closure that receives up to three arguments: the exception object, an exception inspector, which exposes some utility methods to, you guessed it, inspect exceptions, and the Whoops\Run instance that captured the exception. Through this handler, we use the exception inspector to extract the stack frames, all within a neat FrameCollection object:

<?php
    $frames = $exceptionInspector->getFrames(); // #=> Whoops\Exception\FrameCollection;
    count($frames); #=> int
    
    foreach($frames as $frame) {
        get_class($frame); // #=> Whoops\Exception\Frame
    
        print $frame->getFile() . ":" . $frame->getLine() . "\n";
            #=> "/path/to/file.php:123"
    }
    ?>
    
    

Tip: Whoops internally converts closures to a special handler: Whoops\Handler\CallbackHandler.

You can count, iterate, map and filter the contents of this class, with the interesting but important aspect that the map and filter operations mutate the object in-place. This means that both of these operations modify the original instance directly, instead of creating a new collection. How is this important? It means handlers can more easily perform changes that propagate downwards to all the other handlers in the stack. This is exactly what we did with our simple handler above. If you now run the script again, you’ll see that we get a shorter list of stack frames, only concerning the code living within our application directory.

As for the Frame object, itself (Whoops\Exception\Frame), it exposes a set of methods to gather information about the frame contents (the file path, line number, the method or function call, class name, etc,), and methods that allow you to attach comments to individual stack frames. A Frame comment is a useful feature in Whoops that allows handlers to provide additional information that they gather from an exception by attaching notes directly to individual frames in the stack. Handlers like the PrettyPageHandler, for example, can then gather those comments and display them along with the frame’s file path and line number.

<?php
    $whoops->pushHandler(function($exception, $exceptionInspector, $runInstance) {
        foreach($exceptionInspector->getFrames() as $i => $frame) {
            $frame->addComment("This is frame number {$i}");
        }
    
        return Handler::DONE;
    });
    ?>
    
    

Frame comments may also receive a second scope argument. If you have multiple custom handlers, you can, for example, filter frame comments by this argument to gather only the information that you care about.

<?php
    $frames = $exceptionInspector->getFrames();
    foreach($frames as $frame) {
        // Was this frame within a controller class? (ends in Controller)
        $className = $frame->getClass();
        if(substr($className, -10) == "Controller") {
            $frame->addComment("This frame is inside a controller: $className", "controller-error");
        }
    
        // Later, in another handler, get all comments within the 'controller-errors' scope:
        $controllerErrors = $frame->getComments("controller-errors"); // #=> array
    }
    ?>
    
    

Also of interest, the PrettyPageHandler naturally HTML-escapes the frame comments before displaying them, but will intelligently capture URIs in the comment’s body and convert them to clickable anchor elements. Want to link frames to documentation, or to GitHub repositories? It’s easy enough; let’s create our own handler class for this example.

Tip: Using your own class instead of a closure provides you with some extra control over your handler – not to mention making it easier to cover with automated tests. Your custom handler classes must implement the Whoops\Handler\HandlerInterface interface, but you may instead simply extend the Whoops\Handler\Handler class, and implement the missing handle method, as shown in the example below.

<?php
    # LaravelGithubLinkHandler.php
    
    use Whoops\Handler\Handler as BaseHandler;
    
    /**
     * When possible, link laravel source files to their location
     * on the laravel/framework repo @ github.com
     */
    class LaravelGithubLinkHandler extends BaseHandler
    {
        private $repoBase = "https://github.com/laravel/framework/blob/master";
    
        /**
         * @return int
         */
        public function handle()
        {
            $frames = $this->getInspector()->getFrames();
    
            foreach($frames as $frame) {
                $file = $frame->getFile();
                $line = $frame->getLine();
    
                // Some frames may not have a file path, for example, if it ocurred within
                // a Closure, so we'll need to check for that:
                if(!$file) continue;
    
                // Check if the file path for this frame was within the laravel/framework
                // directory, inside the Composer vendor/ directory, and use a regex capture
                // to extract just the parts we want:
                if(preg_match("/\/vendor\/laravel\/framework\/(.+)$/", $file, $matches)) {
                    $path = $matches[1]; // First match is whole path, second is our capture
                    $url  = "{$this->repoBase}/$path";
    
                    // We can also link directly to a line number, if we have it. Github
                    // supports this by appending #L<line number> to the end of the URL:
                    if($line !== null) {
                        $url .= "#L{$line}";
                    }
    
                    $frame->addComment($url, "github-linker");
                }
            }
    
            return Handler::DONE;
        }
    }
    ?>
    
    

That’s it, as far as our handler goes. Put that class somewhere in your project, and all that’s left to do is enable and try it out:

<?php
    # app/routes.php
    // ...
    $whoops->pushHandler(new LaravelGithubLinkHandler());
    // ...
    ?>
    
    

With only a handful of lines of code, we’ve added an extra layer of (possibly useless, but hey, it’s an example) functionality to our error pages. Here are a few extra ideas, if you’re looking for a challenge:

• Package your custom error handler as a Laravel service provider.
• Are you using Git to manage your project? Build a custom handler that hooks into git-blame to determine who the last person to touch that file that keeps throwing an exception (and yell at them) was, directly from the error page.
• If you’re feeling brave, use nikic’s PHP-Parser to analyze the troublesome code, and provide suggestions for fixes (I promise it’s not as complicated as it sounds).

Final Thoughts

I hope that this short guide has helped you gain an understanding of the sort of possibilities that this library enables in your every-day projects. For more information, refer to the complete API documentation.

Whoops is framework-agnostic, light-weight and, I believe, quite powerful in its simplicity and focus on mix-and-matching small tools. It’s also open-source and open to suggestions and improvements. If you’d like to contribute or report a bug, head to the official repository!

Wiley and Treehouse are pleased to announced the release of the third book in the Treehouse series: iOS 6 Foundations. iOS Foundations is a practical introduction for using iOS 6 to create universal apps. Use it as a companion to Treehouse’s iOS courses, and you’ll have everything you need to build apps for iPhone and iPad.

If you have prior experience programming in an object-oriented language and are eager to start building universal apps for iPad and iPhone (including the iPod touch), then this is the book for you! Using the latest version of iOS (iOS 6) along with the latest version of Xcode (Xcode 4.5), this book is a practical introduction rather than just a catalog of components. Full-color and packed with groundbreaking, innovative designs, this book teaches you how to create eye-catching, unique apps.

iOS 6 Foundations teaches you the various aspects of iOS development beginning with getting started with iOS 6, getting up to speed with Xcode, and learning the tools for developing with Objective-C. It reviews building the user interface with Xcode and Interface Builder, details how to set up your app in iTunes connect and distribute it through the app store, walks you through adding features like geo-location and twitter sharing, and helps you avoid common pitfalls and design decisions related to user experience and iOS programming.

What’s Inside the Book?

iOS 6 Foundations is organized so that each chapter builds on the previous, providing you with a blueprint for completely building an app by the end of the book. To give you a better idea of what you’ll learn, here’s a breakdown of the chapters:

Introduction

• Who Should Read This Book? 1
• What You Will Learn 2
• How to Use This Book 3
• Using This Book with Treehouse 4

Part 1: Introducing iOS

• Chapter 1: Getting Started with iOS 6 7
• Chapter 2: Getting Up to Speed with Xcode 25
• Chapter 3: Looking Ahead—Planning Your App 53
• Chapter 4: Designing the Party Planner App 63

Part 2: Storyboards: The Building Blocks of iOS Apps

• Chapter 5: Walking Through the iPhone Storyboard 81
• Chapter 6: Working with Storyboard Inspectors 101
• Chapter 7: Laying Out Your Scenes and Views 119

Part 3: Building the Party Planner App

• Chapter 8: Building on the Data Model 131
• Chapter 9: Building the Detail Data View 153
• Chapter 10: Saving and Restoring Data 183
• Chapter 11: Testing the App with the Debugger 201

Part 4: Using Table and Collection Views

• Chapter 12: Exploring the Table View in the Template 219
• Chapter 13: Formatting Table Cells 245
• Chapter 14: Editing Table Views 275

Part 5: Interacting with Users

• Chapter 15: Telling Users the News: Alerts and NSError 297
• Chapter 16: Getting Input from Users: Alerts and Action Sheets 309
• Chapter 17: Back to the Storyboard: Enhancing the Interface 319

The Giveaway

To celebrate the launch of iOS 6 Foundations, we’re going to give away 3 copies of this awesome book to the three individuals that can dream up the best ideas for an iPhone or iPad app. Just let your imagination run wild and tell us about your idea in the comments. We’ll pick our favorite three based on creativity, simplicity, and unique problem-solving.

Good luck with your ideas and we hope you win! If you absolutely can’t wait to get your hands on a copy, be sure to grab iOS 6 Foundations on Amazon today!

The post Giveaway: The New Treehouse iOS 6 Foundations Book Launches! appeared first on Treehouse Blog.

The Wander Postcard Project is the brainchild of the team at social media start-up Wander. They asked some of their favourite designers and illustrators to imagine a postcard from everywhere and nowhere at once. There were 58 contributors in total including the likes of Dan Cassaro, Fuzzco, Tim Boelaars and Matt Chase, to name a few. With such a talented group of contributors it’s no wonder that the results were pretty special.

An added bonus for fans of the project is that each postcard can be downloaded as a hi-res iPad or iPhone wallpaper.

Check out some of our favourite postcard designs below:

Which of these postcards is your favourite? Do you have a similar side project? Let us know in the comments.

Improve Designer Communication with MicroPersonas – only $17!

The Wander Postcard Project is the brainchild of the team at social media start-up Wander. They asked some of their favourite designers and illustrators to imagine a postcard from everywhere and nowhere at once. There were 58 contributors in total including the likes of Dan Cassaro, Fuzzco, Tim Boelaars and Matt Chase, to name a few. With such a talented group of contributors it’s no wonder that the results were pretty special.

An added bonus for fans of the project is that each postcard can be downloaded as a hi-res iPad or iPhone wallpaper.

Check out some of our favourite postcard designs below:

Which of these postcards is your favourite? Do you have a similar side project? Let us know in the comments.

Improve Designer Communication with MicroPersonas – only $17!