Yesterday, we had a discussion at work about rems, ems and percentages. I’ve used ems for media queries for years. I’ve used rems for font sizing for a couple of years. I felt like I had a pretty good handle on how it all works.

Most of you probably understand the difference, but let’s do a quick recap to refresh. When sizing using rem units, the sizing is based on the HTML element’s font size. When sizing using em units, the sizing is based on the parent element’s font size.

Here’s an em unit example: I’ve created a module named .foo and it contains several other elements. I want the heading inside to be 32px, so I set it to font-size: 2em. If my body font size is equal to 16px, and as long as I’ve set no font-size on the the .foo module or any ancestor of it, it will be rendered at 32px. However, if the .foo module or an ancestor has the font set to “font-size: 14px;” or “font-size: .875em;”, that new size (from the ancestor element) will now cascade to the heading inside as the base to compute by, and our 2em heading will be rendered at 28px.

This is the reason many of us moved to rem units. It’s more reliable to set the font-size on the html element and, if left at the 16px default, you can be confident that setting a heading size to 2rem will always give you a heading rendered at 32px. If you’re the only person writing the code in the site, you can get that same effect with em units by having a rule set in stone that you never, ever, ever set a font size on anything other than type (p, hx, lists, etc). But that’s in a perfect world where you control all the code and never pass it off to another developer. If you do work with other people, things can become messy and unreliable.

This brings me to the reason for this post — using em units for your media queries. Much has been written about it over the years, but the short story is — for reasons related to content and line-lengths — I use em units for my media queries so that the breakpoints adapt to changing font sizes. If the user changes their default, or zooms the browser, all my breakpoints react to this new font-size base.

So what’s the big deal with the break points?

Based on yesterday’s conversation, I was doing an experiment. Since all my font-size, padding, margin, etc, is set in rem units, changing the size of the HTML element should scale the whole design either up or down. And it does. However, I expected it to also change the em-based breakpoints. It does not. I experimented with changing the size of the HTML element or the body element (sometimes even to straight up pixel values) and the breakpoints remained sized based on 16px. #headscratch (Here’s my Codepen to play with if you like: http://codepen.io/stefsullrew/pen/azRzOo)

After testing this several different ways, I did what one does — I reached out to the Twittersphere — the fount of all obscure knowledge. Within two minutes of posting, @susanjrobertson set me in the right direction: https://twitter.com/susanjrobertson/status/575378991017631744 I tested her theory, and by cracky, she was dead on! Fact is, the em base in media queries comes from the user’s setting (which is the 16px browser default if not changed by the user). The author has no control over this at all! Giving this some thought, it makes total sense. If my user has changed the default size of their browser to 32px because they have low vision, their line lengths will be shorter unless my media query breakpoints are now also using a 32px base and change accordingly. The same applies to zooming in the browser, I want my media query breakpoints to change based on their zooming. (Lyza Danger, who likely wrote the article I read years ago that got me started with using em-based media queries has updated this week to state that browsers have fixed zooming.)

The moral of the story is — your media queries, sized with em units, are going to be based on 16px per em unit — unless the browser’s font size has been changed by the user. You can not override the user’s wishes. This means that the idea of scaling a whole design by changing the HTML element’s default size (maybe up to 18px, or down to 14px) will not change your media queries base size. It absolutely will scale your whole design to use any base size you desire (when all your values are rem based) — but your media queries will still be based on 16px. So in my opinion, it seems best to keep the HTML element at 100% (16px) so that it matches the em units of your media queries (or the overrides of your user).

12 Mar: Edited for clarity & to update with Lyza’s update!

While implementing the trial automation flows at Contatta, one of my goals was to create an exit survey email for people who did the 30-day trial but had decided not to move to the paid plan. I wanted to send a simple, multiple choice question with the final option being “other,” so trial users could freeform an answer if it wasn’t offered. I don’t know about you, but I rarely want to click a “Take our poll” button in an email. But if it’s super easy, I’m willing to give feedback. So I wanted to make it as simple as possible to give feedback — so I could get the data I needed.

