It was last year, in July. 2012. I was at my peak, I had the world in my palm and then I blew it.

Late 2011 I got a call from Nicola Fratter. We’d met that year in Barcelona at the OFFF. We’d hit it off; him, Yari D’Areglia, Nicola Armellini and I. We spent most of the three festival days together. It was wonderful and he mentioned, half joking, that he should organize his own conference. We encouraged it, but thought nothing of it. Then the call came.

Nicola invited me to speak at the conference he was organizing. He was to call it Feed the Brain and it was to be held in Venice. Venice. I always wanted to see that place, and here was my chance to finally see it and have my first time speaking experience, as well.

I later saw the rest of the speaker lineup. I was the noob. I remember being shocked for a while. I was going up on the same stage as Janko Jovanovic, Brendan Dawes, Marko Dugonjic, Mike Kus and even Smashing’s own Vitaly Friedman. The guys from Jumpzero, Nicola Armellini and Yari D’Areglia were on the panel as well, though, as it turned out, it was only Nicola who took the stage. I knew I had to get up on that stage and be the best I could. And I had nothing.
Some time passed. Quite a bit of time passed. It took me about 6 months to stumble upon a subject I deemed worthy to be spoken about in front of industry experts I almost idolize and who knows how many peers. Peers who were going to look at me and, rightfully, go “who is this douche?”.

The rise

It was Easter last year. I was working on the problem of determining the actual physical size of a device via Javascript (or any other accesible web technology for that matter). And what started as a simple research into an obscure peeve of mine turned into a full fledged scavenger hunt. I didn’t eat that day, I barely got any sleep.

I went straight for the resolution media query. It didn’t work in any browser or any device/platform I tried. It seemed a bit strange that it didn’t, but I went on, trying measurement after technique. As a last resort I even looked into scaling SVGs to 100% and sniffing their width with Javascript. It made no difference. It was cold and raining outside, heavy clouds filled the sky and not a ray of sunshine shun that day, but with each step I uncovered, I felt closer and closer to a solution. Or at least an answer. That answer, as it turns out, was 96.

96. I kept hitting 96dpi/ppi (the web’s full of people interchangeably using these units) time and time again. And then the final nail in the coffin came. Every browser presumes 96dpi devices. I was angry, sad, nearly neurotic from too much caffeine and nicotine and not enough food or water. I even called and interrupted my friend Paul‘s Easter dinner to pick his brain. He tried but didn’t manage to calm me down. A few more hours of scouring every corner of the web for any crumpet of information on the subject followed. To no avail. 96. Even the W3C themselves have it backwards, stating that too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content. Even after knowing this for some time, seeing that line written in the actual spec still makes me want to send emails to the W3C asking them “Have you gone full retard?!”.

EDID

The next day I went back to it. And found something. I found EDID, the industry standard for storing display information. EDID has been in use for almost 30 years now, bless you VESA, and is supported pretty much everywhere. And there’s software that can read EDID, here and there, for every platform.

So, why don’t browsers read EDID? Is there a security risk? Hardly. Is it difficult to implement? Not even close. Are there any hardware limitations? Please. Would it impact performance? Perhaps, but we have browsers capable of leveraging 3D graphics* nowadays. Is a tiny little string containing the actual, physical width and height of a screen really that heavy on performance?

If you’ve read so far, you might be curious to know why knowing the physical size of a device is important after all. Quite simply, it’s the natural, logical next step to Responsive Web Design. What is the greatest lesson that RWD has taught us? The web is not made of pixels, it’s a flexible environment used by real world beings: us. The old 960px grid was silly. It was a lie. The pixel is a lie. We all had a mental nuclear meltdown when we realized it and we’ve been struggling to find ways of avoiding pixel based work ever since. Working with physical units instead of digital ones would be the final step in completely moving web design and development from a non human centered focus, to a truly future proof activity.

Why physical units?

Knowing and, thus, working with actual physical dimensions gives us more freedom at less cost.
Think about having true cross-browser and cross-platform sites/apps. Simply write button{ width: 1in; } and you can rest knowing that no matter the device, be it phone, computer or a fridge, that button will always be large enough for most people to press it without difficulty. Bam, design for humans, not devices.

