Bricss

caniuse.com redesign - feedback wanted

Sat, 26 Jan 2013 08:58:00 -0500

I’ve posted the following earlier this week on Dribbble, and we’ve got some great feedback so far. But we can use as much input as possible, so I’m posting this here as well.

Over the course of the past few months, I’ve been working on a redesign of caniuse.com together with Alexis Deveria aka @Fyrd, author of the site. If you don’t know caniuse.com yet, it’s an essential resource with compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers. Its current design is in need of a refresh, and while we’re at it we’re improving the usability, clearing up some clutter and making it responsive. The goal was to make a really clear and simple design so you can get to the information you’re after as easy and fast as possible.

This is just a screenshot of a work-in-progress prototype I’ve built, you can see it in action at http://caniuse.lensco.be. Some notes:

A lot of things don’t work yet – it is just a static prototype. You can already click the ‘settings’ and ‘index’ links however to get a feel how those will look like.
I originally made the light theme first, but Alexis suggested a dark theme close to the colors of the current design, as to not alienate regular visitors too much. We’re thinking of keeping the light theme as a user preference, accessible from the footer.
Most of it is already responsive, except the table itself and the tabs on the bottom. I’m not sure however if we really need to come up with a complex responsive table – I guess it works ok with a bit of horizontal scrolling?

It is our intention to gather feedback from this prototype and continue improving the design, out in the open, on Dribbble/Twitter/etc. So, do you see something that needs improvement? Is the responsive design not working on your device? Does this design make sense for color-blind people? Let us know on Dribbble or Twitter!

Using Sass source maps in WebKit Inspector

Wed, 17 Oct 2012 16:07:00 -0400

Here’s a second topic I talked about in my Fronteers 2012 jam session presentation. If you’ve been using a CSS preprocessor in your workflow, you’ve no doubt encountered this issue: you’re inspecting some element and want to edit the CSS, but finding that selector proves to be difficult as the inspector shows you file names and line numbers for your compiled CSS.

If you’re using Firefox and Sass you might have heard about FireSass, but Chrome users have been out of luck until recently. This is where source maps come into play. Source maps are a language-agnostic way of pointing your inspector to the right location in your unminified and uncombined files. Originally devised for JavaScript, they can equally be applied to CSS preprocessors.

A fairly recent commit enabled experimental support for Sass source maps in Chrome, so make sure you’re running at least Chrome 24. You’ll want to turn on Enable source maps in the settings, and Support for Sass in the experimental settings tab. Update: If the “Experimental” tab is not visible yet, visit chrome://flags first and turn on “Enable Developer Tools experiments”.

Next, make sure the output style of Sass is anything but ‘compressed’. Finally you’ll have to enable debug info – if you’re compiling from the command line, pass the --debug-info flag. If you’re using Compass, add this line to your config.rb:

sass_options = { :debug_info => true }

Now when you compile your CSS you should see lines like these preceding every selector in your compiled CSS:

@media -sass-debug-info{filename{font-family:file\:\/\/\/Users\/lensco\/Sites\/lensco\/sass\/style\.scss}line{font-family:\0000336}}

The WebKit Inspector will turn all this into exactly what we need: original file names and line numbers!

Don’t forget to turn off the debug info in your production environment afterwards – you don’t want all these lines littering your final CSS.

box-shadow vs filter: drop-shadow

Mon, 08 Oct 2012 09:54:00 -0400

This post is the first topic I discussed in my jam session presentation at Fronteers 2012. It’s about the drop-shadow filter. You may have looked at it and thought “this is pretty much the same thing as a box-shadow” right? Well, not exactly. The big advantage of the drop-shadow filter is that it acknowledges the outline and transparency of an element.

Have you ever wanted a box-shadow that followed the shape of an element, including generated content, like a tooltip with an arrow? Or you wanted a box-shadow to take transparent parts of a .png into account? That’s exactly what filter: drop-shadow() does. It has the exact same syntax as the box-shadow property, except that inset drop-shadows and the spread value are not supported (yet?).

Yes, it’s an experimental property, and yes, it’s only supported in some WebKit browsers now. But according to caniuse.com there’s already 32.51% of web users with support. And since it’s usually a decoration type of enhancement you can start using this today. Or even use a regular box-shadow on browsers that don’t support filters yet. Keep an eye on browser performance though, as things tend to get laggy pretty quickly with these experimental filters. Here’s a final example with a transparent PNG:

