Ever need a character code for that one goofy character you have to stick in your HTML? TnTLuoma.com has one of the most-comprehensive character code lists I’ve ever seen (and I’ve seen a lot of them). I keep this one bookmarked at all times.

While on this topic, here are a couple tips for when and how to use character codes:

• If you’re building an email, always use a character code and make sure to substitute character codes for non-standard characters when pasting from a Word Doc. Read that last part again. You cannot paste from a Word Doc into an HTML file and expect it to work. MS uses special, decorated qutoes and apostrophes that wind up (most often) as ? in your HTML code.
• Use the numerical code equivalent, because textual code equivalents are not always supported. While numerical codes are not guaranteed support, they are better-supported than their textual equivalents (and every textual code’s numerical equivalent is supported while the reverse is not true).
• Always preview your HTML when it contains character codes. It’s very easy to forget that last ;, the code istelf might not work, and these items look better and different font sizes (generally a larger size than your document’s base font). Preview, preview, preview!

technorati tags:html character codes, ascii, ascii codes, html, web development

QuickRef.org uses "active search" to give you very quick access to documentation on all kinds of programming languages. Type in a method name, language, or object, and, odds are, you’ll get very fast results that document what you’re looking for. QuickRef’s archive is drawn entirely from free documentation; most of it comes from the actual "official" doc.

QuickRef does its job well: it gives you fast access to information. However, it also does its job well because it uses a UI that supports the user and the search process; it’s a very user-centered design. From a graphic design perspective, there’s not much there: it’s a giant search bar. But, this is what it should be: the user’s primary focus is searching, so give them - what else? - a giant search bar. That’s good (user-centered) design.

But, there are a few other very solid UI gems that help give QuickRef a delightful user experience. QuickRef’s search results are color-coded by topic. This speeds visual browsing, helping users easily jump to and select the information they’re looking for. Is color the best choice? Probably, even though it’s not fully visually accessible. However, it ultimately helps users by promoting "browseability".

QuickRef also makes use of AJAX where it’s actually needed and does a lot of good. QuickRef allows users to minimize search results in little "windows" like a desktop app. Think of the benefit for the user: odds are, you’re going to be working on that project for which you’re tracking down information on the DOM for more than just one visit; persisting the results gives a huge benefit for the user. It’s something not often seen: AJAX for more than AJAX’s sake; it’s Web 2.0 building an intiuitive feature that’s beneficial to the user. In all, keeping those results around is a great use of technology that’s a big help.

QuickRef looks like it could be a very good user-centered resource.

technorati tags:quickref, user-centered design, user focus, ajax, reference

Blogged with Flock

Here’s a kind of annoying one. If you’re doing development on forms, odds are at some point in time you’re going to want to pre-select a radio button. Doing that is simple:
<input type=”radio” name=”myButton” value=”myValue” selected=”selected”>

So, you add that to a form element, and, like any good developer, you’re using FireFox to test as it’s more accurate rendering engine means you can develop compliant pages. Of course, your radio button remains unchecked. You can refresh as much as you want while tinkering with your code, but it probably won’t ever change. Why? FireFox caches radio button selections basically forever. The only way to get a true look at radio button values is to perform a hard refresh (CTRL+SHIFT+F5 on the PC). Now your box is selected, as it should be.

That’s the Golden Rule for FireFox Form Development: always make sure your cache is clear with CTRL+SHIFT+Refresh.

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

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 &nbsp; to you div. Voila! There’s the one-pixel-high line, just like you envisioned.

As I posted yesterday, onpaste is Internet Explorer’s handler for detecting a user’s pasting into a textarea or input. However, Internet Explorer seems to fire onpaste before the actual paste of text occurs in some circumstances, which makes the whole event irrelevant. Luckily, there’s a quick fix: make onpaste run your function on a timeout.

Here’s a quick example:

function iePasteDelay(){
setTimeout(’pasteIt()’,1)
}
function pasteIt(){
// your paste function
}

and in the code…

That one millisecond delay is enough to force Internet Explorer to run your function after the actual text has been pasted. Problem solved.

Running events when a user types into a form is easy. Determining when a user has pasted into the form is a little more difficult. When a user types, onkeyup, onkeydown, and onkeypress are fired, giving you ample time to fire your own event. But, what happens if a user pastes into your textarea, input, or other textfield?

Well, if the user does the old CTRL+V paste, you’re covered: the key events fire. However, if they do the old right-click paste, your need a new handle. Don’t worry, though, Internet Explorer and FireFox (Mozilla) both provide us with event hooks we can use to catch a paste.

Internet Explorer (from 6.0 on down to the 5s) provides us with the aptly named onpaste event. onpaste does exactly what you’d think it would do: fire right when the paste finishes.

FireFox also provides an event hook for text field pastes, and it’s called oninput. oninput fires right when paste finishes, too.

Now, how would we cover all our bases, both keypresses and pastes? We using the following events: onkeyup, onkeydown, onpaste, and oninput. Let’s say we’re building a character counter function; by runinning (and re-running) our counter function on all these actions, we’re covered in any and all cases.

Here’s how our character counter would look when applied to a textarea (I’ll leave the actual counter implementation to you, and sorry for the oddly formatting code snippet):

<textarea onkeyup="countCharacters()"
  onkeypress="countCharacters()" oninput="countCharacters()"
  onpaste="countCharacters()">
</textarea>

Our events now fire in all the right places.

A simple javascript makes for an easy way to grab the value from an HTML select input box. Need to access the value dynamically? Give the select box an id, and use the following script:

function getSelectValue(objId){

  var selectObj = document.getElementById(objId);
  return (selectObj.options[selectObj.selectedIndex].value);
}

Two lines and done. You can even do an all-in-one return statement like so:

return (document.getElementById(objId).options[document.getElementById(objId).selectedIndex].value)

Easy enough.

What exactly are we doing? Well, we’re indexing the select box’s options array with the array index of whichever option is selected, then grabbing the value associated with it. Quick and easy indeed.

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.