Which brings me to my second reason why using physical sizes is a good idea: true showcase. You could showcase actual physical things at a 1:1 scale ratio on every digital device you could conceive. Having spoken about this with an actual online cosmetics retailer the reply I got was simply “I need this asap; money’s no object”. So the interest and the application for this technology exists. Yet no one is actively asking for it.

The fall

The conference day came. It was a most humid day in Venice and having found out I was the first speaker just the night before the conference was not helping my nervousness. And then I went on stage. And I told everyone there the story of EDID and how I was hoping for a community-wide revolution. I even had a plan to set up a petition website and gather as many followers on this as possible and then persuade browser makers, OS makers, video card makers, whoever was needed, that we needed EDID. But the audience reaction was mute. Some people asked a few questions, but most had a blank look on their face. They didn’t get it. Some of the speakers did, though. Most notably Vitaly, Marko and Nicola Armellini.

Vitaly was even kind enough to extend an invitation to write a post on Smashing Magazine about this subject. Which I gladly accepted and I still thank him for it. Following, a mere few months after the conference, as I was about to launch the petition website and subsequently the Smashing post to go with it and persuade all of you fine people to join me in my windmill fight this thing happened. And I was crushed and happy both at once. It meant that someone was, in fact, thinking about this problem seriously, and it meant that widespread support is to arrive faster than I, one man, could do by myself. Moreover, it wasn’t going to be done via a public EDID function, but rather by implementing the resolution media query.

I had failed. I wasn’t fast enough, connected enough, resourceful enough to make good on my promise of a free EDID. But that doesn’t mean the story’s over. Soon enough all the cool things I mentioned earlier will be widespread. And when they will, it will mean yet another paradigm shift in the ever changing world of web design and development. I may have failed in my endeavors, but I, like you, am a designer and we’ve grown professionally to believe and thrive off the benefits of the entire community, not the one person’s ego. Today, I’ve shed all resentment towards this issue and eagerly await the time when we will, in fact, be able to truly design for humans.

Thanks for reading.

* We don’t talk about VRML. VRML is Valdemort.

Cheers, all!

Time

It’s called time and it’s in honor of my mother, Magda, with whom I share my love of photography, fine art and design. Love you, mom!

At first Aral suggest using font-size: 1px on the element which would provide a 1:1 ratio between rem and pixel but, as Aral mentions, that’s not a real option as, and I quote, On some browsers it erroneously conflicts with the minimum font size setting in the accessibility settings. Well, that sucks hard. He then goes on to explain how we can use CSS preprocessors to achieve parity, regardless of the aforementioned browser quirks.

But here’s the thing: not everyone likes or prefers using preprocessors. I’m one of those people* and I know a great deal others who will stand by me on this one. Furthermore, there are projects where using preprocessors is just overkill. So, should rems be limited to preprocessor powered projects? Of course not, that’d be silly. But there is hope yet.

Parity for everyone

Aral focused on using a 1:1 parity, which is nice and elegant and all, but as mentioned above, doesn’t work reliably. So, I say, why not use a 100:1 parity? Seeing as rems, and ems for that matter, are a relative percentage unit, using a 100:1 parity would work just like a 1:1 parity, with a decimal point 2 spaces to the left. As such:

1
2
3

html{ font-size: 100px; }
     h1{ font-size: 0.36rem; } /* renders 36px */
     p{ font-size: 0.18rem; } /* renders 18px */

And that’s it. No weird maths, no pesky browser bugs to get in the way, no jumping through hoops, and will work for projects which do not employ preprocessors.

Cheers, all!

* I do appreciate the amazing features that preprocessors like SASS or LESS bring to the table and have actually used SASS in a few projects. I’m not hating on the technology, I’m saying I prefer the vanilla flavor.

Required inputs

1

<input type="text" required />

Simple and sweet. And you should know it by now. But, in case you don’t, this is the HTML5 way of doing form validation on required fields. That’s really all there is to it.

Number inputs

1

<input type="number" placeholder="Digits, dude!" pattern="[0-9]*" />