I know I can’t be the first person who’s wanted to do this. But I also know the overwhelming limitations of HTML email. I guess you could say, as I started my research, I was a hopeful skeptic. We had both a Survey Monkey and MailChimp subscription, so I started looking at the integration between them. But whether you create the integration from MailChimp to SurveyMonkey or from SurveyMonkey to MailChimp, you end up with the same thing. A button in an HTML email that basically says “Take the Survey” and then moves the user to the survey page. Nada.

After digging around on the internet a bit, I was beginning to become less hopeful. I’m a huge proponent of “needs to work everywhere.” So a Google form integration was out of the question.

Somewhere in my research, I found an idea that showed promise. (Sadly, I haven’t been able to come up with the article in subsequent searches to give the author credit.) The article talked about “faking the poll” by putting images of radio buttons along with the questions in your email. The link placed on the image of the question is a custom URL with a different variable appended to auto-submit the answer to the form (access to this required me to upgrade our account level). This works great for a yes/no question or even for a “rate this” question. But mine was a little more complex. I needed anyone selecting the answer “other” to be able to submit further information.

I started testing the theory. Maybe I could put a further question on the thank you page. The answer to that turned out to be, nope. But I found, if I upgraded my subscription, I could use a custom redirect on my thank you page. I decided to create a second form that appeared to be a thank you page, with an area that could be used to leave further info. Though in the end, I would have two forms, it would still meet our needs giving the user the easiest method to interact with us.

I rolled up my sleeves and got to work. I upgraded our account to Gold level ($300 per year). I immediately got the redirect working. That’s when I discovered that though it appeared upgrading to Gold would get me both the redirect and custom variables, in reality it only got me the redirect. I was going to have to upgrade to Platinum level ($780 per year) for that. Being a startup with a purposely lean budget, that wasn’t happening. (I found through a later Support conversation that there was a bug on their website that didn’t make clear what level you needed to upgrade to if you are a paying customer. I’m sure they’ll fix that soon.)

Round Two

Time to see if I can get the custom variables and the thank you page redirect I needed — at a more reasonable cost. The other survey integration I’d seen while perusing MailChimp integrations was SurveyGizmo. I was unfamiliar with SurveyGizmo, but I figured they’d probably be similar to SurveyMonkey — perhaps with even less features. I signed up for the 7-day trial and started poking around.

I very quickly got a redirect of the thank you page working (their knowledge base section is quite good). I had to get a little help from their Support folks (also really awesome) to get my custom variable working, but I was shocked at how quickly I was able to implement the process I had designed.

Then I had a horrible thought. Now that everything was working and I was ready to pay, what if during trial they enable ALL THE POSSIBLE THINGS and it’s actually more expensive than Survey Monkey? I called them. (I hate using the phone, so this was clearly a desperate situation.) They confirmed that everything I had accomplished was at the lowest Solo level ($162 per year). I have to admit, I was flabbergasted—as well as super excited. Credit card engaged — Subscription unlocked!

If you’d like to embed a survey in an HTML email, read on. I’ll list step by step what I did to make this work.

Add an actionable survey question into an HTML email with SurveGizmo and MailChimp

1) At SurveyGizmo, create a form with your one question (multiple choice). Tip: Be aware that if you choose radio buttons, they will only be allowed one answer. If you choose checkboxes, they can choose multiple answers. (Though they have to return to their email to choose a second option, my experience has shown that some users will do that.) The form doesn’t need any styling since it will never be seen by the user.

Note: If you already have a SurveyMonkey Platinum account, you can create the same functionality — I’m just not listing the steps here.

2) Create a second form with a question that allows an “essay/long answer” so they can leave you further feedback. I also added a way for someone to request to be contacted and leave their name and contact information. Style this form as if it’s a thank you page for the first form. Click on the “Share” tab at the top and copy the link for this form. You’ll need it shortly. (You may want to customize the name of the first form since people may see it in their browser when they click your links.)

3) Let’s create the URL variables for the first multiple choice form—the one that’s included in the email. Click edit and open your question. To the right of the “Answer Options,” click Advanced options and choose Custom.

The reporting values are what you will use to customize the URL in your email. I played around with this a bit. What I landed on was simply giving them the values of one, two, three, etc. — due to the fact that my team was changing what those questions were and the reports area of SurveyGizmo will show you the actual answers. (This is their help page.)

