Ajaxian has a nice little thread on IE DOM toolbars. Originally meant as an intro for DOM Helper, it kind of evolved to incorporate a couple other toolbars. Sure, we all use the FireBug and Web Developer extensions for FireFox, but what do we use for IE?

I personally use Microsoft’s Developer Toolbar, which I was only fairly happy with, mostly due to it’s kind of unintuitive UI. (Yes, floating tooltips are easy to make in .NET applications. No, they are not good as the primary means to communicate data). The Ajaxian article finally prompted me to figure out how to modify the DOM in the IE toolbar (because, apparently, it’s always been possible if hidden). Click on (or otherwise select) an element, and use the middle pane to add and modify attributes.

I’ve been trying to use the right pane, which, to me, seems like it should work (but is apparently only meant to show your element’s current style, which is pretty valuable nonetheless). I especially like how the attribute names are a big, giant dropdown so that you can see them all. With that middle pane, IE’s toolbar is better then the Web Developer extension (more robust), yet still not as great as FireBug. Hopefully, it works in IE 7 right off the bat.

technorati tags:developer, toolbars, ajaxian

Though there is a CSS property vertical-align, it doesn’t work like attribute valign in HTML tables. CSS property vertical-align doesn’t seem to be able to solve this problem:

Plain and simple, the CSS veritical-align property really doesn’t work like it should. (Maybe it works to the spec, but it’s not intuitive.) It does not work like a <td>’s valign="middle" attribute, and odds are that’s the behavior you’re trying to emulate when you’re using vertical-align.

Aligning an element vertically within a container of a known height is pretty simple. You can:

• Give the to-be-aligned element margin-top,
• Give padding-top to the container, an sub-container in the larger container, or the to-be-aligned element,
• Use position:relative or position:absolute to slide the aligned element into its desired position.

All this is great. But, what happens when you’re trying to vertical-align against something with a dynamic height? Using vertical-align rarely works as planned, and won’t work if you’re using a block-level element. What do you do?

Vertical Centering in CSS is a solid technique that lets vertical alignment work like it should. I’ve got code using this method in production and, let me tell you, it works very well. Yes, it adds a little extra markup to your document and CSS, but it’s well worth it for the final effect: a vertically centered element without the usual headache. Follow that link and align freely!

technorati tags:vertical-align, css, html

Here’s a little CSS tip that a lot of people are unaware of: you can give an element as many CSS classes as you’d like by adding them to that element’s class attribute separated by spaces.

This is how it looks: <div class="big orange square">. Your div now belongs to three classes: big, orange, and square.

What about adding classes with a script? Just use element.className += ” classname” to add them (that’s space + classname). To subtract? Set element.className equal to a string without that element. You can do this by splicing that unwanted class out of a string, using a regular expression to filter it away, or using any other string manipulation. Just set element.className = to your new string. Voila.

technorati tags:css, classes, html, dhtml, javascript

I’ve been using Dojo’s FisheyeList widget (think of Mac OSX’s dock) in an internal app I’ve been
building for TheLadders.com. It’s a totally killer piece of script,
and works very well right out of the box. However, there’s not much (read: there’s no) documentation on using it. So, in the hope of
helping someone out, here’s what I’ve figured out so far. (I’m working on dojo version 0.31, and by no means is this list exhaustive).

• Using dynamic images: You can add list items (dojo-FisheyeListItems, to be exact) at run-time with JavaScript. Just document.write them into your dojo-FisheyeList container, and the widget will pick them up. This allows you to grab images dynamically with another script, and inject them into your list.
• What do the properties of the dojo-FisheyeList container actually do? This:
  • dojo:itemWidth - The width of the item in the "dock" before mouseover (in pixels).
  • dojo:itemHeight - The height of the item in the dock before mouseover (in pixels).
  • dojo:itemMaxWidth - The biggest possible width your image can have on full mouseover (in pixels).
  • dojo:itemMaxHeight - The biggest possible height your image can have on full mouseover (in pixels).
  • dojo:orientation - Either "horizontal" or "vertical".
  • dojo:effectUnits - The distance your mouse can be from the widget before it activates. Lower values mean your mouse must get closer to
    the widget strip before the icons puff up; higher values mean the widget activates at greater distances. Decimal values are OK.
  • dojo:attachEdge - Specifies which section of an icon triggers the "puff" effect. Can be "top", "bottom",
    "left", "right", or "middle". "middle" creates a really strange effect.
  • dojo:labelEdge - Specifies where the image’s label displays. "top" and "bottom" are the only choices here. If you
    enter anything other than those two, the widget defaults to "top".
  • You don’t need to add a label to your images. If you don’t add the "caption" attribute to a dojo-FisheyeListItem,
    the caption won’t display for that item.
  • dojo:enableCrappySvgSupport - I tried toggling this between quot;true" and "false", but really noticed no difference.
    I’ve been testing in IE 6.0 and FireFox 1.5, so perhaps this does something in an older (or different) browser?

