blog

My short talk how CSS Flexbox will help creating “flexible” Web Apps. It was recorded at this years Fronteers Jam Session.

Quick note: @kizmarh actually did the header example with floats alone by reordering the DOM elements (nice trick). But I think it’s still a bit limited and only one “flexible” element is possible. Also, Flexbox has lots of other cool features I haven’t mentioned.. like reordering and wrapping.

PS. This was my first time ever talking in front of people.. so it might be a bit rough and rushed. ;-)

Update: Uploaded the Mail UI example, but the code might be a bit messy. I just quickly did for the talk. Also, only tested in Chrome.

Media Query splitting

When Media Queries got introduced and people started out with Responsive Web Design, I used to overwrite my Desktop styles to make it fit on Mobile. Later I shifted to “Mobile first” where you start out with the Mobile styles and overwrite them for Desktop sizes. But on a recent project I’ve started using a different approach by splitting the styles instead of overwriting them. It goes something like this:

Here a “Mobile first” example:

.box {
  background: #777;
  width: 100%;
  box-shadow: inset 0 1px 3px #333;
}

@media (min-width: 800px) {
  .box{
    width: 760px;
    margin: 20px auto;
    box-shadow: none; /* reset */
  }
}

And here MQ splitting.

.box {
  background: #777;
}

@media (max-width: 799px) {
  .box {
    width: 100%;
    box-shadow: inset 0 1px 3px #333;
  }
}

@media (min-width: 800px) {
  .box{
    width: 760px;
    margin: 20px auto;
  }
}

So the idea is to keep a default CSS block with all the shared properties and for the rest split them up into different Media Queries. For example max 799px and min 800px, so it’s always either or.

Yes, there are now 3 CSS blocks instead of just two, but I find it much easier to have this mental model. When adding, removing or changing CSS properties, you don’t have to be worried of messing up. They are now more clearly separated and sandboxed. In some cases it could also lead to less code overall because you don’t have to reset a lot of stuff that is not used in the other Media Query.

You could still start out with a “single version”. It can be mobile OR desktop, whatever you prefer to do first. If it’s desktop, the example above would look like this:

.box {
  background: #777;
  width: 760px;
  margin: 20px auto;
}

Then, when it’s time to split up, just start moving your properties that are different into each Media Query.

The only “clean up” or “refactoring” you have to do after lots of changes in that split mode -> check if there are properties that became the same again and could be moved back to the shared (default) block.

I’m not quite sure yet if I will move to splitting MQ like this on all new projects. It was more an accident than intentional, but thinking about it some more, I quite like this way and am gonna try it out on some more projects.

Update: One drawback, as pointed out by Francisc Romano: It doesn’t work well for browsers that don’t support MQs because the default styles don’t get applied. So for IE8 and below a conditional stylesheet could be used. You might need one anyways. Or you could add just some really minimum styles to the shared block as a backup.

Also, you don’t have to use MQ splitting on every single selector. I might makes sense to only use it on selectors where the difference between mobile/desktop is high. In case you like to separate everything, you could create 3 different files and use MQs in the <link> or use a build process so you don’t even have to download the unused styles.

SVG Stacks

Image sprites are wildly used for downloading lots of icons or UI elements all at once with just a single HTTP-Request. But they are somewhat cumbersome to use because you have to calculate the background-position offsets. You can’t easily add, remove or reorder them without recalculating. Or change the size without a neighbour peeking in from the side.

How could it be solved? Well, by stacking them all on top of each other, turn off their visibility and only show the one you want. Have been wishing this would be possible for a while.. and then this happened (read from below):

Oh, nice! The demo already works in Firefox. That’s great news.

There are alternatives to SVG Stacks with better browser support by using embed, iframe, object or img elements, but I still prefer background images because of their easier positioning/resizing. So let’s hope more browsers will also add support for that.

So how does it work? It’s actually pretty simple. Have a look at the source of Erik’s SVG file.