4) The second half of creating the URL variable is the merge value. While editing the question, click on the layout option. Scroll down to the Advanced area and add whatever you’d like to use for the URL variable. (I used the term answer.) This is the format: [url("yourtermhere")]

5) Move down to the bottom half of the page of your first form. This is where you’ll redirect the thank you page to the URL you saved for your second form. Create a new Action. Redirect it to the second form you’ve created with a 0 second redirect:
(SurveyGizmo’s instructions are here.)

6) Now we’re ready to add the link to our HTML email in MailChimp. First, you’ll need to create an image that appears to be a radio button. I did it in a super highly advanced way — I went to a real form on my website and did a little screenshot.

I’m a huge accessibility advocate. Also, I know that some people open email with images turned off by default. For that reason, I chose not to include the words of the question into the image of the radio button. I want them to be real words. The radio button and the words/option next to it should both be linked to the same place. I put inline CSS onto the linked words to remove the underline from the link on the question — that way, it appears that the radio button and option next to it are associated, just like a regular form. Put a the radio button and linked words into a table in your email so that no matter what device your user is on, they’ll remain together.

7) Go to your first multiple choice form and copy the URL you’ve chosen to use. Then, add the merge value along with the reporting value. So for example, since I chose to use “answer” as my merge value and one, two, three, etc for my reporting values, my URL would look something like this:

http://www.surveygizmo.com/data/nameofform?answer=one http://www.surveygizmo.com/data/nameofform?answer=three

You get the picture. Essentially, you’re letting the image of the radio button and the words of the linked option automatically submit their answer to your first form — then quickly roll to your second form — the “fake” thank you page. If they choose to give you further information, you’ll get that in the second form report.

There are a couple other little tricks I’ll share in a follow up post. You can pass more data to SurveyGizmo from MailChimp (like first name, email, etc) and even customize your thank you page/form with that data. But this has gotten long…

Cheers! And please share your tricks in the comments.

I’ve been quiet lately. Startup life is busy… and exhausting. Blogging for me has pretty much gone the way of the Dodo. I’m planning to change that.

Since technology is increasingly involved in a modern company’s marketing department, it’s become quite common for those of us who are developers to find ourselves deeply involved with our marketing team. Almost two years ago, I took on the role of “Director, Web Strategy and Marketing Technologies” at Contatta. As a small startup, it means I personally handle a whole host of technology decisions and implementations — and I do it within a limited budget. Sometimes that requires me to get creative instead of going for a big all-in-one solution.

Though early in my career (building small business web sites) I regularly provided clients with organic SEO and analytics, the techniques I knew have changed. We now use schema and OG markup. Google Analytics has been upgraded to Universal analytics. There are additional analytics tools available like Mixpanel and Kissmetrics. There are also a whole host of things that I didn’t regularly offer back then — like A/B testing, heat mapping, multiple landing pages, and very few clients used email marketing. Through a lot of trial, and some error too, I’ve been creating a system that gives us the ability to test, analyze and iterate quickly.

I still do all the front-end development for Contatta’s website and blog — and I’ll continue to blog about web techniques and technology. But I’ll also start sharing posts with marketing technology-related information. Tips and techniques, and creative ways I’ve found to make things work on a budget. (I’m probably posting these as much for me as for you. More than once, I’ve done a search for how to do something and found the answer in one of my own, older blog posts. It’s one of the best reasons to blog—I can’t remember everything—even when I once figured it out.)

I’m enjoying this journey. I hope you’ll share things you’ve learned with me as well. Cheers.

I ran into a very frustrating bug while using icon fonts on our site at Contatta. A bug I filed last April, and nurtured through the process of getting fixed, didn’t make the Mozilla release notes (though it was included in Firefox 28). Because I feel it’s a very useful solution, I wanted to bring some attention to it.

Font Smoothing for [most] Everyone

In a nutshell, if you’re using antialiasing for icon fonts and headings using -webkit-font-smoothing, you’ll want to be aware of -moz-osx-font-smoothing. I won’t take the time to go into the finer details of sub-pixel or grayscale antialiasing. If you’re interested, you can read this article about type rendering on different operating systems for more info. And though I initially filed the bug on Firefox, the issue is actually OSX. Here’s a summary from Jonathan Kew (a Mozilla engineer):

