Hey, the economy sucks and everybody's scared. What better time to work on your education, up your web skills and earn a little extra job security? There are several upcoming conference opportunities I want to bring to your attention -- as well as reasons you might want to do it at all. If you're smart about it, you can streamline costs and make it an affordable trip.

Are conferences really worth it?

For my business, conferences have been invaluable -- and I'm referring to the time before I spoke at them. Not only do you have the ability to learn about many different subjects all in one place, but the networking can also be a key reason to attend. I can trace most of the original opportunities I've had in this industry back to the very first conference I attended -- TODCon (which sadly isn't happening this year). I recently ran into some old pictures from that conference and it occurred to me just how much of my web beginnings started there. At TODCon, I met Matt Brown who was then the Community Manager at Macromedia. Matt bugged, errr, I mean encouraged me until I agreed to write an article for the DevNet Center (yes, my first, and I was petrified). I also met Angela Buraligia, Dan Short and Massimo Foti -- and those relationships led to my first paper publishing experience (Chapter One of Dreamweaver MX 2004 Magic by New Riders). Most importantly, I met Ray West who encouraged me to join the team who was starting Community MX, prodded me into my first speaking gig (a later TODCon) and has been one of my best friends and supporters. In fact, those are just the high notes of that conference. I also met people there that have remained close friends and business contacts. People who have introduced me in turn to other people who became sub-contractors and go-to folks for various solutions in my business. In my opinion, unless you know it all (haha), you can't afford not to go. You can't afford not to give yourself the opportunity for growth and connection "in this economy."

I see the value, but I can't afford it right now.

• Economize by finding a conference close enough to drive to or one where the flight costs are lower.
• Save money by finding a roommate to share hotel costs.
• Take advantage of early bird and discount pricing.
• If your boss won't pay for the whole excursion this year, perhaps she'll split the cost with you. Negotiate. Show her the value you can bring back to your job.

(And remember, everything associated with the conference you choose is likely tax-deductible.)

OK, I'm convinced. What's coming up?

Glad you asked! There are several conferences coming up in the next couple months that are not to be missed (and yes, I'll be at all of them ;)). In chronological order, here they are:

• Voices that Matter - San Franciso, CA

  Voices that Matter (VTM) is a conference put on by Pearson (parent company of Peachpit and New Riders among other imprints) in San Fransisco. It's next week - April 27-29, so you need to act on this one quickly! The two tracks in this conference pull together many of your favorite authors. The sessions allow for question time, but one of the beauties of this intimate conference is it's very easy to have lunch with one of the speaker/authors or to catch them in the hall to talk. Take advantage of these speakers -- in a good way -- they don't just write your books. Many are designers, developers and Web consultants just like you. Tap their brains while they're available to you in person!

• WebDU - Sydney, Australia

  No, I won't be at this one. My son has finals this week and I couldn't chance being on the road while he didn't get out of bed. LOL But Greg and many others will be there. I was at WebDU last year and it's a really well-run conference with great speakers. If you're on that Southern continent, make a dash for it. May 21-22 in Sydney. Lovely, not too cold, good speakers. :)

• Spring <br /> Conference - Athens, OH

  The Spring <br /> Conference (SBC) is held on the beautiful campus of Ohio University in Athens, Ohio. It's a very inexpensive one day conference on June 9th. This conference includes Eric Meyer talking about (hold your breath) javascript! After watching Eric's mad CSS skills many times, I can't wait to see this!

• InControl Conference - Cincinnati, OH

  InControl is put on by AIGA Cincinnati in, you guessed it, Cincinnati, OH on June 11 & 12. There's one track each day and I have to say, they've really gone all out to pull together a great speaker line up. If you register before April 23, you'll be entered into a drawing for Adobe CS4 Master Collection. That alone could make your trip worthwhile. :) Early bird pricing is available until May 11th, saving you $100, with even more savings for AIGA members.

• Web Design World - Seattle, WA

  Web Design World brings a great group of speakers together for three days in what we hope will be a sunny time in Seattle. ;) Sign up by June 3 for a $200 discount. If you use my code - S9W12 - you'll save $395 off the standard price of the three-day Web Design World Passport - and I'll donate $100 to Habitat for Humanity. Everyone wins there. :)

So there you are. Four chances for you to bring some mad web skillz back to your business or our boss. And "in this economy" how can you afford not to?

When I write and speak, I often talk about using em units to size layouts giving the user the ability to resize the entire layout if they change their font size. In fact, chapter 5 of the book I co-authored with Greg Rewis is an entire project based on em units. Until all browsers zoom, this is my personal preferred method. My personal site is built using this method.

Last year, I wrote a blog post about Scaling fonts using em units and how I saw that affecting different types of users. A comment was made recently, and I wanted to address it in a new post while sharing a couple charts I made for myself. The comment said:

"A simple calculation as 1pt equals 1px at 72dpi (MAC) so:
1pt equals 1.33px at 96dpi (PC}
12px (pt) font in MAC is therefore 16px in a 96dpi PC.
If you have a parent element with a 11 pt font then to convert px dimensions to em you divide them by 14.63 (11pt x1.33) Dont interchange pt and px on a PC."

First I'd like to address using points for the screen on either a Mac or a PC. Simply don't do it. Ever. Points are for print. I regularly use points (as well as inches and serif fonts) when I create a print style sheet. I updated an article recently called From screen to print: Creating a print CSS in Dreamweaver published both at Community MX and Adobe's Devnet Center. One thing it addresses is how to use pts for print style sheets.

Until 2000, Macs used a 12px browser default and PCs used a 16px default. We got used to seeing different things (and due to the 72dpi vs 96dpi difference, it was further compounded if points were defined). I'm under the impression (but can't find anything quickly to back it up) that the 72/96dpi issue is no longer a problem. If anyone can point me to a recent reference confirming or denying that, I'd love it. Either way, all current browsers on both platforms now use 16px as their font-size default.

A while back, I was messing around for my own entertainment (you know, partying on a Saturday night or something) and created a couple of charts that might be helpful. The first is font size equivalencies. This chart shows that setting the font to 100%, 1em, 16px, 12pt and medium are equivalent in the same font. It also shows how font sizes can vary greatly from font to font.

The second chart was an exercise showing divs sized using em-units with a variety of font sizing. The red line down the right side is a graphic at 800px. The body's font size is set to 100% (16px). The first three divs show the default font sizing with the divs set to three different widths. The second section shows all divs set to 50em with the font-sizing (placed on the div) set to different units. It's an interesting exercise if you'd like to more clearly understand the effect of font sizes on the size of an em unit.

The interesting thing to me in the second chart, based on the gentleman's comment in my blog, was that viewing this chart on both a mac and a pc the lengths of the divs are the same. Yes, there's a very slight difference in actual font size on the PC - two of the lines of text slightly wrap to the next line - but the 50em width of the div is still exact on both platforms. Are we really that different anymore?

Though Greg Rewis and my updated book, Mastering CSS with Dreamweaver CS4, was listed on most sites with a February 9th release date, it's available now online! Since we were so late with the last one, we thought being early with this one might make up for it. Well, that's not entirely true. I think our publisher thought we'd be just as late this time and put a later date on it. Either way, the release date snuck up on me and since I'd promised to share it I wanted to give you a quick announcement here.

Mastering CSS with Dreamweaver CS4 has been updated for the completely overhauled interface in Dreamweaver CS4 and as such all screen shots and verbiage relating to that is updated. The new workflows in Dreamweaver CS4 are also introduced throughout the updated book. One change in Dreamweaver greatly affected the rewrite. Removing Layout mode took away the tool we showed to collapse tables and convert a table-based site. For that reason, principles taught in chapter 3 were integrated into chapter 4 (and I personally like chapter 4 better now -- the flow was completely rewritten). Throughout each project, we changed a few of the CSS techniques (as well as adding a couple new ones) as well -- isn't there always another way to do it? :)

Lastly, we integrated any errata found in the last book as well as utilizing some good suggestions made by reviewers. One of those was to have partial project builds available throughout each chapter so that users can check their work without having to go back to the beginning if they make a mistake. I think this makes the book even easier to work with than before. As always, keep your eye on the errata page (we do wish we were perfect) as we do keep it updated. More information on both books is available at the book site. If you have any questions, feel free to use the contact form and we'll get back to you as soon as we can. Happy coding!

There are several exciting, upcoming events I've been meaning to blog about but... life's been wild. This is my first blog post since making the move to Phoenix, Arizona, rewriting Mastering CSS with Dreamweaver CS4, and shooting a video for Pearson on CSS and Dreamweaver. I'll blog again when those two items have release dates. It's safe to say I've been scarce everywhere--except twitter (where I'm stefsull).

Before I miss the opportunity, I'd like to mention that the first, virtual, world-wide conference is this weekend! The <head> conference, created by my friend Aral Balkan boasts an amazing line up of speakers. It would be hard to get this many people from this many places into, well, one place. Some speakers will be speaking live from hubs (like London) and the rest of us will be coming to you live from our own offices or, since it's the weekend, our homes. :) There are three virtual conference rooms using Adobe Connect Pro (viewed directly in your browser), chat for participants to get to know each other, a room (and events) in Second Life and other creative ways to allow attendees to interact virtually. Since you can't be in all three rooms at once (just like a regular conference), you'll have a year to view any of the presentations you like from the library. The only difference is that you can't ask questions in real time. It's quite affordable and won't cost you anything for travel. Just think of all the emissions you'll save -- a truly green conference. I'll present a session Saturday, October 25, at 20:00 - 20:45 (UTC) (that's 1pm in Arizona) called Content is for Everyone. Virtually come out and be part of history in the making!