First we give each of our icons in the SVG file a unique ID and the same class name, add some CSS to hide all icons and only display the one that gets selected with :target. And now we can use a hash in the URL to pass the ID into the SVG file, like background: url(icon.svg#ID).

Big thanks to @erikdahlstrom for that technique.

Update: A couple bugs have been added to other browsers so you can track its progress. Opera: “CORE-37596” (no public link). WebKit’s Bugzilla : 91790, 89983, 89985. And please star it in Chromium Issue 128055.

Update II: Michael Schieben created a tool to that turns a folder of SVG files into a single SVG Stack: SVG Stacker

Update III: Looks like “SVG Stacks” got shot down by the WG. But there is still some hope left and it’s probably still in flux. So instead of url() we could use image().

We’re in an icon-sharpness limbo

With the rise of Retina displays people are looking for resolution independent alternatives to PNG icons. Some fell in love with font-icons, some are shouting “SVG”. But I’m sorry, if you’re looking for a silver bullet, I’m afraid it doesn’t exist. Let’s take a closer look at our options:

Icon fonts are awesome, but..

they are not sharp. I mean really sharp, pixel-perfect kind of sharp. Using font-face for icons has become quite popular. I have been promoting and even started collecting them. But there is a flaw that keeps bugging me. They are still a tiny bit blurry on “non Retina” displays (which are still a huge majority). Try out the size slider in Chris’s demo and take a very close look. It varies at different sizes, but they all have this “half-pixel blurriness” problem. It might be hard to notice, so here a zoomed-in screenshot at 15px (also removed the background noise):

The subpixel anti-aliasing works great on curves, but not on straight lines, there it just doesn’t look sharp. In theory you could use font hinting to snap the icons to whole pixels. But so far I’m not aware of any icon-set doing that. Also I’m guessing it’s a lot more work and the hinting data might increase the file size significantly. Edit: @thijs notes that hinting only works on supported platforms and won’t help on OS X, iOS and Android.

SVG to the rescue?

Well, not really. The big advantage of using SVG icons would be that in their original size (not resized), they look pixel-perfect sharp. But once you start resizing, they have the same subpixel blur problem until you reach multiple of its original size. Notice the inner cross.

In practice using only multiple sizes probably should be ok. You create all your icons in a base size, let’s say 16px and you use a bigger version for action buttons in 32px or 48px.

Edit: @erikdahlstrom + @Marco_Rosella mentioned: shape-rendering:crispEdges. If used on individual rect(angles), they can be forced to pixel-snapping. Might not always be perfect, but keeps it crisp. Test in this jsFidde.

Problem solved? I wish, but there are other issues like:

There is not a lot of good SVG icon sets available.
Lack of SVG sprite creation tools.
Can’t change the color with CSS. It is possible, but only when used with inline SVG and I don’t feel happy adding big SVG chunks to the markup.
No effects.. like drop shadows. (SVG has filters, but again.. you can’t easily change them in CSS).
And the biggest bummer of all.. bad browser support in Firefox and Opera when an SVG is used as a background-image. It appears that the SVG actually gets converted into a bitmap and when resized with background-size, it doesn’t get redrawn, just scaled up, which makes it look really blurry. This kinda defeats the purpose of using a Scalable Vector Graphic.

Here a fiddle to test it out.

You could use inline SVG or SVG as an <img> element, but that makes it hard to be used as a sprite. Maybe with nested elements and overflow:hidden? Anyways.. just not as straight forward and flexible as with background-image.

Edit: David Bushell found a workaround by starting large and only scale down.

PNGs

Lots of icon fonts also come with a PNG version that you could use instead, but then you need a solution for showing a HiRes version on Retina displays. Using a device-pixel-ratio Media-Query should help you out. Or Apple just implemented -webkit-image-set, which looks promising, but still is gonna take a while.

So what should you do? As I said.. there is no silver bullet, but..

Here a little guide that might help.

When starting a new project, during prototyping and development, use font icons. Nothing beats the freedom of quickly and easily swap icons, change colors, try out text-shadow and other effects.
Then at some point you have to decide if it’s worth the trouble that comes when using SVG icons or PNGs. It’s a tough call and in the end it all depends on your requirements and priorities. It almost needs a flow-chart. ;-) You’ve to be ok with all their limitations described above. See if the available budget allows for the extra work, count how many icons there are in total and if you need them in different sizes or not.

There’s just no single image format suitable for everything and probably never will be. So who says you can’t mix them all together? Maybe best is to use PNG served in many different sizes for your high fidelity, multi-color logo and other graphics. SVG icons for your navigation that stays the same size, but also look sharp on Retina displays. Responsive inline SVG for bars and charts and an icon font for all your different button sizes. We’ve mostly been doing that anyways.

A look into the future

Is there a way to get out of this icon-sharpness limbo? Well.. let’s just wait a little.. once we have Retina displays everywhere (ok, could take a couple years), the subpixel problem will be gone and maybe browsers will have fixed the SVG issues and we can truly celebrate our resolution independent icons? But even then, we still would’ve to deal with the problem that details in icons don’t scale. Update: Media Queries in SVG might solve that.