Unprefix express in full swing

Wed, 11 Jul 2012 15:41:19 -0400

The big vendor prefix discussion comes and goes in waves, but one conclusion that always pops up is that these prefixes should have a shorter lifespan. Of course browser makers may shift the responsability to specification writers, arguing that specs take too long to reach Candidate Recommendation (CR) status. Well, it seems the unprefix express is finally picking up steam.

A few weeks ago we heard about unprefixed transitions, transforms, animations, gradients, IndexedDB (and more) in the next Internet Explorer, and this week the Firefox team anounced exactly the same.

This is all great news. Even better, as Lea Verou noticed:

Keep in mind that this means you don’t have to use the -ms- prefix at all for transitions, animations and gradients, since no stable build of IE was ever released that requires it.

box-decoration-break finally coming to more browsers

Fri, 08 Jun 2012 06:48:29 -0400

One of the lesser known CSS properties I’m really excited about is box-decoration-break. From the official spec:

When a box is broken at a page break, column break, or, for inline elements, at a line break, the ‘box-decoration-break’ property specifies whether box fragments are treated as broken fragments of one continuous box, or whether each fragment is individually wrapped with the border and padding.

This will finally give us a simple solution for this problem for example, and for cut off box-shadows and the like. It would have been great to fully control which properties should be sliced and which ones not, but currently the poperty only has two possible values, slice (the default) and clone. This image – also from the spec – says it all:

So far, only Opera supports box-decoration-break, since 2009 (Opera 10.60). Firefox does have the -moz-background-inline-policy property that specifies how the background image of an inline element is determined when the content of the inline element wraps onto multiple lines, but that’s just a part of what box-decoration-break does. Here’s the corresponding Bugzilla bug.

Last week support for parsing the property landed in WebKit, with the rendering part still to be implemented. Let’s hope box-decoration-break will be available in all browsers soon!

Prevent background-color bleed on touch screens

Fri, 18 May 2012 11:18:00 -0400

Here’s an issue I’ve ran into a couple of times related to subpixel rounding on touch screens: while zooming in, I was seeing background colors bleeding through on the edges of an element that also had a background image applied. Open this fiddle on your smartphone or tablet and zoom in, you may see something like this:

Browsing this thread on Stack Overflow I found a really simple workaround that may not work in every situation, but it did the trick for me:

outline: 1px solid #fff;

Just a 1 pixel outline in the same color as your page background, et voila!

Subpixel layout coming to WebKit

Wed, 09 May 2012 11:58:00 -0400

If you’ve ever tried to get precise em-based values of letter-spacing to work in a WebKit browser, you’ve probably wondered why that isn’t really possible, while Firefox or Internet Explorer 10 for example do allow fine-grained control. Play around with this demo in various browsers and you’ll see what I mean.

The underlying reason is that WebKit currently uses integers to calculate pixel positions, while Firefox allows subpixel units to represent locations and sizes. This affects not only letter-spacing of course, but also things like rounding errors while zooming or applying transforms. There has been an ongoing effort to switch WebKit to use subpixel layout, and a few days ago Levi Weintraub and Emil A Eklund landed a patch that should put subpixel layout on the fast track. Look forward to more precision coming soon to WebKit-based browsers.

Here’s some technical background on this matter, and an article on subpixel rendering and the CSS Object Model from the IE team.

Easily checking in JavaScript if a CSS media query has been executed

Tue, 01 May 2012 12:52:32 -0400

For quite a while I have been looking for a way to “mirror” my CSS media queries in JavaScript, but without duplicating the actual queries. Of course, you can use matchMedia to evaluate a media query in JavaScript, but then you have to maintain your breakpoints in two places – not ideal.

Paul Hayes devised a clever method in his fork of the matchMedia polyfill, using transitions on dummy elements and watching for the transitionEnd event in JavaScript. But a truly simple solution – one that doesn’t really need watching for resize events – was still lacking.

Fortunately Jeremy Keith turned to his readers for help, and together they came up with a delightfully straightforward technique:

@media (min-width: 45em) {
    body:after {
        content: 'widescreen';
        display: none;
        }
    }

Which basically doesn’t do anything, except that you can check for it in Javascript:

var size = window.getComputedStyle(document.body,':after').getPropertyValue('content');
if (size == 'widescreen') {
    // go nuts
}

Nice!

Say hello to the color picker in WebKit Inspector