The “problem” in Firefox is simply how OS X renders the font when “LCD font smoothing” is enabled (which I think is the default). AIUI, it’s widely known among the font-design community that OS X tends to fatten glyphs somewhat compared to other rasterizers. For the usual case of black-on-white text, this works OK (though some people like it more than others); however, for white-on-black, the effect can be much too heavy-handed.

Aral Balkan posted an excellent example of light icon fonts on a dark background — one with -webkit-font-smoothing, one on Firefox. The web has been full of people trying to come up with creative ideas for making their fonts render consistently — opacity tricks, text-shadow tricks, etc. But those only work in some situations. In the end, many people have simply thrown their hands up in frustration—and changed to a different heading font/color scheme or moved away from icon fonts and back to sprites.

A while back, the Webkit team gave us a way to counteract the issue — -webkit-font-smoothing. It should be used responsibly and shouldn’t be used on everything. Certain fonts become too thin and less legible when it’s applied. But when needed, it’s a fontsaver (yeah, yeah, I know). This non-standard property got a lot of attention and caused many of us to accuse Firefox of being fat. I was one of them.

Jump forward to the bug I filed. After much passionate discussion, the exceptional Mozilla engineer David Baron agreed to grant us a property that provides a similar fix — -moz-osx-font-smoothing. While it has the similar effect of slimming fonts, instead of using the “antialiased” value Webkit uses, FFOX has chosen to use “grayscale”. (You can read the bug for the reasons why and the methods used.) It also appears from viewing in the FFOX Inspector that you can use the inherit | unset | auto values as well. (Though I haven’t experimented with those.) So far, anywhere I need the -webkit-font-smoothing:antialiased I now use -moz-osx-font-smoothing:grayscale with great results.

