Bricss

pointer-events: none !important; opacity: 0 !important;

This gives you scrollbars that appear during touch and keyboard interactions, and fade out again after a few seconds. Nice.

_I've posted the following earlier this week on [Dribbble](http://dribbble.com/shots/904376-caniuse-com-redesign), 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](http://caniuse.com) together with Alexis Deveria aka [@Fyrd](http://twitter.com/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](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](http://dribbble.com/shots/904390-caniuse-com-redesign-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](http://dribbble.com/shots/904376-caniuse-com-redesign) or [Twitter](http://twitter.com/bricss)!

Here's a second topic I talked about in my [Fronteers 2012 jam session presentation](http://fronteers.nl/congres/2012/jam-session). 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](https://addons.mozilla.org/en-US/firefox/addon/firesass-for-firebug/), but Chrome users have been out of luck until recently. This is where source maps come into play. [**Source maps**](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/) 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. **Heads up**: most of the instructions below are deprecated. There's an [excellent and up to date overview of the necessary steps](https://developers.google.com/chrome-developer-tools/docs/css-preprocessors) on the Chrome DevTools blog. A [fairly recent commit](http://trac.webkit.org/changeset/123768) 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](http://f.cl.ly/items/1t3G383K3n0U1Z0G3i3L/settings.png) in the settings, and [Support for Sass](http://f.cl.ly/items/0a2I0z3g0Z1O0P403C0M/settings-experimental.png) 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.

This post is the first topic I discussed in [my jam session presentation at Fronteers 2012](http://fronteers.nl/congres/2012/jam-session). 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. [](http://dabblet.com/gist/3820382) 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?). [](http://dabblet.com/gist/3820382) Yes, it’s an experimental property, and yes, it’s only supported in some WebKit browsers now. But [according to caniuse.com](http://caniuse.com/#feat=css-filters) 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](http://dabblet.com/gist/3852573) with a transparent PNG: [](http://dabblet.com/gist/3852573)

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](http://blogs.msdn.com/b/ie/archive/2012/05/31/windows-release-preview-the-sixth-ie10-platform-preview.aspx), and this week the [Firefox](http://paulrouget.com/e/unprefixing-in-firefox-16/) team anounced exactly the same. This is all great news. Even better, [as Lea Verou noticed](http://www.netmagazine.com/features/hot-web-standards-june-2012): > 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.

One of the lesser known CSS properties I'm really excited about is `box-decoration-break`. From [the official spec](http://www.w3.org/TR/css3-background/#box-decoration-break): > 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](http://jsfiddle.net/lensco/A7ZFt/) 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](http://dev.opera.com/articles/view/css3-border-background-boxshadow/#box-decoration-break) (Opera 10.60). Firefox does have the [`-moz-background-inline-policy` property](https://developer.mozilla.org/en/CSS/-moz-background-inline-policy) 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](https://bugzilla.mozilla.org/show_bug.cgi?id=613659). Last week [support for parsing the property landed in WebKit](http://trac.webkit.org/changeset/118853), with the rendering part still to be implemented. Let's hope `box-decoration-break` will be available in all browsers soon!

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

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](http://jsfiddle.net/lensco/YjRLS/) 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](http://trac.webkit.org/changeset/116009) 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](http://trac.webkit.org/wiki/LayoutUnit) on this matter, and an [article on subpixel rendering and the CSS Object Model](https://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx) from the IE team.

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](http://www.w3.org/TR/cssom-view/#extensions-to-the-window-interface) 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](http://www.paulrhayes.com/2011-11/use-css-transitions-to-link-media-queries-and-javascript/) in his fork of the match­Me­dia poly­fill, using transitions on dummy elements and watching for the `tran­si­tio­nEnd` 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](http://adactio.com/journal/5429/), 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!

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

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.

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

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

In CSS, there have been `filter`s for a long time. [Microsoft first introduced](http://msdn.microsoft.com/en-us/library/ms532849(v=VS.85).aspx) 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](http://blogs.msdn.com/b/ie/archive/2008/09/08/microsoft-css-vendor-extensions.aspx) in 2009. But soon after these filters were deprecated, and [in IE10 they won't even be supported](http://blogs.msdn.com/b/ie/archive/2011/12/07/moving-to-standards-based-web-graphics-in-ie10.aspx) 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](https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html), and also being implemented in [Internet Explorer 10](http://blogs.msdn.com/b/ie/archive/2011/10/14/svg-filter-effects-in-ie10.aspx) and [WebKit](http://trac.webkit.org/changeset/100565). These CSS filter effects will allow some very exciting Photoshop-like filters, like grayscale, sepia, blur, saturate, brightness, and much more. Coming soon!

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!

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!)