Mon, 05 Mar 2012 10:00:05 -0500

If you’re using the Chrome dev channel or the WebKit Nightlies, you might have noticed this already: previously, when you clicked the colored square on the left of a color code in the WebKit Inspector, it used to cycle through different color formats. That’s still possible when you shift-click it (alt-click on Windows), but a regular click will now spawn a color picker. It was on my WebKit Inspector wish list 2 years ago, and now seems to have finally made it in! No more need to switch to another app just to pick a color for an element on your page. It doesn’t allow you to sample colors on screen, but I presume that’s a lot harder to do.

Since you can easily customize the WebKit Inspector, I got rid of the confusing double background of the widget. Here are the selectors you can use for the color picker – though I’m not sure where the original yellow background is defined?

/* color picker styles */
.spectrum-container {
    background: #ffffc2 !important;
    border: 0 !important;
    }

Forget loading spinners, use a wait cursor

Mon, 20 Feb 2012 06:35:00 -0500

Update: Right after posting this I received quite a bit of feedback in defense of regular loading spinners. Some valid arguments in favor are summed up nicely in this Hacker News thread:

Cursors won’t work on touch devices of course.
Wait cursors might be too easily associated with a frozen browser/system.
A spinner may indicate more clearly which part of the interface is updating.

So think carefully before applying the following technique on a large scale. It might be suited in specific conditions though.

There are loads of funky “loading” animated gifs out there, and these days I also encounter a few CSS spinners. But a technique I haven’t seen a lot is simply using the cursor property to convey the message.

Desktop apps usually use the cursor to indicate that users have to wait. Most of the time the cursor is exactly where the user is looking, so they won’t miss the message. Browser support for cursor is very good too.

You shouldn’t solely rely on the cursor – graying out the loading parts of the interface works well too – but for your next web app you could try slapping a loading class to your body, or any other element, and using

body.loading { cursor: wait; }

You might have to explicitly add form elements and links to the selector, so they don’t trigger the default or pointer cursor. Adding !important won’t work. So something like this:

body.loading, body.loading input, body.loading a { cursor: wait; }

Here’s a quick demo. You can use other cursors as well, or even a custom one with the url(...) value – although animated images won’t work, and other restrictions apply.

Simple responsive design test page

Thu, 26 Jan 2012 16:32:00 -0500

There are some pretty complex testing tools for responsive designs out there. I even see people constantly resizing their browser window using on-screen rulers. The easiest approach to me is just a simple page with a bunch of iframes, like Matt Kersley’s test page. Because I always ended up refreshing the whole page rather than the URL bar on that page, I saved the file locally and tweaked it a little.