This one has two tricks. The placeholder bit replaces the old “click and the text disappears” we used to have happen with JavaScript, while the pattern attribute defines what kind of data the input will take. The pattern attribute is especially useful for mobile users as focusing on the input will bring up either only the numbered keyboard or the regular keyboard switched to number view, depending on phone and operating system. Both are a heck of a lot more useful than pulling up the regular keyboard and having to switch to number view manually.

Call me maybe?

1

<a href="tel:0123456789">Prank call at 0123456789</a>

So simple and effortless, this one. Simply prefix tel: to a phone number (as you would enter it on your own phone) as the href of an anchor. For extra points, I set a cursor: default; on desktops and laptops as they’re less likely to be able to use this functionality.

Before, there was

1
2
3
4
5
6
7
8
9

span:before{
    background: #E2F1E6;
    border: 1px solid #E0E5E8;
    content: '';
    display: block;
    float: left;
    height: 16px;
    margin: 0 10px 0 0;
    width: 16px; }

Someone, somewhere decided it was a good idea to only use :before and :after to insert icon fonts. Not that that’s a bad idea, quite the contrary, but rather I’d say that we can use these very useful pseudo-elements for more than that. In fact, with the above code, you insert a tiny little green box which can be used as a kind of icon. Without an icon font.

Tuck belly, straighten spine

1
2
3
4
5
6
7

b, strong{ 
    font-family: SansationBold, sans-serif;
    font-weight: normal; }

i, em, address{
    font-family: SansationItalic, sans-serif;
    font-style: normal; }

Whenever I use a site-wide custom font, in the above example I’m using Sansation, I always reset the weight for b and strong and the slant for i, em and address to avoid faux bolds and italics. This is targeting Firefox, mostly, but other, more obscure browsers overcompensate as well.

They aren’t the greatest or most advanced tricks in the world, but they’re sure to make your project more usable and provide your users with a better experience.

A quick note

I am aware that HTML5 doesn’t require one to use self closing tags. However, I still use them on account of my code highlighting plugin being a bit old-school. Until the plugin is updated, the self closing stuff stays.

Cheers, all!

The changes have already been added to the Starter Pack archive and, of course, you can download the latest version over nya:
Get the Starter Pack

Cheers, all!

Get the Starter Pack

So, what’s new

As I said, a lot of stuff’s new. The last update had a bunch of useless markup in the html file. That got thrown out real quick. Instead, now you’ll just find some basic structure to get you going. Nothing too set in stone, of course.

I focused a lot on the <head> area. Things like humans.txt and <> have become a widely recognized standard so it just makes sense to try and push people into using them.

Paul Irish’s box-sizing fix has its honor role well set in there. It’s a simple technique that has proven itself time and time again. If you’re not using it, well, you should.

I’ve stripped the old head media queries for more practical and faster queries, straight into the main stylesheet. Breakpoints are obviously something you should be adjusting according to each project.

I’m a very, very big fan of icon fonts. There’s nothing bad I can possibly say about them and in trying to push more people to use them, I’ve included the wonderful Modern Pictograms by The Design Office.

There’s very little in terms of IE stuff, as opposed to previous pack releases. This time, you’ll only find the “render-me-better” meta tag and an ie8.css file. No one in their right mind should support IE6 or IE7 anymore. It’s 2012, people! Get with the program!

This latest release also marks a change in update policy for the HTML5 Starter Pack. Releases will be more incremental, each with its respective blog post and must-have social buzz. No more once-a-year updates.

Well, I hope you all find the new update useful. See you in the comments!

Cheers, all!

So, I set out to pull off my own take on the whole CSS3 Stitched Effect. Take a look at the demo and below I’ll explain some of the code.
Demo

The HTML

I used this image from SXC as a leather texture. The brown texture is the same picture, just scaled down and slightly edited in good ol’ Photoshop. The markup is really quite simple, just two divs.

1
2
3

<div id="stitch">
<div id="inner-stitch">Just a CSS leather stitch</div>
</div>

The CSS

There’s a fair bit of stuff in the demo but it all boils down to two properties: border and outline. Use these two properties with the same width and alternate colors and you have yourself a stitching effect.

1
2
3

