Here at Wall St., we host some of the largest financial websites on the Internet. From The New York Times to E*TRADE and Barclays to Charles Schwab, our data centers serve content to millions and millions of users per week. It’s imperative our websites provide accurate market data, look good, are easy to use, and are fast. With so much information to relay, we’re pushing a lot of data (including scripts, CSS, images, etc.) through the pipe. So Nicole’s presentation was perfect fodder for our design and development teams.

A few highlights from her talk, with some links for your consumption follow.

• Nine best practices for designing and building faster websites:
  1. Create a component library of smart objects.
  2. Use consistent semantic styles.
  3. Design modules to be transparent on the inside.
  4. Optimize images and sprites.
  5. Avoid non-standard browser fonts.
  6. Use columns rather than rows.
  7. Choose your bling carefully.
  8. Be flexible.
  9. Learn to love grids.
• Watch her presentation on the YDN.
• PNG8 is the clear winner for images on any website. They’re smaller in file size than GIFs (I didn’t believe it until I saw it), and they support transparency in IE5.5 and IE6. No CSS filter hacks needed. If you’ve got a copy of Fireworks, you’re in business because Photoshop doesn’t help create PNG8′s transparency. If you don’t have Fireworks and are comfy with the command line, see this guide to making alpha transparency in PNG8.
• Embrace Smush.it — a web service and Firefox plugin created by Nicole and former co-worker Stoyan Stefanov. The tool allows web developers to upload images of any kind while Smush.it runs through a long list of compression algorithms stripping meta data and needless information from them before spitting them back to you in a Zip file. It all happens in seconds and a few tests we ran here — 15 images reduced in size by 320kb (99.18% compression rate) — yielded impressive results. Evidently, Smush.it is in the process of being adopted by Yahoo! which has immediately interrupted the service (but hopefully not permanently).
• Consider Object Oriented CSS, or OO CSS. Much of OO CSS is in the 9 best practices mentioned above. But it’s not what you think. It’s not object oriented in the traditional programming sense of the term. It’s object — as in a virtual thing: a module, a header, a sidebar bucket, etc. I had a hard time with this one in the beginning. Most of OO CSS is pure common sense — at least it is here at Wall St. Sit down, evaluate your designs before you start building, and determine a baseline for common elements across the site. Then piece together your CSS efficiently. Three really useful tips for page layout:
  1. Don’t use height-specific modules. Let the content determine the height. This is genius and must be recognized by designers. Vertical grids, not horizontal.
  2. If you have two or three modules with rounded corners that are different but look similar, just pick one and move on. “Users aren’t that sophisticated,” she said.
  3. Use grids to determine layout, and let the content fill 100% of the available space. This way two columns becomes three columns or becomes 6 columns and the content continues to just fit.
• Set aside a few minutes to watch her presentation on OO CSS. It’s not earth-shattering stuff, but she does make some interesting points that convinced us to approach web dev from a slightly different angle.

Thanks Nicole. Safe travels in India.

 -webkit-border-image

Launchpad HQ:

So for example, the image to the right is an original image from the iPhone. Its width is 29px. That breaks down to there being 14px on the left and right, defining the rounded corners and a 1px sliver which is the body of the button. So, in theory, if you were able to keep the left and right sides of the button stationary while expanding the 1px center piece, this would create a horizontally-scalable button with only one image.

But alas, how would we do this using only CSS? Well, I started digging around Safari’s ‘-webkit’ innards, and was able to to use the -webkit-border-image to accomplish exactly what I wanted.

This goes very nicely with the iPhone GUI PSD.

/* Rotates a leaf from -50 to 50 degrees in 2D space */
@-webkit-keyframes clockwiseSpin
{
/* Rotate a leaf by -50 degrees in 2D space at the start of the animation */
0% { -webkit-transform: rotate(-50deg); }
/* Rotate a leaf by 50 degrees in 2D space at the end of the animation */
100% { -webkit-transform: rotate(50deg); }
}

We’ll see this in IE29.

(via)

Until some future version of HTML gives us new native controls to use in a browser, at Google, we’ve been playing and experimenting with controls we call “custom buttons” in our apps (among other custom controls).

(via)

Enter stage left: Douglas Bowman’s Sliding Doors of CSS courtesy of ALA.

I added two tabs to my new view, repositioned them on the right side — which took some fancy footwork because this awesome technique only demonstrated the tabs as left-justified — and started the browser testing. With some minor edits to the CSS, my new tabs worked perfectly in almost uniform fashion, except in IE7. The browser correctly interpreted both of these declarations, including the Holly Hack (a.k.a. the Be Nice to Opera rule), previously undetected by IE.

#tabbednav ul { margin: 0; }
html>body #tabbednav ul { margin-bottom: -10px; }

A post on Zeldman.com helped me figure this one out, and allowed me to specify rules using a modified Holly Hack. This declaration targets Opera and Mozilla browsers, but all versions of IE don’t see it, including IE7:

html>/**/body #tabbednav ul { margin-bottom: -10px; }