If you use Sass, you’re in luck. Maximilliano Firtman has created a [Sass mixin to turn the font-smoothing property on and off] (http://maximilianhoffmann.com/posts/better-font-rendering-on-osx).

So spread the news — FFOX is thin again!

A Sidenote on Bug Filing

Maybe it’s all the beta testing I’ve done over the years, but I come from the “don’t accept sub-optimal behavior” camp. If something in a browser doesn’t behave as expected, I believe it’s more productive for the Web and my end result to file a bug and help get it fixed.

For those of you that haven’t yet filed a bug or made a feature request for a browser, I’d like to offer a few suggestions I’ve found helpful:

1. Be very clear in your initial report. Use the most accurate terms you can to illustrate what causes the bug (does it have a trigger, can it be affected by other interactions, etc). Create one or two simple demos that illustrate the bug so the engineers can test it more easily.
2. Remember that you’re dealing with people—engineers have feelings (I swear, they do!). Yelling at them, in general, gets you no where fast. Clarity and politeness are the order of the day.
3. Engineers are dealing with massive amounts of work and they have to prioritize. If they feel your bug is a small edge case, it will receive a lower priority. If your bug is one that affects a myriad of people, but the engineers don’t understand that, rally the troops to come vote for it and comment on it. Have them show more examples. It really makes a difference in helping them prioritize.
4. Stay with your bug. Keep an eye on it. Provide more examples where needed. This is your baby, it’s your responsibility to see it delivered to the masses. It’s easy for it to accidentally get stuck in limbo where one engineer has worked on it and is waiting for another engineer to weigh in. But he’s working on other things and doesn’t know the first engineer is waiting, and — well, you get the picture. The occasional little ping or tickle doesn’t hurt.
5. Once the bug is fixed, you may be the one that has to let people know. Don’t count on release notes and the browser’s dev center. It can be missed in the mass of things that occur in a release.

BTW, I have this other outline bug I’d love to see fixed. It’s been around for over three years. It could sure use your votes.

In 1999, when I started my journey through the interwebs, I had no real idea where it would take me. I barely knew what was possible. I only knew that my brain loved puzzle-type thinking, detective work, research and figuring things out. And I suspected code would access the parts of my mind that love a work out—and so I pursued it. Vehemently. For the first 12 months, I did tutorials for 15 hours a day and got any friend that might possibly need a website to let me create theirs. (And for the very first customers, may I apologize for the frame and table-based layouts.)

And as I learned, I had questions—lots of them—and I inflicted every one of them on the unsuspecting, and gracious souls on a couple of web design lists. (The only stupid question is the one you don’t ask!) As my skills grew, I began answering the questions of people who knew less than I and continued to pick the brains of those who knew more. Within a couple of years, I had accidentally created a business via business owners who had planned to build their own web site only to find it wasn’t as easy as they expected. Due to the number of questions I answered on the list, they wrote me offlist for a quote to, “Please, just do it for me”.

It didn’t take me long to figure out that there’s a whole lot to this web design business. And some portions I enjoyed more than the others. In looking at where I thought the puck was going, I ventured into the world of CSS—that marriage of code and design—and I loved it. I gleaned great enjoyment from changing a designer’s beautiful comp into light-weight, web-ready markup (I’m too much of a tweak-a-holic to design). And so I moved into specialization in the portion of the industry we now call front-end development.

My desire to give back led me to accept requests to write articles and books (even though I really dislike writing). Writing led to speaking at industry events. Speaking led to doing training in corporations. Filing zillions of bugs to make Dreamweaver move into the realm of Web Standards led to my work with the Web Standards Project (WaSP) as well as working as a contractor for Adobe to create the CSS Layouts contained in Dreamweaver. And writing a book teaching both CSS and Dreamweaver while using those layouts as a base for each project led to discovering the other half of my brain—my co-author Greg Rewis. Now my husband, soul mate, and co-captain on Geeks4Sail. Every choice I’ve made to give—even when there wasn’t a guaranteed return—has come back from the universe in amazing ways I hadn’t envisioned. It’s been a great ride.

And even though I’ve loved every minute of sharing, learning and teaching others, and of working with awesome agencies, companies and start-ups—I still leave them with the code and walk away to start the next contract. I rarely get to see a product through to fruition or have any further affect on its development. I can’t continually help the code evolve as the web changes. I just hand it off and move to the “next thing”.

But all that’s gonna change…

I was recently approached by a start-up (oddly enough, right here in the Phoenix area). We initially discussed their need for a top notch front-end developer to build their web app—probably a six month contract. We discussed what they were building for about an hour—and I got this feeling in my gut. You know the one that hits you in the pit of your stomach and says, “I really, really feel like this is a thing“? That one. But having been taught by my parents never to trust my gut—always use your head—I did the obedient thing and went to the web for some Google research. As you do… That research made the feeling in my gut even stronger. And a series of meetings with the CEO, CTO and team over the past couple weeks has evolved into my decision to make a full-time commitment—forsaking all others. This is a big step for me after 12 years of independence. I should feel a twinge of sorrow. But I don’t! I’m as excited as I’ve been about anything in years.

I am now officially the VP of Interface Architecture for Contatta (Italian for “be in contact with”), helping to create a new era in Contact Management. And while a product related to CRM may not sound like a sexy start up to you, Pat Sullivan, the co-creator of ACT!, and founder of SalesLogix is a founder of this company. Along with Sunil Padiyar who was a founding member of SalesLogix as well. When the man that helped create an industry 25 years ago says he thinks it could be in a better place—and in fact has ideas about changing a currently stagnant industry—I listened. And in listening, I was impressed enough to get on board.

Not only am I excited about the product, I’m super excited about the team they’ve already assembled. I’m going to have the opportunity to work with some amazingly top-notch devs and we’ve already been exchanging ideas. I’m literally chomping at the bit to get started!

Lest any clients (or prospective clients) are concerned, I’ve got great back-up with good friends and co-contractors like Emily Lewis (of “Microformats Made Simple” and “HTML5 Cookbook” fame), Leslie Flinger (front-end developer and former Director of Marketing at EllisLab) and others. You’ll be in great hands!

A recommendation on Contatta’s Facebook wall says – “With Pat behind it … here’s hoping for a real game changer for the industry!” I agree with that and I’ll take it a step further and say, “With the team behind Pat, we’re gonna work to make awesomeness—and maybe a ding in the Universe.”

EDIT 3/7: Some have emailed to ask whether I’ll still be speaking. Yes, on a more limited basis—but not once a month as I have been. Feel free to send requests.

This morning I awakened with a question in my twitter stream from @deebeefunky. He was frustrated by the fact that when he sets a blur on box-shadow, it shows on two sides of the box. He wants it to show on only one side. Of course, that got me thinking. I did come up with one solution—it won’t work in every situation—but it may work in yours.

The spread value

There’s a little talked about value in the box-shadow property called “spread”. That value, when used, comes after the blur value and moves the shadow away from the box equally all the way around. It doesn’t add a blur, it simply spreads out in all directions. You’ll get different effects based on whether the blur value is a greater than the spread value or whether the spread is greater than the blur. The color defined will be solid right next to the box, and then blur for the rest (based on the difference between the two values). Before it gets too confusing, let’s have a look at the property:

box-shadow: (inset) x-value y-value blur spread color;

div {
-webkit-box-shadow: 0 0 6px 4px black;
   -moz-box-shadow: 0 0 6px 4px black;
        box-shadow: 0 0 6px 4px black;
}

Blur larger than spread

If the spread value has a higher value, you get a different effect with the full spread and only a little blur.

div {
-webkit-box-shadow: 0 0 4px 6px black;
   -moz-box-shadow: 0 0 4px 6px black;
        box-shadow: 0 0 4px 6px black;
}

Spread value greater than blur

Though the differences above are subtle, you can actually create some really interesting effects with this value. If you don’t move the box-shadow on the x or y axis and provide no blur value at all, you can create one, or more, multiple borders for your element.

Create the look of multiple borders

div {
border: 3px solid orange;
-webkit-box-shadow: 0 0 0 3px black, 0 0 0 6px red;
   -moz-box-shadow: 0 0 0 3px black, 0 0 0 6px red;
         box-shadow: 0 0 0 3px black, 0 0 0 6px red;
}

Spread radius with no blur

Notice it appears there are three borders on this element. A single (orange) border was added, then a black border (created with the 3px of spread) and then a red border (the 3 px border is created by 6px of spread since you must allow for the first box-shadow). It’s unlikely you’d actually need more borders than this, but you can create an unlimited number this way. Remember that when using multiple box-shadows, the first one is applied closest to the element.

How does this apply to @deebeefunky’s question?

I’m glad you asked! Sometimes I get off track (you know, that simple little blog post you were gonna write…). The issue with box-shadow is, even if you only move the shadow on the x or y axis, you’ll see a hint of the shadow on at least two sides of your element.

div {
-webkit-box-shadow: 1px 0 2px black;
   -moz-box-shadow: 1px 0 2px black;
        box-shadow: 1px 0 2px black;
}

2px blur moved 1px on the x-axis

I came up with an idea that works as long as A) the element is a solid color and B) you’re not also using border on the element. It involves applying two box-shadows, one with spread in the same color as the box itself and another without. Like so:

div {
background: white;
-webkit-box-shadow: 0 0 0 4px white, 0 6px 4px black;
   -moz-box-shadow: 0 0 0 4px white, 0 6px 4px black;
        box-shadow: 0 0 0 4px white, 0 6px 4px black;
}

Use two box-shadows for a single side effect

Why does this work?

In a nutshell, what you’re doing is creating the first box-shadow (0 0 0 4px white) which doesn’t move on the X or Y axis, doesn’t provide any blur, and has the 4px of spread set in the same color as the background of the element. This basically renders it invisible but makes the element 4px wider than it was (box-shadow does NOT add to the box model, so you’re element will appear 4px closer to the elements around it as well). Remember the order I mentioned before? The first box-shadow is placed on top—or closest to the element? That’s what helps us here. The second box-shadow (0 6px 4px black) is moving 6px on the Y-axis, has 4px of blur, no spread and is black. We’ve moved this vertically—though you could use the same technique on the X-axis.

Where is the real border?

Just to illustrate why you can’t use a border with this technique, here’s a look at the addition of a red border to our previous example.

Red border shown on actual outside of box

The thing to remember when using this technique is A) you can only move on one axis— X or Y and B) your blur value cannot exceed the spread value given in the first box-shadow. If it does, you’ll start to see it peek out on the sides (an effect we were avoiding in the first place). You can, however, move as much or as little on either the X or Y axis as your effect requires. And as always, using RGBA or HSLA color values will give you a more realistic shadow if that’s what you’re after.