#inner-stitch{
border: 1px dashed #000;
outline: 1px dashed #fff; }

Certainly, achieving this effect requires more than just the use of two properties, it's got a lot to do with getting the right colors, maybe doing some rounding off at the corners, subtle stuff like that. It's not a groundbreaking technique, of course, but it does prove one very important point: even a simple technique such as this one takes a bit of elbow grease to get right if quality work is what you're after. Just slapping code in a project and hoping it'll be brilliant right off the bat is a pipe dream.

Cheers, all!

A quick side note, if you’re unsure about which is best, SASS or LESS, this post by the almighty Chris Coyier should answer it.

About 2 years ago, while working at Mind Magnet Software, I had my first run-in with SASS as part of a custom Ruby on Rails project for a client. And it was a gruesome experience, to say the least. Back then, we were using .sass syntax, as SCSS was just beginning to show its head and Compass worked about three days a week. I exaggerate, but the point is, back then, the technology wasn’t mature enough. Working over a RoR project for the first time didn’t help, either.

Since then, I ignored SASS and focused more on interaction design and usability in the ecommerce world. But every now and again, the subject of preprocessors kept popping up either on Twitter, Facebook or the odd secret designer society group (what, you guys don’t have that?) and every time it did there was one term which seemed tonbe ombilically attached to SASS: Ruby. This has been, for some time now, the main deterrent for switching to SASS for a large crowd of non-Ruby designers. Like myself, there are many designers out there who work extensively with CMSs like WordPress or Magento, to name but a few, or even just custom projects. And they aren’t embracing any CSS preprocessor for one very good reason: they don’t know they can.

Well, as the discussion about preprocessors has gathered a bit of momentum in recent time, I decided to take a closer look at what the fuss was all about. I’ve definitely became enamored with SCSS, especially its the more relaxed take on tabbing (something SASS was really bad at) and wanted to fit it into my regular workflow, which usually implies a lot of work with Magento and its quirky bits. Until now, I’ve been using a sandbox theme I put together, but I felt I could streamline the process even further by using SASS.

So, in a nutshell, here’s how I got SASS working for me on both OSX and Windows:

Windows

Step 1: Install Ruby

Go to http://rubyinstaller.org and download and run the latest Ruby installer .exe

Step 2: Install SASS

Once Ruby’s installed, run a prompt window. On any Windows version earlier than 8, press Start and in the Run field type CMD and hit Enter. On Windows 8, press Win+Q, type CMD and hit Enter.
In your prompt window type gem install sass and hit Enter. Some time later, SASS will be installed.

Step 3: Install Compass

In the same prompt window, type gem install compass. Some time later, Compass will be installed. Compass is what you’ll be using to process your SCSS code into browser readable CSS.

Step 4: Make a project

Make a test folder anywhere you want. Shift+Right Click in that folder and click Open Command Prompt Here. In the prompt window which just appeared type compass create project name. After a few seconds, your test folder will be populated with a bunch of ruby nonsense, a /sass folder and a /stylesheets folder. Pretty self explanatory, really.

Step 5: Get ready to rumble

In the same prompt window, type compass watch and lo and behold, Compass will let you know that it’s watching your every move, ready to compile any changes to the SCSS files in the the /sass folder of your test project.

As a side note, what I like to do is mount an FTP server to disk and create a project right up on the server, thenthe compiled CSS to my actual project. This way, whenever I make any changes to the SCSS file, Compass will automatically compile the CSS file on the server and all I have to do is hit Refresh in my browser. Pretty sweet deal, if you ask me.

OSX

Step 1: Install Ruby

You don’t need to install anything. OSX comes with Ruby preinstalled. Woohoo!

Step 2: Install SASS

Open a Terminal window and type sudo gem install sass. As Ruby is part of the OSX core, you need to provide your admin password, that’s what the “sudo” is for.

Step 3: Install Compass

Same as before, type sudo gem install compass. Bla, bla, time passes, Compass is installed.

Step 4: Make a project

Macs don’t have that whole Shift+Right Click to open a prompt window thing, but fortunately, there’s this little app that opens up a Terminal window based on the front most Finder window. And it’s free! As with Windows, type compass create projectname to start up a new project.