In case I’m missing something, you can send a Tweet or write a comment on G+. Thanks.

What is Responsive Web Design?

Yesterday I tweeted this:

My excitement for Responsive Web Design is fading a bit. It’s great for simple websites, but not enough for more complex web apps.

On mobile you don’t just wanna shrink and hide some stuff.. you wanna change behaviour.

It caused some discussion and confusion. What I meant was that next to using media-queries to adapt to different screen sizes, we should also consider other aspects that improve the User Experience. Like changing behaviour trough JavaScript, optimize for a different input method like touch and be responsible with the often lower bandwidth. @fofr came up with a great hack to link Media Queries and JavaScript.

I think the problem is that in @beep’s original post, it mostly was described as a media-query, flexible-layout thing: “Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design”. But @danielmall notes that it’s an approach and not a technology and @vasilis sees responsive design as using client side techniques to optimize the experience.

So if you’re also one of those less educated people like me: The term ”Responsive Web Design“ has either evolved in its meaning, or we didn’t understand it from the beginning.

Another angle on skeuomorphs

There is a good post about skeuomorphs titled Skeuomorph, Pt III.

Also, next to touch and smell, there is another problem with skeuomorphs on digital screens. Changing the view angle. When moving your head, everything stays the same. It doesn’t change the 3D perspective, it doesn’t change the shadows and highlights. It still feels like a flat picture of something real.

Maybe one day we can add a bump map to create more dynamic shadows/highlights and a screen surface that sticks out. We might also get multiple light sensors so we can adjust according to our real light sources. How cool would it be to move your tablet closer to your lamp and see the shadows and highlights change.

I’m not entirely against using Skeuomorphs in our designs. I do it too. Without being able to use textures and fake 3D, it would quickly get boring. But maybe something to keep in mind: Using Skeuomorphs on desktop screens are way less problematic than on tablets or phones because on desktops you don’t touch it with your finger and you mostly keep a straight angle.

Update: @apexsier points out that such a directional light sensor is called Light Field Sensor and already in use by the Lytro camera.

Update II: Seems Apple is already working on it.

Update III: In iOS6, when tilting the divice, the metallic slider-thumb changes reflection.

Force Lion’s scrollbar back

Personally, I prefer the hidden scrollbar, but in case you really need it, you can just overwrite the default and force the srollbar back like this:

::-webkit-scrollbar {
    -webkit-appearance: none;
    width: 7px;
}
::-webkit-scrollbar-thumb {
    border-radius: 4px;
    background-color: rgba(0,0,0,.5);
    -webkit-box-shadow: 0 0 1px rgba(255,255,255,.5);
}

See the demo.

PS. And as an added bonus, it gets rid of the ugly scroll-track in Chrome and makes it look more consistent.

PSS. If you only want it on Lion, here with a JS sniffing script added.

My flirts with CSS3

At my day job I mostly work with Flash, AfterEffects, Photoshop. About a year ago I wanted to try something new and created Shitty Day using HTML, jQuery and CSS. And a couple months later, after I discovered that CSS3 can do animations, I did a photo-only tumblr theme called Organ. Nobody really cared until Cameron Moll (thanks) posted it on his blog and I got asked to create an official theme. It got featured in the theme garden and I was like.. wow.. it seems people really like this CSS3 stuff. So I kept on experimenting and created some more CSS3 demos.

I’m really happy that most people enjoy them. But there are also some concerns. If you look at all the demos, you’ll see that most of them only work correctly in -webkit and some just in Safari. And they also lack a graceful degradation. There are people like Paul or Divya that have been pushing me to make them more cross-browser. Thanks and sorry, for letting you down so often. I can understand that some say: If it’s not cross-browser it doesn’t “count”. And Web Designers have a responsibility and so on..

Well, this is just a hobby for me. I do it only for fun. Doing cross-browser support is the exact opposite of fun. Some might get a kick out of it, but for me, I would just be kicking the wall non-stop. That’s why I usually don’t even try and jump right to the next demo. Or call me lazy, that’s fine too.

