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!

Recently, I noticed that sometimes, when uploading a stylesheet using @font-face, my cute little smiley (thank you Paul Irish!) gets turned into some kind of garbledygook instead of the smile character. Last week, I decided to try an experiment. It cleared it right up.

To the top of your stylesheet, add this: @charset “UTF-8″;

Be sure you don’t have anything at all before it or you’ll get errors. Now your smileys will stay nice and cute.

I was reading a discussion on the W3C Bug tracker about native video and whether it should, or should not, provide DRM to protect video content. In the process, the point was made by John Foliot that Apple is presenting their own answers in their browsers and devices to the DRM issue (emphasis mine):

> The question of DRM within the media formats supported by browsers is a
> separate issue to be addressed in a different forum, but as I said, I'm fairly
> sure there will be strong resistance to it.

Really? I have it on first person confirmation that currently Apple is
promoting "...H.264 with the m3u8 format for HTTP streaming with optional AES
encryption..." to commercial content producers in North America. Either that
gets supported directly in the browser, or gets handed off to a third party
(QT)player... Frankly at this point I could care less if Opera, Mozilla and
Google see this as a problem or not - it's your business models, not mine.
Apple will profit by selling their iDevices that *do* support encryption, as
will Roku, Wii, X-Box and other companies who understand the real business
needs at the intersection of the multi-billion dollar industry that is "the
Internet" (delivering content over the global network) with the multi-billion
dollar industry that is the Entertainment Industry. 

My best guess, without having all the information personally available, is that the statement above (placed in bold type) means that if you’re using a Mac, DRM is supported directly in the browser because QuickTime is built in. If you’re using a PC, just as happens currently with native video, you must install QuickTime to view it.

Isn’t a plugin just a plugin?

QuickTime is a plugin. So the question I keep asking is this one — Apple refuses to allow the Flash plugin on their devices (and until very recently also refused Adobe the hooks they needed into the OS to speed Flash up like it has on a PC). Much of the web that needs video is already standardized on Flash. They seem to be attempting to move people to their plugin (which they can either build into their own products or ask people to download—as they do Flash now).

Was native multimedia added to HTML5 to make plugins extinct?

The W3C says the co-existence of plugins and native multimedia are par for the course and expected. One was never meant to kill the other—the embed element was even made valid and acceptable in HTML5. Thus, Apple’s stance that HTML5 multimedia should be the only solution—and it’s been taken to the extreme by blocking Flash altogether on their devices—then they circle back around with their plugin to provide the features that Flash already provided… Sorry, it seems disingenuous at best and anti-trust/anti-competition at worst.

Why don’t I hear people discussing this? Am I making up the gravity of what’s happening? Am I seeing something others haven’t noticed? Am I making a mountain out of a molehill? I’m starting to wonder…

Today on Twitter, Keith Clark (@keithclarkcouk) mentioned he was struggling with creating an element with rounded corners and rgba borders because the background color of the element was showing through. That sounded silly. I mean, modern browsers have background-clip. We can clip to the content, the padding or the border. That should fix it. But Keith was reporting that it wasn’t working.

In experimenting, I found that in webkit-based browsers, it doesn’t really work at all as I would expect (the Firefox 4beta does what I’m interpreting the spec to say). The background-clip property itself works (in modern browsers). But when the inner border is rounded (on the padding edge), the content with the background-color is not rounded—it remains squared. This causes the rbga border to overlap the square corners making an entirely different color on those points.

Firefox and webkit differences

The image below (from this border-radius demo) shows Firefox 4b on the left and Safari 5.0.1 on the right. Note that with transparent background, it keeps the rounded look. It’s only with the background color that you get the overlapping look.

Corner shaping

The spec reads like this (emphasis mine):

The padding edge (inner border) radius is the outer border radius minus the corresponding border thickness. In the case where this results in a negative value, the inner radius is zero. (In such cases its center might not coincide with that of the outer border curve.) Likewise the content edge radius is the padding edge radius minus the corresponding padding, or if that is negative, zero.