A conference "in real life" you may want to attend is Adobe MAX. MAX is one of the largest conferences of the year. But don't be afraid, there are tons of small to moderate rooms and the geeks are friendly--particularly at the parties. :) With the recent launch of CS4, you'll have the opportunity to learn a lot about the new products. There are also sessions on mobile, CSS, interaction design and other more general subjects. I'll be presenting a session on Monday, Nov 17th called, Standards-Based Solutions to Common Web Design Challenges. On Wednesday, I'll present another session called, Common Mistakes Print Designers Make on the Web. This session is particularly good for people being moved from print, into the web space, but the content is also pertinent for people starting out that need to grasp CSS and the fluidity of the web. Be sure to sign up for these soon though -- they're filling up fast.

Whether virtually at <head> Conference or in real life at Adobe MAX, be sure to come up and say hello!

Back in November, I wrote a blog post explaining a fix for the poor and varied rendering you will get with a wordy legend that forces its containing fieldset to be wider than you've specified. You can read more details in the previous post. In a nutshell, it involves placing a span within the legend. Since a span (and a legend) are inline, the span won't render the width until you change its display to block. The styling is then applied using a descendent selector - legend span. (The span within the legend technique is demonstrated here.)

And all was well in the world of cross browser fixes -- until the birth of Firefox 3. The changes made to FFOX 3 mean the span technique now fails in that browser. (Thanks to Atus for the heads up.) The behavior of FFOX 3 continues to be a legend that doesn't wrap. However, instead of making the fieldset wider, the legend now protrudes out the right side of the fieldset. (If you view the file linked above with FFOX3, you'll see that the span does render at the width specified in the selector - but the content within continues and protrudes to the right, until it ends. Unsightly to say the least.)

Just one more declaration

After filing a bug at Bugzilla, I was told that the changes made were to keep the original rendering for those that prefer it, but to now offer a fix (without the span technique) for those that desire more control. Certainly progress is a good thing. Using the white-space:normal declaration within the legend rule causes FFOX3 to actually wrap the text. So YAY for that! (Thanks a bunch, Philippe.) However, this of course, does nothing to FFOX2 or any other browser with the non-wrapping issue. So BOO for that.

If you want to support browsers with the non-wrapping issue, you'll still need to add the span within the legend. However, to support FFOX3, you'll need to add the white-space property to either the legend or legend span selector. In my testing, both will work. This fix for FFOX3 does not affect any other browser negatively - but it doesn't fix any of them either. (View the page with the white-space in the span selector. View the page with the white-space in the legend selector.)

To me, the bigger conversation is, why the blank can't we get some form rendering that actually makes it easier to more consistently mark up and render forms? I'm sure someone can tell me where my thinking is going wrong -- but a legend is an inline element. An inline element doesn't accept a width. I'm good with that. But when paired with the fieldset, it's parent that does have a width, why is it not contained? Why in some browsers does it force the fieldset wider than we've specified. I don't think inline elements should have that much power (especially since it must not be white-space:nowrap declaration causing the increased width for the other browsers since the FFOX3 white-space: normal fix doesn't work for them)! And why, in FFOX3, does the content in the span (contained in the legend) not react to the styling given to the legend span selector? The span itself does, but the text within runs out the right side of it. I know someone will say because in the Moz style sheet, the legend is set to white-space:nowrap. I see that, but WHY was that the fix/change given when none of the other browsers seem to be handling it in that way? Inquiring minds want to know! (I mean, when exactly would you want the legend to overrun the fieldset and not wrap? And couldn't you just add white-space:nowrap when you did?)

(Update) Philippe and Boris essentially explain it this way: A legend is not actually an inline element. A fieldset/legend pair are treated as replaced elements. Just like the form controls they contain (Boris explained that the reason has to do with the way borders have to work). Thus, they can't really be described with CSS. Philippe pointed out that in the conformance section of the specs, it says, "CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further." So I suppose what it boils down to is - this is what we've got for now. :)

For those wondering and dreaming of the great beyond - thinking about what's on the horizon with Internet Explorer 8 (currently in the beta), it's fine with the "span technique" and it's not bothered by the added declaration of white-space:normal. However, unlike IE6 and IE7, it's placing the legend down, below the top border of the fieldset - instead of halfway over it like the other browsers do. But it's still in beta. I'll worry about that little issue, if it still remains, later.

