Skip to: Navigation | Content | Sidebar | Footer


Full Archives

Font Size Redux

November 28

Phew. We're turning over the font size issue so vigorously it's gone green.

An on-screen style switcher was due on this site sometime down the pipeline, but I rushed it in response to the discussion. See right-hand sidebar—if things are funky, reload.

Here is every way this site now caters to potential font size problems:

  1. All fonts are defined in relative units so that even IE can scale them.
  2. Two style sheets exist, one with units defined, and one that bases units on your default browser size.
  3. You can switch between these with any browser capable of style sheet switching.
  4. You can choose a style and make it persistent by hitting one of the buttons on the right, thanks to the magic of cookies.

The only potential group that might still have a problem with all of this are an insignificantly miniscule fraction of users who disable scripting/cookies, retain CSS, leave their browser default at 16px, can't read the text, and refuse to suffer the inconvenience of hitting two keys upon entering, and two keys upon leaving this site.

I've yet to write the alternate page that will load if scripting is disabled and the links are hit, but rest assured, that's coming too.

Permalink › | 33 comments

Font Size: No Happy Medium

November 26

If there's one thing nobody can agree on, it's how to treat your text size. Pixels aren't scalable within the most common browser on the market, and if you do everything you can to support relative units, you will still get people complaining that you are using text that's too small, or too big, or too low in contrast, or too high in contrast. A designer can do his or her best to find a happy medium, but someone will always speak up:

Please see http://www.w3.org/2003/07/30-font-size

I have. Why? The only point on that list that I might be breaking is "Avoid sizes in em smaller than 1em for text body"—a pretty good success rate.

Because your fonts are tiny!

CTRL + '+' ? Or CTRL + 'scroll wheel'? I'm using relative sizing specifically for cases like this. Besides, my text is a pretty common size...

Of course I know how to adjust font size in my browser quickly. Doing it all the time is annoying though.

My fonts are based on your default browser size. If you bump that up, they scale accordingly. So is this my problem, or, perhaps, yours?

And what about thin users who think that IE 'is the internet'?

My site is not for them. I have a target audience; what do mom & pop care about CSS, after all?

Perhaps your site is not for them, but, in my opinion, ALL websites should be accessible to ANYONE, ANYWHERE. My opinion of course.

Then read [above] again. My target audience is not clueless newbie. But they are able to view it all the same—not only are my fonts scalable, the rest of my site complies with Section 508 and the better half of WAI's AAA. In fact, it would be single A if it weren't for FIR; other than that it's kosher. Even IE can scale my fonts just fine, and it renders the site well.

I really have a hard time understanding what your problem is—if you don't want to hit CTRL + '+' just say so, and don't cloak it behind misdirected accessibility concern. This isn't an accessibility problem, it's a convenience problem, n'est-ce pas?


Okay, a rather contentious way to start off the day. But something I'm hearing more often than I'd like is the opinion that text size should be left alone; a user's default font size shouldn't be messed with. This is an idealist view, and not at all representative of how the world works.

Built into that viewpoint is the naïve, or willfully ignorant assumption that all users are a) aware of this setting, and b) have changed it to suit their preference. Even the low percentage of the population that know they can do this generally won't; too many existing pages rely on a 16px default font size. The majority, believe it or not, would bump their default down a size or two. 16px is too big for most people.

If it helps, don't consider this issue on a site-by-site basis, consider it on a web-as-a-whole basis. Bump your font size down a setting or two, and start loading some common sites. Microsoft. CNN. Yahoo. This site, even. All become less legible, since they assume a starting point of 16px. And they assume because people don't, as a general rule, screw with the default font size.

Let's ignore Internet Explorer for a second. Browsers like Firebird and Safari allow a quick adjust. If, as a user, I visit a site that uses a text size I can't read, I can hit CTRL + '+' a few times until it's legible. Done, and my fonts are now bigger for every other site. The fact is that my browser allows me to compensate in different ways; I can even whip up a custom user style sheet to customize each site I care to, if I wish.

Which places the legibility issue in a grey area somewhere between designer and user, since both can combat the problem. The designer should take precautions to ensure his or her default font size is legible to a wide percentage of the population. But is it necessary to address users who need extra assistance, within the same style sheet everyone else uses? CSS offers choice; is there some reason we shouldn't be taking advantage of this?