Step 5: Get ready to rumble

In the same terminal window, type compass watch and Compass will let you know that it’s ready to compile any changes to the SCSS files in the the /sass folder of your test project.

OSX is a little bitch about mounted FTP servers in that it can do it natively, but it’s read-only, which is a real bummer. Fortunately, there are alternatives, like Transmit, which I recommend mostly because it’ll work on Mountain Lion as well as lesser felines.

There you have it, kids, the designer friendly way of getting up and running with SASS. And if, by chance, you’re still on the fence about preprocessors, just remember that the CSS working group has already started to add things like variables and mixins to future versions of CSS. Do yourself a favor and jump on the bandwagon while you can still call yourself an early adopter.

Cheers, all!

But, as cool as Quicksand is, it does lack in some departments. Most notably, for me, it sorts through lists based on preset filters, not based on user input. And that’s quite a shame, really. How cool would it be to sort seamlessly through a list of items by just typing in an input. So, I set out to do exactly that.

For a live demo, check out the blog listing here.

Do note that this is not a Quicksand patch script. My script has no other dependencies other than jQuery itself. Mostly, this is so because I can’t make heads or tails of Quicksand’s inner workings, and when that happens, I, usually, just do things my own way. May not be the best way, but it’s the best I can do with my limited knowledge of JavaScript.

Let’s get started on this bad boy.

Some basic HTML

We’ll be using the data-* attribute to hold all the meta information about each item. We’ll be using this information, which can be a fair bit more verbose than what other attributes can hold, to sort through the list.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<!-- An input wherein you can type your filter -->
<input id="type-me" type="text" />

<!-- A list of items to sort out -->
<!-- I used a bunch of cars. You can use whatever you want. -->
<ul>
<ul><!-- Three roadsters -->
    <li data-sort="roadster Wiesmann Roadster MF4"><img src="img/mf4.jpg" alt="Wiesmann Roadster MF4" /></li>
    <li data-sort="roadster Mercedes SLK"><img src="img/slk.jpg" alt="Mercedes SLK" /></li>
    <li data-sort="roadster Mazda MX5"><img src="img/mx5.jpg" alt="Mazda MX5" /></li>
</ul>
</ul>
<!-- Three sports cars -->
<ul>
<ul>
    <li data-sort="sports car Lamborghini Aventador"><img src="img/aventador.jpg" alt="Lamborghini Aventador" /></li>
    <li data-sort="sports car Aston Martin DB9"><img src="img/db9.jpg" alt="Aston Martin DB9" /></li>
    <li data-sort="sports car electric BMW i8"><img src="img/i8.jpg" alt="BMW i8" /></li>
</ul>
</ul>
<!-- Three sedans -->
<ul>
<ul>
    <li data-sort="sedan car Mazda 3"><img src="img/mazda3.jpg" alt="Mazda 3" /></li>
    <li data-sort="sedan car Volkswagen Passat"><img src="img/passat.jpg" alt="Volkswagen Passat" /></li>
    <li data-sort="sedan car Mercedes C Klasse"><img src="img/c-klasse.jpg" alt="Mercedes C Klasse" /></li>
</ul>
</ul>
<!-- And three SUVs -->
<ul id="filter-me">
    <li data-sort="suv BMW Hybrid X6"><img src="img/x6.jpg" alt="BMW Hybrid X6" /></li>
    <li data-sort="suv Honda CRV"><img src="img/crv.jpg" alt="Honda CRV" /></li>
    <li data-sort="suv Land Rover Range Rover Evoque"><img src="img/evoque.jpg" alt="Land Rover Range Rover Evoque" /></li>
</ul>

Some not so special CSS

You can use whatever CSS you want as there are no actual CSS dependencies with this script, so you can style whatever pleases your retinas. Seriously, whatever floats your boat. Get creative!

The JS to make it all work