So there's been a pretty decent sized debate going on through the webosphere. Designers should know how to code. Developers should know how to design (or shouldn't need to design). I considered weighing in on the 37 Signals blog -- but the comments were already closed. Call me slow (yes, I've been on the road, had a birthday, and had my mom visiting with her birthday. ;). You'd be right. Oh well.

I do have one thing to say. Well, I probably have more than one, but I'll start with that. I recently did a couple sessions at the HOW design conference. One was on "Mistakes Print Designers Make on the Web." Yes, I definitely agree there are common mistakes from the print paradigm. Many times I can tell how people's brains work when they ask for help on lists. I can tell they don't understand the web or come from a print background. However, that does NOT mean I think they are useless. Do I think they should know how the web works? That the web is a fluid, not static medium? Am I willing to help them learn (if they're going to be in my "designer stable")? He77s yea. I am willing. Because I think they are very important to our industry.

Do I think that coders should not use a graphic medium. Lord no. "Designing" (or so they call it) using the constraints of "what's easy to do with code" is really a sad, and less attractive, way to work. I say bring on the tough comps -- we'll work it out, or we'll ask for a small revision. We'll come up with a way to make it work accessibly. A way you might not have thought of before -- but a way that is equally lovely. But lord knows I think you design types are valuable. I quit designing years ago. Why? I'm a tweakaholic. I make more money hiring people that are more creative, better trained and faster. My clients save money with those same people. The designers are freed to be their creative selves -- but yes, it's nice for me if they understand the web. It's nice if I don't have to lead, guide, explain. That said, because I know my craft, I'm willing to help them at the beginning. And no, I don't expect them to know how to code. Just to have an overall understanding that the web is not print. Everything will not have line breaks where they want it to. It won't be glued down. But I, with my experience, will guide them through what can and can't be done. In time, they will be one of my favorite designers. They will understand, but they will send it to me to code. Because that's what I do best.

Do you create the site with HTML? Do you create it without a graphic program? Well, gawd bless you. But I'd venture to say your designs are likely boring. I think 37 signals rawks in usability. I have no bad words to say about them. But what I'm seeing from their recent blog posts in this area is just silly. And no, I've never seen a super creative design come out of that group (at least that I KNEW was from them. I'm certainly not barring it).

Personally, I welcome the challenge of the design minds. I find that if I create the site IN HTML, I do what's easiest to do with HTML/CSS. I don't challenge my abilities. I don't push the envelope.

Yes, the site is about the content -- the message. People are generally looking for information on the web. I teach that all the time all over the world. But there's another side of it. There's the package that same content comes in. Is it readable and usable? Good. That's important. Does it work when the text size is large. Does it work with assistive technology. Excellent. Accessibility is even more important. But goodness knows that a majority of your readers are going to be influenced by what it looks like. Yes, even the colors. Study color psychology. Look at eye patterns. Immerse yourself in usability and interaction. Heck, watch your mom try to navigate things -- I just did. It's eye opening. How it looks is important. Sorry, that's just the facts. Why do you think company's spend so much on their Superbowl commercials?

And let's not leave out how you interact with the database -- how well that content dynamically appears. How much sense it makes. How usable the interface is. There are many things to think about. The root of my story and my point is -- it's the rare individual that has all the strengths needed for one web site. It's the team that matters. Should everyone have a basic understanding of the other member's jobs? How they work? What they can accomplish. Oh yes. Absolutely. Should they be able to do them? That's just ludicrous. Absolutely not. Surround yourself with people more brilliant than yourself. Always learn. Work hard. You, and those around you, will be enormously successful.

Ciao.

As I train all over the world, one of the issues I try to spend a good deal of time on is helping people to understand the malleable em unit. And how to utilize it for good and not evil. :)

Anyone who knows me knows my burden for accessibility and the em unit is one of the most accessible ways to design. In fact, Greg and I spend a chapter on it in our upcoming book, so I won't go into a lot of detail here. But today, I stumbled upon a really great font-size calculator created by James Whittaker. If you'd rather keep it handy on your desktop, he also created it as an Adobe AIR application.

In reading the comments of his blog post, I saw a couple people questioning the reasoning behind decreasing the default text size of a user at all. And I began to answer those questions with my own opinions. About three paragraphs into my reply, it occurred to me that I was monopolizing James' comments and it was best done as a blog post of my own (please read James' post for the full story).