Thanks to Zeldman and donovan.

Update @ nearly 4PM:
After further testing, Safari picks up my modified Holly Hack and improperly renders my tabs. I guess I’m going back to the drawing board.

Update @ just a bit before 4PM:
Ok, final update. I promise. In the end, I was able to make some modifications to one other rule and didn’t end up needing the negative margin. If anyone knows more about this “/**/” hack, ping me, I’m curious now.

If you have ever tried to send an (X)HTML email from your web apps, you and I both have a lot more to ask for.

I’m currently writing an application for a client of mine that’s rich in user interaction. In part, users can create accounts, verify email addresses, forget passwords, and more of the standard account-related functions. Needless to say, without any unnecessary overkill, we will be sending a good amount of emails to my client’s user base. I could have easily opted to send text-only messages, but the requirement included displaying a logo, bolding text, and other graphical presentations otherwise not available in text-only. So, without much hesitation, I charged ahead. Whip up some clean (and strict) XHTML, use loads of my already-fine-tuned CSS rules, pump in some content and we’re off!

Wrong. And this was just the beginning.

I use my Gmail account for testing — it’s convenient because all the messages get lumped into one conversation for easy review, not to mention the huge disk space and (my favorite) delete button closely within reach. But for all of Gmail’s successes, it sure wreaked havoc on my nicely-formatted XHTML messages. Evidently, Gmail strips every shred of code out of your email, and rebuilds it in its entirety before spitting it back into it’s wonderfully successful conversation view. Those unique div, span and other IDs? Gone. The short and sweet CSS rules? Gone, and definitely not working. Hell, even my one-line footer wrapped in a small tag didn’t render properly. I now know why I can’t read my itinerary confirmations from the airlines in Gmail.

To make sure I wasn’t out of my mind, I changed my testing email address to an account I manage with Outlook on Windows and Mail on the Mac. Naturally, the message came through looking as perfect as I could have ever imagined. I repeated this process with Mozilla’s Thunderbird and then webmail at Yahoo!, Hotmail, and AOL — all succeeded, but in different ways. Microsoft’s widely-used Outlook client performed the best (same goes for Outlook Web Access), followed closely by OS X’s Mail. Neither re-wrote my code. Yahoo! did better than Hotmail, but Hotmail’s new interface liked the HTML and CSS hybrid a little more than the old but it still wasn’t perfect.

I am fighting an in-browser application war! Here we have browser-based applications developed by the world’s largest software manufacturers performing the same basic functions displaying standard XHTML and CSS content from the same source — and it just doesn’t work. Grrr. In the end, it’s Gmail that is causing the biggest headaches.

Yesterday, I finished restructuring the code following tips I read about on this highly-useful Interweb (I love that old Verizon DSL commercial). Here are a few that helped me get going again:

• Don’t put anything in the head of your email template.
• Forget the love you have for your fine-tuned CSS document; there’s no hope of using it (as an externally linked file). You’ll have to drop all your classes and ids replacing them with hideous inline styles. If your email’s recipients use Gmail, you’ll need to do this one.
• If all else fails, especially with AOL, use a table to position your goodies. I can’t believe I typed that, but when it comes to this and saving time, it works.
• Have patience. I nearly tossed my lappie out the window on more than one occasion.

As of yesterday, my client’s customers are ready to receive fancy-schmancy emails. No matter which mail client, web-based or desktop, Mac or Windows, they’ll all see the same content — as it was intended by this designer. Now that it’s done and I’m filling out my time sheet, I find myself having a hard time justifying the large chunks of time spent formatting arbitrary (yet critical) emails when there’s plenty of other work that needs doing. It seems funny to me but after all these messages, like them or not, are part of your app and, more importantly, your client’s outward-facing marketing.

Visit Jude Healey Photography today.

Poor XSL
One of the reasons I’m discontent with the three biggies — Safari, IE7, and Firefox 2 — is their apparent blatant disregard for a designer’s freedom to exercise his or her right to a custom XSL—styled XML feed. I don’t normally spend too much time writing XSL documents, but for one client’s particular requirement, they wanted a custom XML feed page. The client’s user base, we anticipated, was not RSS-savvy and we’d hoped to ease them into the process for consuming news, regular updates, and more. So, enter a fairly simple XSL style sheet and the über—friendly appearance of styled XML. Not so in the latest versions of these browsers.

It’s possible that I haven’t yet found the setting in the browser preferences or the line of code that fixes it, but the aforementioned Big Three are overriding my XSL! (Opera handles the XML as intended.) They favor their own display of RSS feeds and bully mine out of the way. (See theirs. See mine.)

I’m not even going to try to explain why the software makers decided on this, so if you know of a fix, let me know.

So, take a few minutes and poke around. You’ll find articles written often daily, photography, details about my freelance work, and a list of some pretty amazing things. I hope you enjoy your stay, come back often, and feel free to comment on any articles.

Check out the article: Web accessibility soon mandatory in Europe? (from CNET News.com)