But I guess the main reason why all my experiments work best in Safari is the tool I’m using: CSSEdit. If you don’t know about it, there’s one killer feature that changed everything. I would say, if it wasn’t for that feature, I probably would’ve never started doing CSS. It’s the Live Preview! Every change you make in your CSS get’s instantly updated. It’s like Firebug. Because I like to try out new stuff, I don’t know upfront how to do things.. I kinda just throw properties in there and start tweaking the numbers till I get to some interesting result. Without Live Preview, I would have to save the file, switch to the browser, refresh, switch back to the editor and start over. For the basic stuff you get things usually right without having to see a preview, but not if you’re trying to do Photoshop-like styles with CSS. Can you imagine having to save for web your Photoshop design just to see your changes? Insane right? So because CSSEdit uses Safari to render the Live Preview it automatically will work best in Safari, so there you have it.. blame them. ;-)

Unfortunately I’m still waiting desperately till CSSEdit get’s updated to support CSS3. I’m puzzled what they are waiting for, if browsers already start dropping prefixes. They could have such a nice head-start before the big guys like Adobe start to add it. Heck, there are tons of online CSS3 generator tools and there is even and app for the iPad. But nothing for desktop? WTF?

Wait a minute.. online tools. Online? Damn, that’s it! This will solve everything! A complete HTML/CSS editor in the browser with live editing. Something like jsfiddle, but with auto-complete and a GUI. Things like box-shadows, text-shadows, gradients just scream to be manipulated with sliders. But the best part by far.. you could do your cross-browser hacking right there in any browser you want to support. Maybe such an online editor is technically not possible with older browsers? Or extremely hard to do. Or just have limited features. I have no idea. But trying to add all possible web rendering engines into a desktop editor sounds way harder. The term designing in the browser would get a whole new meaning, because you’re literally designing in the browser.

Also all files are kept in the cloud. After doing changes, you could just save it, push it to your live server or commit it to something like GitHub or so. Also some kind of SVN or collaboration feature with co-workers could be build in.

Who is gonna do it? Is somebody already working on it? Is that why CSSEdit doesn’t get updated? Or maybe Adobe? Will they move to a subscription model with a “Dreamweaver Live”? I also would love if 37signals would give it a try. They have the cloud experience, they do web stuff, they have the customers already paying with a subscription model. And how awesome would that be with some integration with their current products. Let’s see.

Thanks for reading. Tweet your Comment.

PS. What’s next? There probably won’t be any new demos for a while. No, not because I gave up on CSS3.. because I’m already working on the “next big thing”. ;-)

Update: Here a couple tools that go into that direction. Thanks for sharing. Symbiote, LiveReload, CSS3 auto-complete for CSSEdit, Akshell

The Future Post

Sometimes when I write a new post I wish I could set the post date in the future. I don’t mean publish it on a later date. Publish now, but the blogging system is aware that the post is referenced into the future. The problem now is, that when I write about an upcoming event, visitors will see it too early and when the event get’s closer, that post is already buried with new ones.

As an example, let’s say I plan to attend Chirp, the Twitter Developer Conference. I probably post about it when I first find out about it, or when I get my ticket and maybe after the event already happened. But Nobody will see it right before the event occurs!!

Below a quick example:

The “future posts” appear above normal posts for an easy glance what’s coming up. After the set time passed, a post would fall below the NOW line and you could even update it with news from the event.

A tumblr theme could look like this:

{block:FuturePosts} ... {/block:FuturePosts}
<div id="now">NOW</div>
{block:Posts} ... {/block:Posts}

Actually any kind of stream with chronological posts could use it, even Twitter or Facebook statuses. It would kinda be like a public calendar. Let’s see.

This is the new Design Process I’ve been trying to use lately. Skipping Wireframes and Photoshop comps! This video shows all the different design steps needed to create the Shitty Day site. As you can see, I tried to implement some principles I picked up during the years:

Getting Real: Create a working prototype first, worry about Design later.
Design from the inside-out (can’t remember the link): Concentrate first on the content (Tweets), then the things around it.
KISS: Keep it simple..

So, where are all the wireframes and Photoshop comps? They got skipped..!! no wait.. actually you could say that the wireframe (basic layout at the beginning) and the Photoshop comp got created straight with HTML/CSS and then constantly changed and refined.

The tools I used for this project were Espresso for the HTML markup and then CSSEdit for styling. Later in the process I used Photoshop to create single images like the background tile, paper holder and so on, but never for the layout.

It all seems pretty easy and straightforward, but I think this process works best for smaller simple sites. For bigger and more complex projects, the traditional approach might still be better. Also before I started I had sketched out the idea on a notebook and had already a pretty clear picture in mind how everything should look and work. If you would ask the client for feedback during the process, they would probably tell you nonstop how ugly it looks. ;-)