For the quick back story - the default text size of modern browsers is 16px (that would equal 1em). It's quite common to choose a 12px font-size which is 75% of the default sizing (.75em), as the base font size for elements on your page. (I'm not going to address here whether that should be placed on the body, or on individual elements.) The people responding in the comments were questioning whether we should adjust the base font size (something I've heard for years) since we're taking away "the experience the user expected." My reasoning follows...

The Three Groups of Users

I likely don't have to remind you that back in the days of tag soup, 12px was a very common size to set type to on the web. In fact, even after many developers started controlling their typography with CSS, 12px was probably the most common size to set type to. So saying that people who leave their browser set to the default 16px size want that size is simply not true. They hardly know what it looks like since more often than not, it's overridden by other font sizing and styling anyway. And if they're like the average user, they don't have the inclination to change it either. They can see just fine, thank you. And they use most of their apps with the defaults they ship with (which explains why most of those same people use Internet Explorer -- since it ships with their operating system). They're not upset that you changed their text size since they get what they have always seen and have come to expect.

Now, in the case of a low-vision user, this is not the case. If someone struggles with the issue of low vision and surfs the web regularly, they've probably developed a method of dealing with it. Users with aging eyes, many times instead of changing the base font size of their browser, have simply learned to use menus or key commands to bump the text size up. They change to a more comfortable size when necessary, but sometimes are limited by the fact that the site breaks in some way as they increase their font size. With this 75%/.75em font calculation, they get what they expect because they surf at default sizes to begin with and they still have control as well as a usable site at any size they settle on.

There are the more extreme vision-impaired that change their default browser text to 32px, 45px, or whatever size works for them. If they've changed their default to 32px, using the 75%/.75em size puts them at 24px. They can still use a key command to increase the text size if necessary. They're probably the users that know the most about making your site work for them because they need it the most. I'm guessing a great deal of the web is difficult for them to use (with columns that have one or two words per line, overlapping, elements getting cut off, etc). So though they don't get their initial optimum size (which is, most probably a common occurrence for them since many sites still use pixel sizing), they have the tools to increase the size a bit more if it's necessary.

Now, do not misunderstand me and think that I'm saying that since the very low vision user is the only one that doesn't get what they initially expect, that they're not important. They are and all users and user agents should have access to the content. I'm simply saying that the first two groups, and even part of the third (for the not uncommon pixel-based sites) see what they expect to see. And with em-based layouts, they have the tools to change them--very smoothly giving them a great experience. That's all.

Recently, I did a presentation at Webmaster Jam Session in Dallas. In my session, one of the things I showed were some faux column techniques. During the QA at the end, a problem was brought up that I hadn't run into. The statement/question was that, evidently, there's a reported bug in Internet Explorer 7 (OMG, imagine!) where background images are not zoomed with the rest of the page when the Page > zoom accessibility feature is used. So when you use a faux column technique on your web page to create the illusion of equal columns, your text can end up not being on top of the column color you want. In some cases, this can lead to some pretty major legibility problems. The attendee stated they had given up faux columns due to this issue. Talk about depressing! I use faux columns so regularly -- I just couldn't imagine I had to give them up!

I talked to a couple Microsoft people and yes, they said it was a known bug, but I couldn't get any information about a possible fix time frame. Now that I have IE7 on my computer (yay, VMWare!), I had some time to have a look (well, I didn't really have time, but due to something I was working on and with my curiosity piqued, I did some testing). What I found was actually so much better than what I expected. I'm sharing it for those out there that may have the same misconception I did -- along with a couple of workarounds I've discovered.

• Misconception: When using a background image to create the illusion of equal columns (faux columns), the background images don't zoom with the rest of the page causing legibility problems.
• Fact: The problem actually only occurs when you put the faux column on the body element (depending on the situation, sometimes I do, sometimes I don't).

Two Solutions for IE7's Zooming Issues

1. Place the faux column image on a div that wraps your entire page instead of the body element. This graphic will zoom with the rest of the page. Since many times, this is my preferred method, it's no wonder I hadn't run into the bug.
2. If the graphic must be place on the body element, don't lose hope. I found a workaround there as well. If there is a background property declared on the HTML element, the background image on the body element will zoom. This seems to work on the HTML element with both background images and background colors (I tested using the short property name background with both). I removed the background color from the body element and placed it on the HTML element instead. In all major browsers I tested, it worked perfectly.
3. Update! I should have thought of this when I was testing. This works where I've tested it (IE6, IE7, FFOX, Safari) but I've not been exhaustive across every browser due to other deadlines. It shouldn't cause any problems though and it gets Dreamweaver users around a rendering issue (where the color on the HTML element isn't rendered in the DW workspace). Keep the normal background properties on your body element -- background color and image. Simply add a background property on the HTML element as well:

   html { background: #FFF; }

   The body zoom still works properly in IE7, and due to the cascade, the html color is overridden by the background properties on the body selector. It's valid code. It's not a hack. It makes one of the handiest techniques in my arsenal work until IE7 is fixed (no bets on when that might be) and no harm is done. Only good. ;)

So don't give up hope on the fabulous faux column technique just because IE7 has some issues. Continue to use it all you need to -- just keep the above parameters in mind to decide what you need to do in your situation.

Yes, it's rather embarrassing, but I admit it. I have a Facebook account. Though I resisted for a long time, I was recently convinced to join Facebook to participate in a birthday prank for a friend. Oh well, another social time sink.