Somebody recently asked me to share it, so here it is. Just drop this HTML document in the same folder as your index page and open it – it’s dead simple, really!

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Responsive Design Testing</title>
    <style>
        body { margin: 20px; font-family: sans-serif; overflow-x: scroll; }
        .wrapper { width: 6000px; }
        .frame { float: left; }
        h2 { margin: 0 0 5px 0; }
        iframe { margin: 0 20px 20px 0; border: 1px solid #666; }
    </style>    
</head>
<body>
    <div class="wrapper">
        <div class="frame">
            <h2>320 &times; 480 <small>(mobile)</small></h2>
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="320" height="480"></iframe>
        </div>
        <div class="frame">
            <h2>480 &times; 640 <small>(small tablet)</small></h2>                   
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="480" height="640"></iframe>
        </div>                                                                                                                        
        <div class="frame">
            <h2>768 &times; 1024 <small>(tablet - portrait)</small></h2>                   
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="768" height="1024"></iframe>
        </div>
        <div class="frame">
            <h2>1024 &times; 768 <small>(tablet - landscape)</small></h2>
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="1024" height="768"></iframe>
        </div>
        <div class="frame">
            <h2>1200 &times; 800 <small>(desktop)</small></h2>
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="1200" height="800"></iframe>
        </div>
    </div>
</body>
</html>

Update: Ben Keen turned this into a very handy bookmarklet. Reloading the page will kill the effect of course, but still very useful for quick one-shot tests.

Update 2: Here’s another bookmarklet based on this idea by William Golden.

Small but important (and final?) change to linear gradient syntax

Thu, 19 Jan 2012 03:29:16 -0500

After redefining angles in gradients, another small but important revision was made to the linear gradient syntax last week. It’s outlined in full detail on Peter Gasston’s blog, but the gist is this: If you need a direction keyword, you’ll have to specify the destination keyword and prepend the word to. Previously you had to specify the origin of the gradient.

background: linear-gradient(left top, red, gold); /* old syntax */
background: linear-gradient(to right bottom, red, gold); /* new syntax */

Makes it a bit more readable and logical, so it’s a good adjustment. But how about the transition from old to new syntax then? Well, this will probably be the last edit to the syntax, as the CSS Image Values and Replaced Content Module Level 3 specification moved to the Last Call status. Browser vendors will likely only start using this new syntax when moving to unprefixed gradients, or keep supporting the old syntax for prefixed gradients (as Firefox 10 will do).

Therefore, if you already used unprefixed gradients with direction keywords – for future compatibility – you’d better edit these stylesheets.

On filters, -ms-filters and filters

Sun, 18 Dec 2011 17:07:49 -0500

In CSS, there have been filters for a long time. Microsoft first introduced them for Internet Explorer 4, producing a range of visual effects and transitions. Also called DirectX filters, we still occasionally use them today, for things like fallbacks for CSS gradients. They are proprietary though, and were never picked up by other browser vendors.

As a result, the Internet Explorer team decided to add the -ms- prefix in 2009. But soon after these filters were deprecated, and in IE10 they won’t even be supported no more. So you really never need to bother with the -ms-filter syntax, just use filter in those rare cases.

In the meantime, the filter property has been reborn however, this time for SVG filter effects applied in CSS. Partially supported in Firefox since version 3.5, they’re currently being formally specified, and also being implemented in Internet Explorer 10 and WebKit. These CSS filter effects will allow some very exciting Photoshop-like filters, like grayscale, sepia, blur, saturate, brightness, and much more. Coming soon!

The CSS profilers are coming!

Wed, 07 Dec 2011 15:35:00 -0500

Back in August I talked about the lack of benchmarks or performance tools for CSS. In the meantime, the fine folk we call browser makers have been working hard on new developer tools to do just that: measure CSS performance. First the Opera team showed off their upcoming style profiler, and now the WebKittens are tinkering on a CSS selector profiler too.

One of the features of these tools is to calculate how long your selectors take and then show a list of the worst offenders. But as you can see from the screenshots, and as noted by Pavel Feldman:

I can see selector matching taking single digit milliseconds. I know from the timeline panel that layout takes hundres of milliseconds or even seconds.

So the relevance of this information may be rather marginal. Perhaps more interesting then is the fact that the Opera Dragonfly style profiler shows the exact moment and location of paint events and layout reflows. Definitely some exciting developments to keep an eye on!

Native CSS nesting with new Hierarchies spec

Thu, 01 Dec 2011 03:35:00 -0500

Googlers Shane Stephens and Tab Atkins Jr. recently posted the first editor’s draft of a new specification on CSS hierarchies. The CSS Working Group has been paying close attention to what’s happening in the world of CSS preprocessors (like LESS and SASS), and this is another illustration of that. Take this code:

.error, .warning {
    padding: 10px;
    }
.error p, .warning p {
    font-size: 12px;
    }
.error a, .warning a {
    color: #f00;
    }
.error a:hover, .warning a:hover {
    border-bottom: 1px solid #f00;
    }

When the spec is implemented, you will simply be able to write it like so:

.error, .warning {
    padding: 10px;
    & p { font-size: 12px; }
    & a {
        color: #f00;
        &:hover {
            border-bottom: 1px solid #f00;
            }
        }
    }

The advantages are pretty clear: better readability and maintainability, and smaller file sizes!

If you’re wondering about compatibility, the spec says the following about this:

if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored

So a browser that doesn’t understand nested selectors will read the above example as:

.error, .warning {
    padding: 10px;
    }

While we wait for browser implementations, ~~it would be great if all CSS preprocessors added support for this syntax so we can start getting used to it today~~ you can actually start using this syntax today – it’s compatible with both LESS and SASS. (Thanks @dariocravero!)

Using letter-spacing breaks right-to-left text in Opera on Windows

Fri, 25 Nov 2011 06:03:00 -0500

Granted, this might seem a pretty exotic scenario, but a very plausible one nevertheless: using letter-spacing breaks right-to-left text in Opera on Windows. On Windows XP the character order seems to be reversed, and on Vista and Windows 7 the order is fine but characters are no longer joined – while scripts like Arabic, Urdu, etc. rely on this. (Thanks to @BifterComic for the Vista results.)

Here’s a JSFiddle to test, and some screenshots to get an idea. The first line is without any letter-spacing, the second one has a positive value, and the third line has a negative letter-spacing.

So if you have a page with RTL text, remember to reset any letter-spacing to avoid running into this issue. I filed a bug at Opera to report it.

Update: Apparently the Opera team was working on some issues with hardware acceleration, which fixed this bug. The fix is in the new development snapshot, so it shouldn’t take too long for this bug to eventually disperse into thin air.

Using an icon font as a web font – introducing Fico

Fri, 18 Nov 2011 04:19:41 -0500

A technique that hasn’t been researched and used enough in my opinion, is the use of an icon font as a web font. There are many advantages to this approach, rather than using images. You can:

infinitely scale a font, because they’re just vectors
use whatever color you like – even gradients in some browsers
add shadows, transitions, transforms, …
stop messing around with loads of files or sprites
rest assured it will work in most browsers – browser support for @font-face is very wide

One problem with icon fonts that can make them less than ideal for font embedding, is that they’re often big files. That’s one of the reasons I created Fico, a limited set of simple icons specifically tailored to use on the web. The icon set might grow in the future, but it will always remain a lightweight solution for using icons on your website. Give it a spin!

There’s some more info and techniques about this on the Fico website, and coincidentally Chris Coyier from the excellent CSS-Tricks posted this today as well: Icon Fonts are Awesome.

Working with 8-digit hex colors (aRGB) in Internet Explorer filters

Sun, 06 Nov 2011 12:06:00 -0500

You’ve probably come across the use of CSS filters as fallback techniques for RGBa colors or CSS gradients for example. They have their limitations and implications, but they do come in handy sometimes. They look something like this:

.awesomesauce {
    background: rgba(0,0,0,.6);
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#99000000,endColorstr=#99000000);
    }

Maybe you’ve noticed these weird colors that have 8 instead of the usual 6 hexadecimal digits. Well, these are aRGB colors, used in Internet Explorer filters but also in Android development among others.

The syntax is pretty easy: first a pair of digits for the alpha channel and then 3 pairs for the RGB channels, just like regular hex colors. But instead of specifying alpha as a percentage or a floating point like for RGBa colors, it is defined in a range from 00 to FF. To calculate the hex value from a decimal number in JavaScript:

hexAlpha = Math.floor(decimalAlpha * 255).toString(16);
// so:
// rgba(255,255,255,0) = #00ffffff
// rgba(0,0,0,.5) = #7f000000
// rgba(255,255,0,1) = #ffffff00 = #ffff00 = #ff0

To make it even easier, there are several RGBa to aRGB convertors out there.

Complete Compass API in iOS 5

Fri, 28 Oct 2011 05:36:59 -0400

One new feature of iOS 5’s Mobile Safari that was not known back when I wrote this post, is an extension to the DeviceOrientation Event API. There was already an implementation of the official yet limited spec in iOS, but the Apple team didn’t have the time to wait for a resolution and implemented two new properties that allow developers to get full access to the real world orientation in Mobile Safari now!

James Pearce from Sencha took the new API for a spin and created a complete web-based compass. If you’re running iOS 5 and you’re on an iPhone 4 or 4S, iPad or latest generation iPod Touch, just tap the image below. Now go ahead and make your web app orientation-aware!

Some notes on bouncy CSS transitions

Fri, 21 Oct 2011 09:05:57 -0400

Earlier this year the CSS transitions specification was rewritten so that transitions with a custom timing function (using cubic-bezier) would no longer be clamped between the start and end values, making it possible to add a rubber-band bounce to your transitions. Opera and Firefox already implemented this, and recently the related WebKit bug was fixed, so we can start experimenting with bouncy transitions now!
This rubber-band bouncing doesn’t only work for things like position and transform, it equally applies to animated colors, shadows, borders, font-sizes, etc. Of course, transitions won’t extend across minimum or maximum values – you can’t go darker than rgb(0,0,0) for example.
If you need real bouncing though – with more than one bounce – you’ll still have to use keyframe animations, as cubic-bezier curves only take two user-defined control points. Dan Eden made a nice library of ready-made animations to drop into your project. Apparently browser vendors and spec writers are currently looking into defining more timing functions like bounce however.
If you want to play around with cubic-bezier curves look no further than Cubic-Bezier or Ceaser, two essential tools to comprehend and play with CSS timing functions.