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.

You'd think that the perfect Web 2.0 recipe organizer would already exist online — after all, they have a tool for everything else! — but I have yet to find it.

Food blogs are really big now, and though I don't food blog myself, I have gotten hooked on reading them. In fact, I pretty much get all my recipes these days from food blogs and never look in my cookbooks. Why would I? They're not searchable, they don't have beautiful full color photos of every recipe, recipes aren't backed up by real people's comments of how they liked it or adapted it, etc. Online recipes really are the way to go.

I began bookmarking each individual recipe in del.icio.us, as do many other food bloggers and their readers, because you can tag each recipe bookmark with all of its main ingredients or other characteristics (like "low fat," "easy," "Indian") and then use those tags to search for recipes that contain the mixture of characteristics you are looking for. So, I could find all recipes tagged with the combination of "dinner," "low carb," "chicken," and "garlic" by using the plus signs by each tag listed as a "related tag" to further filter down. I could also just do a search within my bookmarks if I was looking for something very specific.

This system worked exactly as I wanted, with these exceptions:

• no photos of recipes from the pages
• no rating ability
• no ability to add items to my list that aren't online
  

The rating ability wasn't a big deal to me, and I could also do without the ability to add my own recipes (I was fine with maintaining both an online and offline paper recipe collection) but I really, really wanted the photos. I searched high and low for an online tool that had the abilities of del.icio.us but with the added ability to choose a picture from the page you're bookmarking to associate with the bookmark. I found a number of online recipe organizers that came nowhere close to what I needed, and a number of social bookmarking tools that let you have a thumbnail of the whole page associated with the bookmark but not an individual picture that you can choose from within the page itself.

Finally I found Kaboodle, which is billed mainly as a wish list and shopping site. I thought it did everything I wanted except the rating, so I was thrilled. But I was wrong — it actually lacks the essential search tool of combining multiple tags to search that is the strength of my current system in del.icio.us. You can view all your items with a specific tag, but then can only filter those by keywords within their titles, instead of by further tags.

So, I'm still without the perfect online recipe manager, and undecided whether to stick with del.icio.us or Kaboodle. If anyone has a suggestion for what to use, I'd love to hear it! In the meantime, I have no problem with someone stealing my idea for the perfect online recipe manager and becoming the next big Web 2.0 success story — just please let me be the first person in your beta.

Usability has become quite the hot topic. Seems it's on everyone's lips of late. If it interests you, I'd like to bring a couple things to your attention.

First, Tuesday, November 14th is Worldwide Usability Day. There are 206 events in 39 countries this year. That's pretty impressive. Find a usability event near you. One of the interesting activities you can participate in no matter where you live is card sorting. From their site:

"Card sorting is a technique used to help identify how users organize, and expect to find, information on a website. The way the cards are sorted, and the labels the users give the cards are often used (along with other methods) to create the global and local navigation on a website."

Participants will take about 20 minutes to go through the card sorting exercise and demographic survey. The information will then be analyzed to look at regional, cultural, and other demographic differences, and shared with the usability community. You need to RSVP by Monday, November 13th to have the information emailed to you about participating.

The second bit of usability info that you may find interesting is related to a new, excellent book. It's written by Robert Hoekman Jr., called "Designing the Obvious: A Common Sense Approach to Web Application Design." I know Robert well, and he's passionate about usability, customer loyalty and just using common sense (which we all know isn't always so common). I've turned to Robert myself at times to look at larger web rollouts and he always has something helpful to say. And yes, once he says it, it's quite obvious. I've nearly finished the book and plan on writing a review on it here at Community MX in the near future. But I can already tell you, you need it. If you do anything web-based, you want it.

Robert is currently working on making GoDaddy a more usable place. This week, I went to GoDaddy to renew a few client domains -- I was shocked (in a really good way) at the new interface when I logged into my account area. It rocks! Pared down, everything at my fingertips, sexy. Thanks Robert!

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!