On Facebook today, I was invited to join a group called "Blue Beanie Day." November 26th has been named Blue Beanie Day, in honor of Jeffrey Zeldman's photo, donned in a blue beanie, on the cover of his book, "Designing with Web Standards." It's a day to stand up and show our solidarity around accessible web development using Web Standards. And besides that, it'll just be plain fun!

Here's how it works:

1. Buy, beg, or borrow a Blue Beanie and take a photo in it. Heck, you can even take a picture with your camera phone at the mall trying one on if you don't want to buy it. Maybe you'll put a beanie on your head or change a black beanie to blue with Photoshop. Be imaginative. Take a cool group photo of you and your friends wearing Blue Beanies. The possibilities are limitless. Show your beanie creativity.
2. Post your photo, or photos to Facebook, the Flickr pool, and other social networks on November 26th, 2007. Remember to switch your profile photos that day on all your social networks, like Flickr, Twitter, Last.fm, iLike, Pownce, Dopplr... you name it.
3. Promote Blue Beanie Day in your blog or wiki starting today. Tell all your friends to get ready for Blue Beanie Day. If you have a Facebook account, join the group and invite all your Facebook friends to this event.

You can participate without a Facebook account too. Just grab a beanie, make it blue and join in! See you there.

I've just returned from over six weeks on the road (12 locations all over the globe). Needless to say, I've been scarce around these parts of late. I'm hoping to start remedying that.

While attending one of the conferences, I was discussing creative, problem-solving techniques with an attendee, and mentioned a method I'd recently employed for legends that won't wrap in some browsers. They mentioned that these types of creative tips should be blogged and, well, I'd truly intended to blog it here for others who run into the same problem. I found precious little written on it when I was searching for a solution. I figure it's better late than never. :)

Many of you understand the accessibility and organizational reasons for using the fieldset and legend elements. I was recently coding a site that had a large number of forms. I was using fieldset and legend to organize and group the information. The copy written was very off-the-cuff, conversational and fresh. I liked it. But occasionally, the amount written (and used as the legend) needed to wrap to a second line. Enter the problem.

I found that the wrapping behavior varies from browser to browser. On a Mac, legends wrap automatically in Opera, Safari, and Explorer. They do not wrap in Netscape, Mozilla, and FireFox (obviously the Moz-based browsers). On a PC, they don't wrap in Netscape, Mozilla, FireFox, or Internet Explorer. This means that you either have the div containing your legend pushed wider and overlapping your other divs, or, in the case of IE, it can cause float drop. You can place a break element into the legend to randomly force the text to a new line. However, once the text size is larger, and you're viewing with a browser that does allow the legend to wrap, you get a horrid stacking of the legend. It wraps automatically and then again where you placed the break element. Unsightly.

Several suggestions were made on a list I'm a member of. One was to put a width on the legend (which didn't work in all browsers). The other was to make the text within the legend extremely short and then place the longer question/comment directly below it before the form controls contained by the fieldset. That, however, isn't a good option either (even if I did want to change my clients interesting way of wording things). Once Assistive Technology (AT) enters forms mode, it doesn't read elements not marked as form elements (like paragraphs, lists and headings). So though it was an interesting idea, it was sub-optimal and nixed as well.

Finally, after much discussion, Mike Moore (on the WebAIM list) and my friend Derek Featherstone (by IM), put me on the right track. The answer lies in placing a span element directly inside the label element - <legend><span>Text within it</span><legend>. Then, create a rule (something like - #divName legend span) which includes display:block (since a span is inline by default), the width you need, along with your other styling. Works perfectly in all the major browsers. So there you have it with many hat tips to my friends. :)

For anyone who knows me well, the most shocking part of this post is that I actually, finally, put my own web site up. Yes, after 2 years of "Coming Soon," I've actually launched my site focued on training, speaking and coding. One of the things I learned (which I knew, taught, but obviously wasn't practicing) is--let the content dictate the design. Oh my word--I had three designers work on the site over the past two years before I realized I should practice what I preach and let the content, semantically marked up, determine the design. So much better than trying to force the content into your preconceived design notion--at least when you'd like to accomplish something. Special thanks to Carolyn Wood (editor-in-chief of Digital Web and owner of Pixelingo) for all her hard work with me on this (and for continually kicking my butt)!

Meanwhile, something I found in the process of creating this site, I wanted to share with you guys. Due to the spam I receive on my blog and the form on my old site, I really wanted to make it more difficult for the bots. However, I'm also very concerned about accessibility with the current CAPTCHA products I'm aware of. Enter reCAPTCHA. This one actually gives the user the ability to interact with the CAPTCHA by viewing the image and typing it in--even with JavaScript turned of. And if they prefer, they can have the challenge spoken. I've not had the ability to have a non-sighted user test it, but it seemed to work well for me when listening to it. Best of all, it's free!