In all, this widget gives you a great effect with a very quick installation. Does anyone else have any tips for using the FisheyeList?

technorati tags:dojo, javascript, dojo FisheyeList, dock, css, web development, dojo toolkit

As one working exclusively on CSS-based layouts (that’s it, a little markup and a lot of CSS) day in and day out, I readily admit that it’s a tough thing to learn to do and it’s not an easy thing to master. Ben Henick’s 12 Lessons for Those Afraid of CSS and Standards serves both levels by presenting ideas that the novice needs to know and the intermediate needs to master. I recommend clicking that link and reading the article, no matter what you’re level. I’ll provide some of my thoughts on the article below (I’ll even try to make them match his order).

1. CSS is a very functional language. You really should think of it as an object-oriented language powered by inheritance and contextual properties. This is confusing at first (why does my headline render differently in one column than another?) but immensely powerful (I can make my headline render two different ways in two different contexts).
2. Rendering engines cause rendering bugs that make perfect presentation of a design very difficult. It’s not impossible, though. Using tools like position, you can really measure and execute designs to the pixel.
3. Most people don’t understand the skill and time involved in battling browsers, especially when your company or project is firsting starting out down the CSS road. It takes a while – especially for a new CSS programmer – to figure these things out and learn how long "simple" tasks will take.
4. I’ve fallen into the div-soup trap before. Real CSS mastery occurs when you realize that you don’t need divs anymore, that you can do the same thing using all those "basic" html tags that you’ve long forgotten.

5. In many cases, the person responsible for a site’s graphic design is not responsible for any other aspects of site implementation. When paired with a failure to create strict site- and section-wide wireframes, this lack of accountability results in unique comps for too many pages, and thus a lot more work for the stylist and producers.

   Please, designers, create consistent designs. There’s no reason why your columns should vary by a few pixels here and there. There’s no reason why a site should have more than a few base templates. Designers can either expidite the build process or bottleneck it with their creations. And, believe me, I’ve designed and built. When I design with building in mind, my design works better with fewer compromises.

6. Tracking down browser bugs takes time, and it’s most often that crunch time when a project is in its final phases. It’s a hectic thing.
7. The author left out one big benefit: really taking advantage of the cascade lets you do things, and change things, quickly. Want your left-hand links to be green? Tight CSS makes this a snap.
8. See #7. You don’t need all the markup that you think. This is a hard concept for novice programmers to grasp: their quickest action is to wrap everything in a div, style it, and walk away. I prefer to use divs as selectors, then use normal HTML markup as children of that selector. This makes stylesheets easy to read and easy to change. Plus, by using normal HTML markup, you can really improve that SEO, which everyone loves.
9. Without stylesheet hacks, your site won’t work. Plain and simple. Yes, /**/ is not valid CSS, but it works. Try to write code with standards and mind, but avoid blocking on standards. There are cases where you will need to eschew standards to get your work done. Don’t stay late looking for a "standards-compliant fix" when you won’t find one (believe me, I’ve looked), and the hack is the cleaner, easier way to go.
10. There’s nothing like writing a whole page, getting it into production, then seeing the "peak-a-boo" bug dropping off some text for no discernible reason. Or having blockquotes slowly shift your text off the screen. Or having…
11. position:relative is usually the first thing I try when trying to fix an IE bug. line-height sometimes works, too.
12. A background image on an <h1&gt makes a lovely, accessible, SEO-friendly headline. Standard design templates let you use and reuse backgrounds. Reusting common elements means less new browser bugs, and shorter development cycle, and much happier developers.

You can tell I’ve been doing this for a while, eh?

technorati tags:css, learning css, front end development, design, web standards, web development, front-end, user interface development

Blogged with Flock

Looks like I’m getting a little pub. Well, indirectly. And, no, I’m not actually named in the article at all.

TheLadders.com Redefines the Art of the Job Search, and I wrote "the latest Web technologies" behind that redefinition. It’s really simple: CSS and JavaScript and DHTML. Hundreds of lines of each.

My Jobs is a slick bit of CSS, JavaScript, and DHTML, and has bits and pieces that spread across to other parts of the site, too. I feel like I’m at the cutting edge of Web 2.0. Now, if they’d just get a quote from me next time …

technorati tags:Web 2.0, TheLadders, DHTML, javascript, project

Blogged with Flock

The CSS background-color property makes things look nice and pretty. But, they don’t play well with margin in a block-based layout where the body tag’s background-color is different from your content’s background-color, especially when you’re using a liquid height layout.