Update: Method Two

If you have a patterned background on the element or need to use a border, Joseph Silber had another idea in the comments below. Use a negative spread radius. Nice thinking, Joseph! Playing with this method, I came up with the following:

div {
	-webkit-box-shadow: 0 8px 6px -6px black;
	   -moz-box-shadow: 0 8px 6px -6px black;
	        box-shadow: 0 8px 6px -6px black;
}

Negative spread radius with equal blur value

The issue to be aware of with this method is, the negative spread value should be equal to, or greater than, the blur value or you’ll end up with a slight blur on the other two sides of the element. Also, very little of the box-shadow will show if you don’t give the X or Y a value equal to, or greater than, the blur. Otherwise, the blur is slightly hidden behind the edge of the element since the spread value is negative.

With the negative spread value, a border can be added

Notice the element isn’t “expanding” like it did using the first method (the box size is what you’d expect), but the shadow doesn’t quite go to each edge due to the negative spread value. Based on the interaction with other elements on your page, one of these two methods might just work for you!

Update Oct 2

Due to an Android bug when the box-shadow has no blur, you’ll likely want to use the second method if you want the shadow to appear on an Android device. Let’s hope they fix this one soon. (Thanks, Luís Carmona!)

Do you have a method you use to create the same effect? Share it in the comments. Happy coding!

Last night, I was getting a file ready to share with Estelle Weyl, one of my co-presenters for our CSS3 workshop at SXSW11. The page was a silly little demo that used media queries, multiple backgrounds, transitions, generated content, multi-column layout and, well, a unicorn.

I had only viewed the file in Chrome since that’s the browser I used during the demo. Since we were putting it online where people could look at the code, I decided to take a peek in other browsers. Oddly enough, Firefox seems to be hacking a hairball on the multi-column layout with generated content (I’ve tested in both FFOX 4.1 and Aurora with the same result).

The generated content (.container:before) creates the layered look of the main .container div to avoid any extra, non-semantic wrappers. The bug is not triggered when the generated content is removed (either by removing the position: relative from .container—the parent to the generated content, or by removing it altogether). And it seems to have something to do with the values in the top, right, bottom, left properties of the generated content (it’s protruding on the right and tall enough that you can’t see the rounded bottom corners). My guess is that FFOX is somehow adding actual pixels to the box model (width and height), but I’ve no clue why it would.

UPDATE 5/5/11:

Thanks to Oli Studholme who identified the padding on the .container as one of the bug’s triggers. I’ve added another demo with the padding removed and filed a bug with Mozilla. If anyone identifies another piece of the bug puzzle, please post it in the comments or on the bug report.

As you may have read, outside of gradients, you can’t change a background-image with CSS transitions. Or can you? At InControl Conference last week, Greg Rewis spoke about Transitions, Transforms and Animations. A question was asked about showing one background-image on load and transitioning to another in a subsequent pseudo-state. You can always change the background (we do it all the time in menus on :hover), but you can’t apply sexy transitions to that change. You can, however, transition a background position change. In the first demo, I’ve created a sprite that has both background states which load with one image, and then move to the other when the pseudo-state is triggered:

CSS Transition with sprite

(Thanks for your nice use of this effect at the bottom of CSS Tricks, Chris Coyier!)

In the InControl wrap up panel, someone asked a question about creating a menu that has no background image to start, but on hover, would transition to the background image. While it’s correct that you can’t do exactly that, all good CSS’ers know there’s usually a clever work around. An idea occurred to me on stage that I’ll share here. Using a sprite again, have the starting portion of it transparent (gif or png). You can create the effect of going from no background to a background image by simply changing the background-position.

Illusion of going from no background to an background-image using CSS3 transitions.

What creative uses can you think of for CSS transitions and background images?

In August, due to a twitter discussion with Molly, and of course while partying on a Saturday night, Dave Gregory and I were looking at whether the Flexible box layout module (still a working draft) is getting close to ready for prime time yet. Our hope was that it will solve some of the frustrations we have with layout—like columns that are equal heights and vertical centering. We read the spec and some good articles. It gave us hope. We started testing on our own. That’s when we realized how much is left to do here.