They have one other product which I'm also using -- Mailhide. You enter the email and they generate some code that you put into your page (I doctored mine a touch) and, in the same way, it forces the user to solve a reCAPTCHA challenge to get your email. Of course, I'm sure nothing is foolproof, but having a little protection is better than nothing at all. Have a look!

If you get the CMX newsletter, you may have read the blurb about the upcoming Web Directions North conference. This is the sister conference to the awesome Web Essentials/Web Directions conference that has happened down under for the past few years -- the one that I've been so jealous not to be able to attend. If you felt the same way, now's your chance! Canada is a lot closer than Australia for many of us. :)

Here's the coolest part to me. Not only are the speakers world-class and the topics current to today's web, but you can ski! That's right -- if you're a geek that loves the cold, white, powdery stuff, there are two days of speakers, and then, two optional days of skiing (or snow boarding, of course) at Whistler-Blackcomb in British Columbia. How close to heaven is that? Even if you've never skiied before, there are plenty of easy runs -- and lessons. Don't be shy -- we're geeks -- we're supposed to make fools of ourselves. And anyway, no one will laugh -- for long (except, perhaps, at my 15 year old ski outfit... heh).

I've got several conferences to go to this year, and South by Southwest (one I'm already registered for) is very close to these dates. Conference money can certainly get a bit tight and I don't want to have to make a choice. That's why, if you decide to register, I'd love it if you'd click my little affiliate link to the Web Directions North conference. Once you're on the home page, click the register link on the right side. The cookies will track your every move and there's a chance I can earn my way there. So come on -- you know you wanna go! Let's go together (I do not, however, assume any responsibility for geek injuries that may occur as a result of clicking the above link)... ;)

After letting HTML stagnate for years, the W3C has finally decided to start fixing it up again. That's right folks: XHTML is not the only standard in town. HTML has remained a standard all this time, just as valid a markup option as XHTML, and now it's apparently going to get an update.

This decision has been met with a variety of strongly expressed opinions. The comments on the article range from supportive to confused to angry.

There have also been some responses written at other blogs. I really like Joe Clark's response, which emphasizes the need to work on WCAG 2, not HTML, which is being handled just fine by the browsers despite all the cruft.  I'm not as much in agreement with Elliotte Rusty Harold's response. He seems to be one of the people who thinks that only XHTML can be written cleanly. I've never been clear on how clean, well-written XHTML is any better than clean, well-written HTML — especially when the XHTML is served as text/html anyway. Maybe someone can tell me a real benefit of using XHTML, aside from the easy portability to XML (which I can also achieve with clean HTML by running it through any number of tools to convert it)?

Regardless of where you stand on this issue, there's some good reading out there right now on our humble friend HTML. 

In my last post, I complained about sites that pop up windows and take away my menu bar so I can't print. Tonight I found the perfect Firefox extension to stop this annoying scripting: Unhide Menubar. It keeps scripts from ever hiding the menu bar, ever. I've already put it to use to print out my flight confirmation through Orbitz.

Why do so many sites that insist on opening popup windows also insist on taking away my menu bar when they do so? Sometimes it makes sense, such as in my Yahoo Music player that pops up. But other times it seems to only be done for its own sake, and it's really annoying.

