Entries tagged “css.”

Colorpeek for Chrome (and on CSS-Tricks)

Hey, remember Colorpeek, my web app for quickly sharing and previewing colors? Well, good news: I just released an accompanying Chrome extension that makes the creation of palettes from text, webpages or images even easier!

I’m honored to announce the extension in an article I wrote for CSS-Tricks, one of my favorite blogs and an indispensable resource for any self-respecting web designer. Stay tuned for Part Two, which will walk through the process of making your own simple Chrome extension. (Update: Part Two is now available!)

And if you use Chrome and dig Colorpeek, try the darn extension already!

Meet Colorpeek, a simple way to share and preview colors

When Tim Sears and I were almost done making Lotsa Blocks, we decided it might be fun to change the color of the blocks for seasonal holidays. Christmas blocks would be red and green, halloween blocks black and orange, etc.

Once I finished designing one of these color palettes in Illustrator, I had to send it to Tim. So I did what a lot of designers do: I threw together an image showing the colors and their corresponding hex values.

This worked fine, but the process was tedious for me to create and for Tim to reference (especially when he needed to convert them to RGB notation). I wanted a way to quickly and easily share colors without numerous steps, ongoing maintenance or even account creation.

I found a lot of great color-related apps (COLOURlovers, Palettee, color.hailpixel.com), but none that did exactly what I wanted.

So I made one. It’s called Colorpeek.

Now I can send Tim a link to the colors I want: colorpeek.com/#a899f2,dd4e85,4dc45e,6da7e8

And if he needs RGB, it’s as easy as tapping or clicking the cog icon and changing the notation.

 Colorpeek will accept just about any CSS color value, including hex (triplet or shorthand), RGB, RGBA, HSL and HSLA. It will convert color keywords like indigo or lightslategray to hex. It also supports many brand colors as keywords, so you can easily add facebook, android or wordpressorange to your palettes.

This being a 1.0 release, I tried hard to include only features I find to be critical. I hope to add more things from my list of “wants” to future iterations (copy to clipboard, transitions/animations, color picker, color editing, palette export options, to name a few).

If you have ideas for making Colorpeek better while retaining its simplicity, please let me know.

I want to thank Marc Roman for designing the Colorpeek logo, Erik Jung for helping me learn Knockout, my Cloud Four teammates for their support, encouragement and access to the device lab, and everyone who offered feedback or advice for my little side project.

You can follow me and/or @Colorpeek on Twitter for updates.

Feature Queries Follow-Up

Back in February (eons ago in internet time), I brainstormed a possible alternative to vendor prefixes I called feature queries. After receiving a collective “meh” from my close collaborators, I assumed the idea was a misfire. Perhaps it was too verbose, too repetitive, or maybe it missed the point entirely. I accepted the concept’s shortcomings and moved on.

So imagine my surprise when I saw Stuff and Nonsense link to a Chris Mills post titled “Native CSS feature detection via the @supports rule.” A brief excerpt:

This article looks at the CSS @supports rule, part of the CSS3 Conditional Rules Module Level 3, which provides a perfect mechanism for selectively applying CSS based on feature support.

Here’s how this “perfect mechanism” works:

@supports (display:flex) {
    section { display: flex }
}
@supports not (display:flex) {
    section { float: left }
}

Looks familiar, right? I got the name wrong, my query syntax was shorter (but less straightforward) and I failed to consider operators (as detailed in the aforelinked post), but otherwise my “feature queries” came surprisingly close to the real thing.

To be clear, I’m not saying my post inspired the contents of the W3C’s working draft for this module. That would be presumptuous.

What I am saying is that I clearly possess a very specific kind of clairvoyance. With that in mind, I’d like to make a few more CSS “proposals”…

  • A new value for the font-smoothing property, use-common-sense-to-render-predictably.

  • The pill: red rule, which would specify that targeted elements are ready to face the painful truth of reality. (Default value would be blue to avoid freeing users of outdated browsers.)

  • The @pizza mechanism would reward designer-developers for well-written styles with delicious, piping-hot pizza delivered right to their door.

Your move, W3C.

Happier IE fallbacks with CSS, LESS and conditional comments

Nobody likes writing CSS fallbacks. They’re a speed bump in your creative flow. Here’s how I use a couple different techniques to simplify the process

This assumes that you’re using conditional comments on the html tag to define classes for certain versions of IE. This technique was originally proposed by Paul Irish and refined in the HTML5 Boilerplate to something like this:

<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7" lang="en"> <![endif]-->
<!--[if IE 7]>    <html class="no-js lt-ie9 lt-ie8" lang="en"> <![endif]-->
<!--[if IE 8]>    <html class="no-js lt-ie9" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->

You can omit the “no-js” class if you aren’t using Modernizr, and feel free to remove or tweak the conditional comments to suit the versions of IE that actually require fixes (I recommend referring to this Quirksmode post for examples).