Read the comments in the script to get an idea of how I made it work. Or reverse engineer the script in my blog listing page, if that’s more up your alley.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// Make sure everything's all nice and loaded before running the script
$(document).ready(function() {

// After each new character has been typed...
$('#type-me').keyup(function(){

// Pass whatever's in the input to a variable...
var sortQuery = $(this).val();

// Iterate through all the list items
$('#filter-me li').each(function(){

// Get each list item's data-* attribute value
var dataSortValue = $(this).attr('data-sort');

// Create a new regular expression from the user input data
reg = new RegExp('\('+sortQuery+'\)' , 'gi');

// Match the user input to the data-* value
if (dataSortValue.match(reg)) {
$(this).fadeIn(300); // If it matches, keep it.
}
else{
$(this).fadeOut(300); // If it doesn't match, bin it.
}

});
});
});

I liked this so much, I used it on the Blog Page of this website. Feel free to sort through posts by just typing in the input at the top. Quick tip: the data-* attribute in the Blog Page holds the title and excerpt of each post, which should be enough for basic sorting.

Cheers, all!

Demo

Demo first, code comes after that. Don’t forget to navigate through the examples.

Let’s get down to it then. The HTML is quite ordinary and I’ll only be showcasing the important bits:

1
2
3

<!-- The regular embed code that Google Maps spews out, sans the line break and small tag; also, added "gmap" id as hook -->
<iframe id="gmap" src="https://maps.google.com/maps?f=q&amp;source=s_q&amp;hl=en&amp;geocode=&amp;q=Cluj-Napoca,+Cluj,+Romania&amp;aq=0&amp;oq=cluj&amp;sll=37.0625,-95.677068&amp;sspn=60.158465,135.263672&amp;ie=UTF8&amp;hq=&amp;hnear=Cluj-Napoca,+Cluj+County,+Romania&amp;ll=46.777248,23.59989&amp;spn=0.206687,0.528374&amp;t=m&amp;z=12&amp;output=embed" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="425" height="350"></iframe>
<div id="container"><!-- Website stuff goes in here --></div>

The CSS, however is where most of the magic happens:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

body,
html{
height: 100%;
width: 100%; } /* If you don't do this, gremlins will eat your nose. */

#gmap{
height: 100%;
left: 0;
position: fixed !important; /* Acts in pretty much the same way as background-attachment: fixed for an image background. Has to be !important only if you're using the Google Maps API. */
top: 0;
width: 100%;
z-index: 1; } /* Has to be at least one increment smaller in value than the container's z-index */

#container{
background: rgba(0, 0, 0, 0.8);
border-radius: 20px;
border: 3px solid #fff;
box-shadow: 0 10px 20px rgba(0, 0, 0, 0.3);
margin: 0 auto;
overflow: visible !important; /* Has to be !important only if you're using an on/off switch */
padding: 40px;
position: relative;
top: 100px;
width: 800px;
z-index: 2; } /* Has to be at least one increment larger in value than the Google Maps iframe z-index */

And that’s about it. The demo pages show off two extra examples, one in which I used the Goole Maps API instead of the regular embed code and another one in which I added a small jQuery control to turn off the container which would allow users to take full advantage of the screen real estate to interact with the map.

A few caveats

The whole technique relies on setting the body and html elements to 100% width and height and a bit of z-index trickery.

If you’re using the Google Maps API, you need to call !important on your position:fixed because the good people at Google decided that if the map comes via their API, then it should have position: relative. I still can’t figure why they did that.

If you’re using an on/off switch, like I did in the third demo, the container will need to have an overflow: visible !important to avoid any clipping.

So…

This isn’t a revolutionary technique or anything groundbreaking, but it is a creative use of Google Maps and a fairly good way of getting a handle on what CSS positions do and how they do it.

Cheers, all!

Update

Isac Lagerblad caught an accessibility bug with one of the Google Maps demos, wherein the maps iframe should be loaded at the end of the document in order to prevent screenreaders from having to go through all the Google Maps tiles before getting to the actual content. Demo has now been updated, thanks Isac!

Fortunately, here’s a pretty nifty idea about ::selections I sort of just stumbled upon: styling them differently throughout the website. And the code for that just couldn’t be simpler:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