Last month was the annual enrollment period for health care spending accounts, dental insurance, vision insurance, and several other benefits programs offered by the State of North Carolina, which I work for. This year, they offered an online enrollment option for the first time. However, the web site they created solely for this purpose (they already have a couple other web sites, and I have no idea why they didn't make this new site simply part of the old sites...but I digress) was awful. The navigation was very unclear and hard to use.

When I went to enroll, the site insisted on popping up a new window with all of my toolbars stripped away, including the menu bar. Why? This didn't help me in any way that I could see. The enrollment process was just a series of forms and text-based pages — in short, nothing that couldn't be presented in a regular web page as part of the rest of the site. Perhaps they didn't want me to click any links other than the form buttons that navigated me through the enrollment process? If that was the case, why not just strip the nav menu out of the enrollment pages, and just leave me in the regular site?

I can handle a popup window, as much as it annoys me, as long as it doesn't hamper my work. This one, however, did. When I finally enrolled, I clicked on their printer-friendly version link. This opened another popup window. I expected it to automatically bring up a printer dialog box, since I couldn't access File > Print to do it myself. Instead, the new popup told me to hit the Print Screen button to print the page. But the PrtScn button doesn't actually print — it takes a screenshot! I had no way to print my page. Why had they decided to hide the menu bar from me? What harm would it have been to include it? What benefit did they get from it that was so important it was worth completely wrecking the user-experience for me and preventing me from printing?

Ironically, after I finished my enrollment, they presented me with a feedback form, "in order to ensure that www.ncflexonline.org provides the ability to meet your needs." However, the comment fields they provided only allowed 256 characters, which is only a couple sentences worth of comments, and not nearly enough to convey my dissatisfaction. I suggest that if they really want to create sites that meet their users' needs that they employ extensive usability testing before launching a site, instead of taking surveys afterwards that never appear to be acted on.

After this frustrating user experience, I went straight to userscripts.org to find a Greasemonkey script to override all those sites that try to take my menu bar away from me. Alas, no such script exists on this site. I beg someone to write one and let me know about it! Or, if anyone knows any other tricks to get the menu bar, or other toolbars, back, please let me know that as well! 

Today I heard about a very cool new tool developed by NASA. From their press release:

The MDE (Math Description Engine) distinguishes itself from other accessibility software by determining the key characteristics of a graph "on the fly." Using this determination, it builds natural-language text descriptions that enable visually-impaired users to view spatial relationships through sound alone.

Check out the demos at the MDE web site for examples of the text and sound the software can generate. It's pretty neat. I can see a great use for this, as I work for a research center that deals with a lot of data. So far, we've laid graphs out and written their alternative text manually. But with this new tool, it might finally be time to look into graphs that are built dynamically, because now they can be accessible too.

Good grief. I really don't have a problem with Flash banner ads at all. In fact, many times they're the best way to showcase a product. What I am greatly annoyed by though, and they're starting to pop up everywhere, are the ones that move down over the active part of the page. Sure, they're real sexy and all -- but get off my freakin' links!

Last week, I saw one where the guy looked like he was pushing the Flash ad downward and grabbing something from the other advertisment below. Problem is, he has to "traverse" across the top navigation which, when covered by the transparent Flash movie, isn't clickable. You can't activate the buttons or links while he's doing his cute little thing. Well, let me rephrase that -- in IE you can (due to the dangers, errr, beauty of Active X), but not in any other browser.

Today, we have a possible tropical depression off my coast. I quickly went to the Yahoo! weather page to find a satellite pic. I didn't find what I wanted, went up to the navigation to click something else and the stupid Flash movie drops down over the buttons. I had to wait while it did it's thing and got off the navigation so I could get off the page. Now, I understand that usability studies have shown that people ignore the top area of the page where banner ads live. And I understand the advertisers wanting to find a creative way to get users to look at their ads. But don't hijack me. If I want to leave, let me go. I think we need to make a fuss or this will end up being like commercials at the movies. You pay to get into the movie, and then have to watch ads for products. Things like this are just wrong. On so many levels.

For those of you that have been following the development of, or even using sIFR, this post is for you. Mark Wubben has announced the release of the alpha of the next version of sIFR. I just got back from TODCon, so I haven't had time to play with it yet, but the feature list makes it look very promising. Especially the part about the increased simplicity of tuning your fonts. For me that was the only difficult part.

Other interesting bits -- Mark is taking advantage of the new Flash 8 filter features, like drop shadows. You'll also get the added benefit of Flash's new anti-aliasing and leading. There's also a fix included for the AdBlock issue. All in all, very promising.

If you've got time to test/play/help make this version the best it can be, head over to the sIFR 3 Alpha page and download it now.

Before I left for my two whirlwind trips, I was interviewed by the guys over at Lodestone Digital for their weekly geek podcast - Lodebearing. We talked about a variety of things including web standards. The only problem was, somehow, since we did the interview over Skype, I came out sounding like the digital chipmunk version of myself. Or perhaps like I was holding a few marbles in my mouth while I talked. (Yes, I've heard myself on audio before. No, it didn't sound like this. ;))

It sounded so odd to me, I didn't link to it or tell anyone. OK -- so I'm over it now. If you want to hear Digital Stephanie Marble Chipmunk, make your way over to my podcast interview for the entertainment. It's about halfway through the show.

Recently, one of my clients with a Bobby AAA accessible site was informed that his PHP style switcher didn't work with a Linux/Mozilla 1.4 combination. This was troublesome since it's very important to him to be accessible not only to screen readers, but also to low vision users.

I attempted to get to the bottom of it and, with the help of Tom Pletcher here at Community MX, I found the page at Mozilla where you can download all the previous versions of the browser. I'm sharing it here just in case I ever lose my bookmarks ;) ... and so you don't have to dig for it if you need similar. Mozilla 1.x Releases will give you access to all Mozilla 1.x releases for all platforms. Handy!

Using these, we were able to download Mozilla 1.4 (2 years old) onto OS X and a PC -- these showed no issues with the switcher. I found a friend with a Linux box that had Mozilla 1.7.8 installed -- which also worked perfectly. I was able to convince him to install Mozilla 1.4 on that box to test for me (thanks Steve!) -- It was also flawless. Thus, we determined the issue was on the person's computer that reported it which releived my client's mind. But without that great little link to the older versions of Mozilla, I would have been searching through Google for similar problems, likely taking more time than I could afford to give it with my workload of late.