First, I’ll say that both webkit- and moz-based browsers did great in our simple testing of four equal-sized boxes—whose background colors fill each container. They were they equal width, and the color filled the container whether the content did or not. Good news! There is a difference in the height of the containers between -webkit and -moz which is related to their differing treatment of the bottom margin on the paragraph inside each box. I don’t know which one is right, but find it odd that when Webkit allows the margin to escape, it doesn’t push the next element away as can happen in a floated/non-floated layout. (But that’ll be another experiment.)

1. Four equal boxes
2. Equal amounts of content

The demos shown on the Mozilla site appear to work, but in real life really don’t yet work as expected.The demos work because there’s not really content in the boxes—and in that situation, the flex box does work. But check our tests to create four equal boxes with content—especially content that varies in length. Less than wonderful.

3. Varied content
4. More varied content

On vacation (when else is there time!?), I was reading Zoe Gillenwater’s excellent book, Stunning CSS3. If you want a well-written, easy to understand, beautiful book on the new CSS3 capabilities, I highly recommend this one. Anyway, the last chapter of the book is about upcoming layout possibilities—most of which covers the flexible box model. It got me thinking about my earlier testing. I started playing around with having widths on one or more of the boxes. These results didn’t really do what I expected.

If I give three of the boxes a width, with one set to box-flex:1, it will fill the remaining space. It doesn’t seem to matter how much content is in them.

5. Example of three with widths

This seems to be the most reliable way to use the flexible box layout right now—to take up remaining space.

I then, bravely, placed box-flex:1 on two of the four boxes. This, as I read the spec, should have added up the widths of the two boxes where the width property exists and then equally divide what is left over between the two flexible boxes. If I had set one box to a value of 2 and the other to 1, it should divide it into thirds, giving 2/3 to the box with a value of 2. Instead, we went back to unreliability. The boxes don’t split the space left evenly, they seem to split it based on their content. This may be the way it should work, and I may be misunderstanding the spec, but it seems very unreliable as a form of layout.

6. Two box-flex and two with widths (the widths are correct)
7. Two box-flex which are not next to each other with the same results

Finally, I gave the first and last boxes pixel widths. The middle two both had box-flex:1. They have substantially different amounts of content. The larger literally suffocates the smaller amount of content—even though they should be splitting it more evenly as I read it.

8. The second box is overflowing its boundaries even though each line is a single word—causing the page to be much taller than it should.
9. A small increase in content made it slightly wider and the page is closer to the height it should be.

I’m playing with this and don’t feel I’m the definitive expert. But I do think something is far from correct in browser implementations—or the spec needs to be much more clear. Either the boxes should be split evenly, or they should be split so that they’re the same height, but widths are based on content within (though that’s not what I think I read in the spec). Currently, the odd splitting, based on content, but not even at all, is baffling me.

Update: Based on Zoe’s comment, I did a few more tests. If widths are given to all boxes and then box-flex is added to one (or more), the dividing of space between the boxes is reliable. It seems to be when you leave the browser to use the intrinsic width as a default that unmatched content amounts gives you extremely unreliable results.

• Equally sized boxes with 1 box-flex — extra 200px left in container
• Equally sized boxes with 1 box-flex — overage of 200px
• Equally sized boxes with 2 box-flex:1 — extra 200px left in container
• Equally sized boxes with 2 box-flex — one set to 1 and the other 2

Opera hasn’t implemented flexible boxes yet (they’re reportedly waiting for a more complete spec) and though this may be included in Internet Explorer 9, as you might expect it’s certainly not in any of the earlier versions. (Update: It appears it’s not made it into the RC which is feature complete.)

Once this is implemented more fully, it’s going to be a very interesting new weapon for the arsenal. Kinda makes you wish someone working on CSS3 had realized our lack of proper layout is more important than making things move around and transform—we already have Javascript for that anyway.

I’ve had a couple people ask me to link on my blog to my four part video series on HTML5 and video. Currently, it’s a feature on the AdobeTV home page, but I reckon that will be for just a little while. After that, you can link directly to Part 1 (7:18), Part 2 (10:31), Part 3 (6:20), and Part 4 (9:41).

If you follow all the way through to Part 4, I cover some alternate methods to embed HTML5 video depending on your needs. Enjoy!