With this markup is in place, you can conveniently target styles to specific versions of IE. For example, let’s say I’m running into a box model bug in IE7 that’s resulting in a div not having the correct amount of top margin. Thanks to the classes I’ve applied using conditional comments, I can apply extra margin only for that browser version and below.

.example { margin-top: 24px; }
.lt-ie8 .example { margin-top: 48px; }

Voila! .example will have extra margin to account for the bug in IE7 and below without impacting any other browsers.

Vanilla CSS works well for a simple, top-level item like that, but it can get a bit hairy when you try to apply similar fixes with particularly deep inheritance. An example:

.l-container.example.s-active .button {
    background-color: #00ccff;
    display: block;
    line-height: 42px;
}
.lt-ie8 .l-container.example.s-active .button {
    height: 42px;
}

Yeesh… that’s pretty verbose! Here’s where the beauty of LESS comes in handy, particularly its support for scoped variables, nested rules and the ampersand combinator:

.l-container.example.s-active .button {
    @height: 42px;
    background-color: #00ccff;
    display: block;
    line-height: @height;
    .lt-ie8 & {
        height: @height;
    }
}

Occurrences of @height will be replaced with 42px in the compiled CSS. The ampersand in the nested selector will be replaced by the parent selector. This will compile to exactly the same as the previous example, but with a lot less redundant typing.

That’s all well and good for one-off bug fixes, but what about recurring fixes that need to be applied on a case-by-case basis? That’s where the power of parametric mixins comes in handy.

Here’s an example of a mixin we can use to support transparency in old IE syntax and standard syntax. Note that because IE’s filter property does not use standard CSS syntax, it can throw off the LESS parser, so we use a leading tilde (essentially the LESS equivalent of eval) and string interpolation to render the rule:

.opacity(@amount) {
    opacity: @amount;
    .lt-ie9 & {
        @ieop: @amount * 100;
        filter: ~"alpha(opacity=@{ieop})";
    }
}

.example { .opacity(0.5); }

Which will compile to:

.example { opacity: 0.5; }
.lt-ie9 .example { filter: alpha(opacity=50); }

Here’s another example for supporting inline-block in IE7 and below:

.inline-block() {
    display: inline-block;
    .lt-ie8 & {
        display: inline;
        zoom: 1;
    }
}

.example { .inline-block(); }

Compiled:

.example { display: inline-block; }
.lt-ie8 .example {
    display: inline;
    zoom: 1;
}

Like The Force, nested rules can be used for good or for evil. When working with this sort of shorthand it can get a little too easy to overuse mixins or forget to combine selectors to insure your compiled CSS is still fairly lean. Refer to this entry for more on that very topic.

Feature Queries, a hypothetical CSS vendor prefix alternative

Web browsers can be pretty self-absorbed. Vendor prefixes (and conditional comments before them) are narcissistic solutions that favor browser detection over feature detection, contrary to our industry’s best practices. As a result, browser makers have gotten themselves in a bit of a pickle.

To be fair, their intentions were (and still are) good. Our designs have benefited from proprietary or burning-edge CSS features, most of which would be difficult or impossible to implement without vendor prefixes.

The problem is, we got here by asking the wrong questions.

We shouldn’t care about whether or not our design is viewed in a “WebKit” browser, Firefox or Internet Explorer. We also shouldn’t care about whether or not a feature is in “alpha” or “beta”, distinctions too broad and subjective to be of much practical use.

Here’s what we really need to know:

  1. Does the browser support this feature?
  2. Can the browser successfully parse the syntax I’m using?

Media queries already work this way. The browser only renders the styles therein when the query is true. Because CSS is fault-tolerant, browsers that don’t support media queries will ignore the ruleset entirely.

What if we adopted a similar syntax for feature detection? Let’s use our imaginations and dive in to this 100% fictitious, hypothetical example:

@feature (transition) {
    .example {
        transition: background-color .25s ease-in-out;
    }
}

The .example ruleset will only be rendered if the browser supports the @feature query and the transition property.

By implementing the not operator from media queries, we could get hardboiled and only use queries for fallbacks:

.example {
    transition: background-color .25s ease-in-out;
}
@feature not (transition) {
    /* Fallback rules */
}

If these (again, hypothetical) feature queries could be extended to test values as well as properties, we could test for differences in syntax:

/* -moz syntax */
@feature (linear-gradient(left, white, gray)) {
    .example {
        background-image: linear-gradient(left, white, gray);
    }
}
/* -webkit syntax */
@feature (linear-gradient(linear, left center, right center, from(white), to(gray))) {
    .example {
        background-image: linear-gradient(linear, left center, right center, from(white), to(gray));
    }
}

This idea obviously has its flaws. In the latter example, things can get pretty verbose (not to mention repetitive). Also, it feels a little unintuitive to group rules by feature instead of by element or media (even though Modernizr already encourages this, albeit much more succinctly). In spite of these flaws, feature queries would allow us to design for features instead of browsers, which feels like a step in the right direction.

Then again, I may be woefully misguided. Thoughts?