The current standards movement seems to place an awful lot of responsibility on the designer. It's up to the designer to work around browser flaws by not using pixel-value text. It's up to the designer to consider people with perfect vision, low vision, and no vision. It's up to the designer to account for different monitor sizes and resolutions. It's up to the designer to make sure their layout doesn't break when fonts are at 100%, or 150%, or 200%.

Which, when you consider the history of the web, is the way it's always been, except that no one used to do it. And now that we are starting to, by way of alternate style sheets and relying on relative font sizing, it's becoming clear that while CSS offers answers, sometimes the answers aren't good enough for some users.

Yes, it's important for the designer to keep all these things in mind, and with a developed social conscience, cater to the largest audience possible. But, and here's the whole point of what I'm trying to say, when the designer does this to the best of his or her knowledge and ability, and it's still not enough, perhaps it stops being his or her responsibility.

Permalink › | 47 comments

CSS Crib Sheet Archive

November 25

The Crib Sheet has moved to a permanent home. I threw it into this site's template for now, but I may choose to do something differently, eventually. Perhaps a PDF or two. The good news is that my print style sheet should allow for a relatively clean printed version for now.

I'm referring the Sheet to this post, and leaving it open for comments indefinitely. Feel free to add more suggestions below. Remember the focus: practical, real-world tips that aren't picked up in the spec, or by the validator. Things that are easy to trip over, and may not make sense without external knowledge.

Permalink › | 34 comments

Meatspace

November 24

'Tis the season for industry events, fa-la-la...

I'm a few months early for South by Southwest, but before we get to that: WestCiv builds the popular StyleMaster CSS Editor and publishes the House of Style. WestCiv is hosting a series of workshops on CSS layout in Sydney, Australia in a few weeks. The first has sold out, and the second only has a few seats left. Anyone looking to sharpen their CSS skills who will be in the area on December 12th may want to book a seat, like, now. It would seem that the Zen Garden will be a focus; don't let that fool you, I'm not taking a cut for plugging the workshop. WestCiv is a company that really gets it; that's worth supporting.

The beginning of next year is looking mighty interesting. What I can tell you for sure is that somehow, some way, I'll be finding myself in Austin in March for SXSW Interactive.

The Zen Garden has been entered in the Awards as a developer resource, since I can't quite see it taking the 'Humor' or 'Music' prizes. Should I hedge our bets and enter it as an 'Experimental' site as well? Perhaps an 'Art' site? I've heard categorization of the awards has been a problem in the past; trying to lump a large enough site into one category is no easy task.

And if you go to the panel grid, you'll see a ton of panels it will be hard to choose from, and a very impressive roster of panelists running down the right. Somehow, some way, I've managed to work myself onto that list (which will update any time now...), but I think I'll leave precisely what and who I'll be presenting with a surprise for now. It's going to be a good one, provided I'm not completely overwhelmed by the amount of very cool people I'll be meeting for the first time.

More coming as more develops. Three and a half months isn't looking that far off.

Permalink › | 4 comments

CSS Crib Sheet?

November 19

Alright you Nielsenites you, that didn't go quite like I expected. It's probably my fault for calling it 'Best Practices' in the first place—what we're looking to create is more a crib sheet of practical advice, something for reference when a designer gets stuck while using CSS specifically.

"A lot of these 'best practices' are just arbitary favouritism for a particular way of working." - jgraham

I'd tend to agree. While nobody wants a blue, underlined link world, and we'll be debating for ages the best way to size fonts, this is what I was getting at: "a CSS Best Practice is a one sentence action statement, a 'thou shalt' or 'thou shalt not' (paraphrased, of course) that highlights a specific issue, be it browser compatibility, code integrity, or whatever else can actually be considered factual (instead of opinion)."

Take a look at my original four examples again—the point is to specifically address things we've learned about CSS after working with it for years, that may not be covered in the spec, or pop up when validating. Things like browser compatibility, code integr... you get the idea.

After sifting through the comments, here's an updated version of my original list. Feel free to add more in the comments, but consider the focus.