Let’s say you’re stacking three divs on top of each other for a nice stack. That middle div has a background-color. Now, adding a block-level element with built-in margin (like a p or h1) to that middle div will cause a big huge band of color where the element’s enforced margin pushes down the block beneath it. (Is it a bug? Nope. Just doing what it’s supposed to.)

How in the heck to you get rid of that band of color? Simple: add something below that block-level or margin-enforcing element, or add padding to the block-level element’s container. The margin is enforced on the item below, which gets pushed down, but also stretches the container’s height, keeping the color in tact. Ditto with the padding: the padding forces a height on the container, keeping the background in tact and delightful.

Feel like playing with margins? Give a margin-bottom of 0 to that problem element. Or, give a margin-top of a negative value to the block that’s being pushed down (it’s roughly the line-height or specified font-size that’s in effect on the container).

There’s four simple, friendly ways to make margins play nice. The third is probably the cleaneast; the fourth the dirtiest (especially if another developer doesn’t see that negative margin, and wonders why blocks are overlapping after he’s made a change to the code). But, all do the job.

technorati tags:css, background-color, margin, html, liquid layouts

Everyone who’s everyone uses Firebug with FireFox to debug pages during web development. Firebug lets you get to the root of pretty much any problem you’ll come across. But what happens when you’re trying to make a page work in IE? It used to be like a black box … until now! (Now the box is like a light gray).

Internet Explorer Developer Toolbar Beta matches almost all Firebug functionality, while adding a few new, great things. In fact, IE dev toolbar combines the winning qualities of several of the top FireFox dev extensions into one package. Simply put: download this now to make debugging happier. Very quick install, and no need for a browser restart! (As an aside, if you ever want to wow one of your designer friends, whip out a screen ruler - one’s built in to the IE dev toolbar - when working with them on their design. Say, “nope, that’s correctly to the pixel.” They’ll peacefully go back to their Macs.)

technorati tags:development toolbar, ie, ie6, web development, web developer toolbar

Blogged with Flock

Here’s a great Internet Explorer bug that you might stumble on when working with javascript to dynamically insert images into the DOM. Apparently, Internet Explorer sometimes fails to render dynamically placed images. Microsoft even acknowledges the defect.

Microsoft does, however, provide some insight into what you can do to work around this browser flaw. Basically, you need to force the IE browser to run the insertion again. This is the basic idea:

• Give the browser an img tag without a src attribute to render while the document loads.
• After the document loads (such as during an onload function, or in whatever post-load function you need, use a setTimeout function to force the browser to render your image.

This may seem like quite a bit of overhead, but, in practice, it can be pretty simple. Here’s some example code:

if(navigator.appName.indexOf(’Internet Explorer’)!=-1){
document.body.removeChild(objImageContainer);
document.body.objImageContainer.childNodes[0].src = newImg.src;
setTimeout(’hackIe()’,10);
}
else {
// Regular old code
}function hackIe(){
document.body.appendChild(objImageContainer);
}

That should do it. According to Microsoft, this bug is do to the timing of when the browser attempts to render Document elements, so anything that disrupts this timing, like setTimeout or alert, will work to “fix” this bug. An extra function and browser sniff, but at least it’s a simple fix.

When writing a Web 2.0 app, function completes get to be pretty important. In fact, they’re the little signal that a function can send out to the larger program that says, “Hey, I’m done, now do something else”; callback like this is a pretty important thing.

Take the case of a web application that loads a list of items from an external source. Generally, most AJAX libraries, and even XHTTP request code that you roll on your own, gives you the opportunity to write a function that runs onsuccess. That’s great: when your code is done executing, bam!, your function runs. In most cases, that’s great. However, consider the case of a set of images loaded externally then inserted into the page dynamically: the images might be received from the server and stuck into the page, but they might not be fully rendered, depending on the environment.

I ran across this interesting little quirk while working on a Web 2.0 app using Flickr. I loaded a bunch of images from Flickr, dynamically built them and inserted them into my page, and, voila, they’d slowly render, dial-up modem style. Not optimal. I almost gave up until a quick Google showed me that, in face, Images Can “Call back,” too!

Thanks to evolt, I was able to come up with this little design pattern:

• In a for loop, iterate through an array of images to be added.
• For each iteration, dynamically build an image, using document.createElement(’img’), or your image object.
• At the end of each iteration, test to see if the current image is the last image in your array. If it is, assign your “all loaded” function to that image’s onload event handler. Otherwise, assign an arbitrary little callback function if you’d like.

Now, your function can learn when all images are loaded. Also, if you’d like more flexibility or interactivity, you can map each individual image’s event handler to a different function (say, update a progress bar with what image is being loaded, or show a progress percentage). All thanks to the image itself.