/* General style */
::selection{
    background: #000;
    color: #fff; }

    /* Area specific style */
    #id ::selection{
        background: #a20;
        color: #ef0; }

    /* Another area specific style */
    .class ::selection{
        background: #b1f;
        color: #fff; }

*Vendor prefixes needed, of course

Pretty cool, huh? Just don’t get too carried away with this, lest you waste countless hours just tweaking ::selections like some sort of weird OCD crazed loony. No disrespect intended to people actually suffering from OCD.

Cheers, all!

As I was coding the new Sickdesigner.com (you did notice, didn’t you?) I, eventually, came upon the comments section. Specifically the comments itself and one thing I noticed WordPress does is it keeps line breaks as users hit Enter in their comments. Not a problem.

But, of course there’s a but, most users don’t double Enter for a new paragraph, although if they would, WordPress is so kind as to separate <p> from <p>. So, now I have a problem: user comments look like the blurb of a 12 year old One Direction fan to another 12 year old Justin Bieber fan instead of the elegant, intelectual replies of my peers.

The jist

Cmd+C / Cmd+V the very code I used to get user comments properly spaced out and easy to read:

1
2
3
4
5
6

#comments li p br{ 
    clear: both;
    content: '';
    display: block;
    margin: 0 0 10px 0;
    width: 100%; }

Before you start flaming about what the heck is with that extra code in there, here are some of the issues which lead to this kind of an approach:

• without a content property, you can do pretty much fuck all with your line breaks; nothing works
• if you don’t clear it, in most cases, it will just behave like an inline-block
• which is also why it needs to be a block level element
• height and paddings don’t work; used margin instead, courtesy of Zoran Jambor

So, a bit of creative thinking and I didn’t have to go about tinkering with WordPress’ comments engine, of which’s logic I know nothing about, mostly because I couldn’t write proper PHP if my life depended on it.

Cheers, all!

Update

The good Zoran Jambor discovered a bug wherein Firefox was disregarding the height property, but margins were working. My initial tests were flawed in seeing margins not working in Chrome for reasons yet unknown. Post updated to reflect new information. Thanks, Zoran!

The all mighty columns

The solution is so simple that it gave me a brain freeze: CSS columns. Granted, their purpose is to display text in columns like a newspaper, but their display mode is exactly what’s needed to recreate the Masonry effect. But let’s get down to the code. What do you need, you say?

The basic HTML

1
2
3
4
5
6

<div>
<a href="#">Whatever stuff you want to put in here.</a>
<a href="#">Whatever stuff you want to put in here.</a>
<a href="#">Whatever stuff you want to put in here.</a>
...and so on and so forth ad nauseum.
</div>

And the CSS magic

1
2
3
4
5
6
7
8
9
10
11
12
13

div{
    -moz-column-count: 3;
    -moz-column-gap: 10px;
    -webkit-column-count: 3;
    -webkit-column-gap: 10px;
    column-count: 3;
    column-gap: 10px;
    width: 480px; }

    div a{
        display: inline-block; /* Display inline-block, and absolutely NO FLOATS! */
        margin-bottom: 20px;
        width: 100%; }

An interesting fact: the width of the elements within the columned container is not relative to the width of the parent, but the width of the column. In the case of the example above width: 100% actually translates to 150px, not 480px (the width of the parent).

Fallbacks and browser compatibility

Of course, our friends at Microsoft have taken good care to not provide support for CSS columns. Not even in IE9! In this case, I recommend slapping in David’s awesome plugin like so:

1
2
3

<!--[if lte IE 9]>
<script type="text/javascript" src="js/jquery.masonry.min.js"></script>
<![endif]-->

In Microsoft’s defense, for what it’s worth, my technique does work (well, even!) in the IE10 Platform Preview. Hopefully they’ll leave support for columns in the final version, which could be released as early as next year which will see a final release when I’ll be able to lick the back of my own head.

I’m guessing there’s no point in mentioning that this works (brilliantly) in Gecko and Webkit browsers (Mozilla, Chrome, Safari). Opera does weird things that I don’t quite understand yet, but does an acceptable job of rendering columns (it just has trouble with the gaps and all).

This is usually where you’d find a link to a demo page. This time, however, I direct you to the homepage of this site. Yes, I used it live. I have that much confidence in this. Enjoy, kids! Since the new design doesn’t use this technique, I put together a demo page here:
Demo

Cheers, all!