When in doubt, validate.
When debugging, you may save yourself a lot of headache by simply validating your code first. Improperly-formed XHTML/CSS will cause many a layout glitch.
Make sure your desired effect actually exists.
There are browser-specific CSS extensions that aren't in the official spec. If you're trying to apply filters or scrollbar formatting, you're working with proprietary code that won't work in anything but IE. If the validator tells you the code you're using isn't defined, chances are it's proprietary, and won't work consistently across browsers.
Avoid the Flash of Unstyled Content in IE.
If you rely on @import alone for external style, sooner or later you'll notice IE 'flashes' plain, unformatted HTML briefly before applying CSS. This can be avoided.
Be careful when styling links if you're using anchors.
If you use a classic anchor in your code (<a name="anchor">) you'll notice it picks up :hover and :active pseudo-classes. To avoid this, you'll need to either use id for anchors instead, or style with a slightly more arcane syntax: :link:hover, :link:active
Specify units for non-zero values.
CSS requires you to specify units on all quantities such as fonts, margins and sizes. The behaviour of particular browsers when no sizes are specified should not be relied upon. Zero is zero, however, be it px, em, or anything else. No units are necessary. Example: padding: 0 2px 0 1em;
Test embedded; launch imported.
If you work with a stylesheet embedded in your HTML source, you eliminate any potential caching errors while testing. This is very important when working with Safari, among others. But make sure to move your CSS to an external file, imported with @import or <link> before launching.
Test different font sizes.
Advanced browsers like Mozilla and Opera allow you to resize text no matter which unit you use. Some users will definitely have a larger or smaller default than you; try to accomodate as large a range as possible.
Remember "LoVe/HAte" linking.
When specifying link pseudo-classes, always do so in this order: Link, Visited, Hover, Active. Any other order won't work consistently.
Build and test your CSS in the most advanced browser available before testing in others, not after.
If you build a site testing in a broken browser, your code begins relying on the broken rendering of that browser. When it comes time to test in a more standards-compliant browser, you will be frustrated when that browser renders it improperly. Instead, start from perfection and then hack for the less able browsers. Your code will be more standards-compliant from the start, and you won’t have to hack as much to support other browsers. Today, this means Mozilla, Safari, or Opera.
Don’t use quotation marks around paths/URLs.
When setting a background image, or loading in an imported file, resist the urge to surround the path with quote marks. They’re not necessary, and IE5/Mac will choke.
Try to avoid applying padding/borders and a fixed width to an element.
IE5 gets the box model wrong, which really makes a mess of things. There are ways around this, but it’s best to side-step the issue by applying the padding to the parent element instead of the child that gets a fixed-width.
Combine selectors.
Keeping your CSS light is important to minimize download times; as much as possible, group selectors, rely on inheritance, and reduce redundancy by using shorthand.

As well, there were some notable theory items that don't particularily apply to the functionality side of things, but probably should be mentioned:

Organize your CSS file
Make sure to comment blocks of CSS appropriately, group like-selectors, and establish a consistent naming convention, white space formatting (recommendation: spaces instead of tabs for cross-platform considerations), and property order.
Name classes/IDs based on function, not appearance.
If you create a .smallblue class, and later get a request to change the text to large and red, the class stops making any form of sense. Instead use descriptive classes like .copyright and .pullquote.
Consider accessibility when using image replacement
Classic FIR has known problems in screenreaders, and for those who have turned off images. Alternatives exist; use discriminately.

And finally, there were a few points I want clarification on before adding: is using a number at the beginning of an ID just invalid, or does it actually cause rendering problems? And this one—"Avoid horizontal margins and padding on floated elements, IE tends to render them incorrectly"—yeah? Sounds right based on experience, but I don't have supporting documentation on hand.

Permalink › | 46 comments

CSS Best Practices

November 17

I've been thinking about how to put this together for a while, so I think I'll open it up to everyone for contributions, then build an actual resource out of it somehow.

Here's the idea: a CSS Best Practice is a one sentence action statement, a "thou shalt" or "thou shalt not" (paraphrased, of course) that highlights a specific issue, be it browser compatibility, code integrity, or whatever else can actually be considered factual (instead of opinion). It's followed by a paragraph that goes more in depth about why or why not someone would want to follow the action, with links to further reading. This is the stuff that, if you know it ahead of time, makes your design process much less of a headache.

The final resource would be a single-page collection of learned knowledge that might otherwise be spread out too much to be useful. Consider it a crib sheet for designing with CSS, one page that's full of valuable guidelines.

Here are some of the ones I've started with:

Build and test your CSS in the most advanced browser available before testing in others, not after.
If you build a site testing in a broken browser, your code begins relying on the broken rendering of that browser. When it comes time to test in a more standards-compliant browser, you will be frustrated when that browser renders it improperly. Instead, start from perfection and then hack for the less able browsers. Your code will be more standards-compliant from the start, and you won't have to hack as much to support other browsers. Today, this means Mozilla, Safari, or Opera.
Don't use quotation marks around paths/URLs.
When setting a background image, or loading in an imported file, resist the urge to surround the path with quote marks. They're not necessary, and IE5/Mac will choke.
Try to avoid applying padding/borders and a fixed width to an element.
IE5 gets the box model wrong, which really makes a mess of things. There are ways around this, but it's best to side-step the issue by applying the padding to the parent element instead of the child that gets a fixed-width.
Combine selectors.
Keeping your CSS light is important to minimize download times; as much as possible, group selectors, rely on inheritance, and reduce redundancy by using shorthand.

That's just a start. There are a ton at the back of my mind, but I'm having trouble fishing them out. This is one of those instances where you need to be doing it at the time to remember all the specifics. Add your own in the comments.

Permalink › | 62 comments

Methodology

November 14

From an e-mail exchange last night:

I think there's an important relationship here: if content is the focus (as it should be), usability means structuring that content appropriately.

Structuring that content appropriately means designing it properly, but you can't design until the content is in front of you.

Once you've designed it, it's easy to look at the comp and figure out how to break down the content into structured markup (or, it is for me these days anyway—I build XHTML before I touch CSS). And then once the markup is done, you style it with CSS.

Really, in the end, CSS is the last step in the chain, and the least important. BUT. You have to consider it as early as the structuring.

If you can't build it, well then you can't design it. So even though CSS is the least important step, it's still absolutely critical to the design process as a whole.

It's the designer's job to know the strengths and limitations of the technology, and how to make best use of it. That is why CSS is important to the designer; no more, no less.

Permalink › | 21 comments

Remember

November 11

Priorities

November 10

Necessity forced the abandonment of software solutions in favour of hardware; a router got bought. A router with sticky-uppy thingies, to be more precise. Yes, we have discovered 802.11 (wireless) and oh is it good. Sitting on the couch with an Airport-enabled iBook (which is increasingly becoming the weapon of choice chez Shea) and a good pair of headphones tuning in to a radio station from a timezone a whole day removed while writing one's latest tome on Cascading-something-or-other is a most agreeable way to spend a Sunday afternoon.

Increasingly I find the weekends, prior reserved for the catching up I swear I'd do mid-week, are becoming more about the exploring of new and just getting-the-hell-off-the-screen. Sitting in a coffee shop without wireless and playing an old-fashioned game of Scrabble one November afternoon while sipping the new festive specialties feels right. Putting ten or fifteen kilometers on the old rubber soles and trying out new sushi restaurants and pizza joints means spending that time doing things off-line instead of on-. Taking these precious two days a week to keep life in check, meet new people, and try new things breaks up the otherwise routine.

And that's what it's about really, finding balance and figuring out what matters once you strip away the distraction. Sure, I saw that movie and built a wireless network this weekend. But I'm far more satisfied after stewing a largeish pot of soup (using frozen stock leftover from Canadian Thanksgiving), meeting up with Matt H. over lager, discovering a new organic produce grocer, enjoying my wife's company, and all the other little things that made it far more interesting than the five days preceding.

What did you do —offline—this weekend?

Permalink › | 38 comments

Retrospective

November 8

A year already? A year. Already.

I keep stopping myself from writing over-detailed summaries about how I created other similar sites before this one going back to 1997, and how this one has really been around since 2001, but the weblog and the 'official' birth of mezzoblue happened a year ago. Too tedious for anyone but me though.

So to try (and fail) to avoid a self-indulgent narcissism-fest, here's a simple month-by-month summary of the year you've been with me, and we'll leave it at that.

November — The revised mezzoblue.com launched after some downtime. No one noticed. For the record, you might have visited a month prior.

December — Not much happened.

January — Not much happened.

February — I re-designed to a code-heavy version of the design you're currently viewing. More or less.

March — The Hack Hotbot saga began. I managed to get approval to enter as a Canadian citizen, win, but get shot down despite it all. Still bitter. I like iPods.

April — Frustrated by the difficulties of Hacking Hotbot, I brushed off an idea I started building in 2002, and spent most of the month putting it together.

May — And then it launched.

June — And then I got married.

