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

Roger Johansson, of 456 Berea St., found a strange little bug involving unitless line-heights in Mozilla and Firefox. This bug seems to have been squished in current releases of the Mozilla codebase and, oddly enough, everything appears to work correctly in Internet Explorer. There’s a rare one.

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

IE seems to have a rendering bug (!) that causes it to incorrectly render the height of any div that has no text in it, no matter where you place it, or even if you’ve declared any kind of line-height at all in your document (and fall back on the browser default of about 1.2em).

Let’s say you want to use a div to display a background-color only (yes, I know a hr should be used properly here, but then I’d have to mess with margin; absolutely positioning a div is a little easier as its shorter CSS-wise). The below CSS will render a giant div, set to about the line-height of its parent (or the browser default):

 div.aLine{
 width:400px;
 height:1px;
 line-height:1px;
 background-color:black;
}

Yep, perfectly valid code. One would think that would create a one-pixel-high black line. Nope: the line defaults to the line-height of its parent (or the body, or, if no body line-height is set, the browser default). Very odd: one would think that with Internet Explorer’s famous height malfunctions and ability to scale height at will, it would work fine. Luckily, there’s a quick workaround: add a   to you div. Voila! There’s the one-pixel-high line, just like you envisioned.

position is a very useful CSS property that gives us very explicit control over where things should appear on the page.
position gives us the ability to move elements to the exact spot - to the pixel - that we’d like to see them. There are two
main types of position that we see most often: position:relative and position:absolute. I’ve created a quick rundown of how position:relative and position:absolute work in the field.

One of the trickier pieces of CSS positioning is figuring out how to position elements absolutely inside of other elements. Instead of using position:relative to slide an element around, then using things like negative margin or other tricks to reset the document layout, you can use position:absolute within a parent element with position:relative set, and you can get that layout you want without needing to reposition any other elements. Here’s a quick rundown:

• Create a parent element with a style property of position:relative
• Inside this parent container, place the element that you’d like to absolutely position along with all other elements. Basically, the larger parent will act as a container for all of the other children, or pieces of the layou
• Since elements are positioned according to their nearest parent element with position, your absolutely positioned element will move to the correct spot inside the larger container while not disrupting the flow of the others.

With position:relative, we can nudge things around, moving smaller elements, especially inline elements, wherever we like.

position:relative and position:absolute are two very important tricks for creating CSS-based layouts, and are especially useful when trying to replicate a mockup or comp design to the pixel. CSS positioning is an extremely useful way to realize even the most complicated layouts and is often a quick way to get layouts right.

I’m writing up a series of tutorials on CSS-based layouts. Why? Because making the transition from tables to divs and CSS can be difficult and there are often many little quirks that you only learn to conquer with practice.

In the first tutorial, I give a little intro to how block-level elements work and how people familiar with building presentations using tables can see block level elements in a familiar light.

The big question is probably “why the heck should I give up tables?” The web-politically correct answer is “because they’re meant only for presentation,” which is true. However, that doesn’t mean a whole lot in the real world. I’ll tell you personally that there are several reasons why using CSS-based layouts is easier:

• CSS is found in a single file, making for easy changes
• CSS-based layouts allow for multiple selectors acting on many different children, letting you
  create much more visually attractive (if not much, much more intricate) layouts and designs
• Extremely complicated table-based layouts become almost impossible to debug
• CSS-based layouts are usually much slimmer
• Tables are limiting; you can do just about anything with CSS

…and so forth. Table-based layouts are pretty quick and easy to throw together, but not much quicker and easier than CSS. When you add the time it takes to debug and change table-based layouts, and the ease of changing and freedom given by CSS (not everything has to fit in a row and a cell that’s in another row and cell that’s in another…), and it’s an easy battle.

Learn some block-level basics and start down the path of dropping tables for CSS.