In the case of my code, the padding edge (which you can see as the inner border when there is no background color) should be made from the outer border radius (30px) minus the corresponding border thickness (10px). 30px – 10px = 20px. The content edge should be made from the padding edge radius (20px) minus the corresponding padding (10px). 20px – 10px = 10px. What I’m seeing in webkit however is zero curve on the content edge—at least that’s what I think I’m seeing. Is anyone reading this differently?

Corner clipping

Furthermore, the spec continues to talk about the corner clipping and says (emphasis mine again):

A box’s backgrounds, but not its border-image, are clipped to the appropriate curve (as determined by ‘background-clip’). Other effects that clip to the border or padding edge (such as ‘overflow’ other than ‘visible’) also must clip to the curve.

In my case, background-clip is set to padding-box. This means the background should cover the content and padding, but not the border. Webkit is not clipping to the curve of the padding (which we can see in the transparent example). 

What disturbs me a bit is that, in both Chrome 5 and Safari 5, the -webkit- prefix has been removed. It seems we need some method of ensuring that a vendor actually complies with the spec before removing their vendor prefix since, in this case, I can’t even “turn off” or change the rendering in webkit because the newest versions use the unprefixed border-radius property.

Is this a bug? Or am I reading it all wrong?

The web is becoming more and more dependent on Javascript. This has been troubling me a bit since I’ve always held the view that all content should be available and usable (though perhaps in a different state) when Javascript is turned off.

Internet Explorer

In Internet Explorer (up to version 9), the only way to use the new structural elements in HTML5 is to use Javascript to insert the elements into the DOM. Then IE will allow you to style them. If you don’t do this, IE will style the elements it understands (the HTML4 elements), but leave the ones it doesn’t unstyled (the new HTML5 elements)—and that can be worse than no style at all.

As I was writing a new talk on HTML5 recently, I struggled to find current information related to how many users view the web without Javascript enabled. The numbers ranged from 5%-8% (and I couldn’t be sure how accurate they were). When giving my talk at Web Directions US, Nicholas Zakas who was also speaking, informed me that Yahoo! has found Javascript turned off in 1% of users on their home page. He’s currently writing a blog post documenting/explaining this information and I’ll link to it when completed.

HTML5 and Accessibilty

I also wanted to be sure that there was no accessibility penalty when Javascript was turned off. To me, this is even more important since many that surf without Javascript (geeks) can enable it if it’s needed. But if the lack of Javascript harms the usability for screenreaders or other disabled users, that’s clearly problematic. Derek Featherstone pointed me to an excellent bit of testing done by Jason Kiss which showed that even though screenreaders may not totally understand the HTML5 elements, they still read the content. There are a few issues—you should read the article for more information—but it’s not related to Javascript, so we’re safe there.

When Javascript is Turned Off

The conclusion I’ve personally arrived at is this. I’m going to use Javascript to enable the new HTML5 elements in Internet Explorer. But I’m going to take it one step further. I’m going to notify those using IE that they need to enable JS to properly view the page. Instead of using the <noscript> element, I’m using Modernizr. I realize that <noscript> may seem more semantically correct, but there are situations where it may not be best served as such (serving your document as XML is one of them). It also doesn’t give you the same styling abilities without special care.

With Modernizr, I place a class called .no-js on my html element:

<html class=”no-js”>

Modernizr not only adds the IE support for the HTML5 elements, but it tests for many other supported and unsupported HTML5/CSS3 features and gives you feedback in the form of classes. That’s not the important thing here—what’s important is that Modernizr changes the no-js class to js. Thus, if my html element has the js class (along with a myriad of other classes), I know that Javascript is enabled. If the html element retains the no-js class, I know that Javascript is disabled and I can then serve the note I’ve written to let the user know to enable Javascript to properly view the page.

I create a paragraph with a class of “noscript” and put the information within:

<p class=”noscript”>Please enable Javascript to properly view this page.</p>
(Or any other pithy comment you’d like to make.)

In my CSS, I then set that paragraph to display:none if Javascript is enabled. This makes sure that only those with Javascript disabled will see my comment:

.js .noscript { display: none; }

In this case, I don’t actually see a reason to set the .no-js .noscript paragraph to display:block. If that class exists on a paragraph, it’s going to be set to display:block by default. If the html element never displays the class of .js, there’s nothing to override anyway.

Paul Irish has added this to the HTML5 Boilerplate as well. 

Happy coding!