July — And honeymooned. Then got back and proceeded to document a few ideas that seemed important.

August — Kicked off a new idea which never defined a schedule other than "infrequent". It ain't dead yet.

September — Garden rip-offs escalate. Didn't know what to do. Eventually figured it out.

October — Mozilla. WaSP. Sexy menus.

November — And here we are. It has been a good year, to say the least.

Permalink › | 15 comments

IE x 3!

November 6
thumbnail of screenshot of IE5 in action

Ethan, excellent find! The big news for today is that it is possible to get multiple versions of Internet Explorer running on a single Windows box.

Joe Maddalone has written up the process in detail, and while there could be a couple of tweaks to make it easier to understand, I was able to follow it and verify that, yes indeed, IE5.01, 5.5 and 6.0 can all run on the same computer. Here's my screenshot of IE5.01 in action on an XP box normally running IE6.0.

Great thinking Jon, this is exactly what we need! Now the question is, as Matt Haughey puts it, what possible explanation would keep them from releasing the simple info and making developers the world over happier to use MS products? I'm hoping to get an answer. Stay tuned.

update: Luke Redpath has put together a great set of colour-coded icons for the various IE installs.

Permalink › | 42 comments

Plugging the RSS Usability Hole

November 5
xml button

It's been said before, but it's worth repeating: direct links to syndication feeds, be they buttons or text, present a problem for end users:

I am not a technically proficient user. I don't know what XML, RSS, or even HTML stand for. I think the internet is the web, and the web is the internet. I still haven't figured out that I can dial up without having to click on the blue 'E' first.

When I see an orange button, I wonder what it does. I push it. A bunch of garbage text fills my screen, so I assume the button is broken. I don't push the useless button again, and resent it being there.

This is 90% of your viewing audience. Even if you have a core of more educated, technically-inclined users, you're still creating confusion. My first (and second, and many subsequent) exposures to the links caused momentary doubt. Why would I be seeing raw XML? What broke here, me or them? What is this XML good for, anyway? It took a long while before I managed to put the pieces together, and realize that it symbolizes something called RSS (which is inexplicably labelled 'XML', about as useful as labelling a desklamp 'Wires and Glass').

The worst part is how avoidable this confusion is. A simple page explaining the feeds is all it takes. This site has been using an explanatory page that lists associated feeds for ages. Simple, but necessary.

Still, in the interest of pushing the bar, I've taken to some further experimentation. Others like Sam and Anne have been playing around with CSS and various syndication formats. While I'm completely out of my element here, I've managed to take Anne's lead and use a touch of XSL mixed with CSS to actually do something useful with an experimental feed.

Since I believe the XSL must be parsed client-side (so that the RSS can actually be used as RSS, rather than XHTML), this will most likely only work in Gecko-based browsers for the time being. The layout is a simpler version of this site's current layout; it could go further, and using XSL I could theoretically duplicate everything from the sidebar to the fancy new CSS-based menus. But that's a lot of work just to create what already exists.

The key to the whole thing is a text explanation in the sidebar:

This is an RSS feed.

So what's RSS, you may ask? It's a technology that notifies you when a site is updated, and allows you to read the updated content without viewing the site itself. Think of it like a mailing list for web sites. More reading is available on this site's RSS resource page.

By styling and providing a reason for this page's existence, hopefully users will be provided an answer before the question is asked.

Most browsers won't be able to render this, so it's not much more than a theoretical glimpse at what could be. The main point in this exercise is the information page, which does help solve the problem now instead of later. But with better browser support, it should be possible to go even further and do something about the raw code dump as well.

Permalink › | 65 comments

Fog Creek Software

November 3

It's site launch day again!

Fog Creek logo

Today's redesign is Fog Creek Software, purveyors of the popular CityDesk web publishing system and FogBugz bug database software. You've probably heard of Fog Creek's founder, Joel Spolsky, via his popular weblog, Joel on Software.

My role was providing three custom CSS-driven templates for the various sections, built from the ground up to validate as XHTML Strict. Fog Creek was able to take the templates, plug them into CityDesk (which is coming along very nicely as a standards-compliant content management system, by the way), and customize the layout and content as was deemed necessary.

No, most pages don't validate, and you'll even find the odd table within the content. But Fog Creek should be commended for their forward-thinking approach to building web sites, echoed in both their products and on their company site.

Permalink › | no comments