Until now, I've just considered JSON to be the equivalent to regular JavaScript object literal notation. Jonathan Snook has now explained the difference. It turns out JSON is a bit more picky than regular object literals. Key names must be quoted, and you can only use double-quotes around keys and values. Also, functions are not allowed as values.

I gave an example of JSON some time ago that turns out to be wrong. I used single-quotes in my JSON example. I'll leave them there since the example works, but I just can't call it JSON.

If you're doing JSON-style coding by hand for your Ajax communications, you can get away with using any object literals. So why care if it fits the JSON standard? Well, there are parsers and tools out there which can work with the JSON format, and if you don't fit the standard, they might not work.

I have no idea why the designers of JSON didn't just make the standard flexible enough to handle single quotes and unquoted keys. It's also confusing that JSON stands for JavaScript Object Notation, and that Object Notation somehow means something different from the object literal notation in JavaScript. Great.

Moral of the story: it probably doesn't matter if you use the JSON standard until you have to interoperate with JSON tools or feel the need to offer your JSON data to the public. You should probably stop calling it JSON if you use single-quotes, though.

Usually when assigning class names, it's most natural to assign a different class name to each uniquely styled area of the page. Often, there are common words you'll want to use as class names in more than one spot on the page such as 'date', 'section', 'title', etc.

At first, it seems the solution is to make up unique class names like 'header-date' and 'comment-date' or 'side-section' and 'main-section.

Instead of doing this, you can just stick to using your simple 'date' and 'section' class names but refer to them in their context. For example, if your mark-up looks something like this:

<div class="side">
    <h2 class="title">Side Title</h2>
</div>

<div class="main">
    <h2 class="title">Main Title</h2>
</div>

Then you could define your CSS like so:

.side .title { font-size: 1.2em }
.main .title { font-size: 2em }

Even better, you can get rid of the unnecessary class names and just define styles onto elements within different sections of the page:

.side h2 { font-size: 1.2em }
.main h2 { font-size: 2em }

You also have the option of doing element-sensitive definitions. Perhaps an <h2> tag with a 'date' class can mean something different than an <h3> tag. Then, just do this:

h2.date { color: blue; background: white }
h3.date { color: green; background: red; }

This is pretty simple stuff, but it opens up all sorts of possibilities for keeping your HTML as clean as possible. Just be careful not to get confused (or confuse others) by using the same class name for more than one purpose.

Welcome to the second edition of the Carnival of the Web.

To start things off, Emil Stenström at Friendly Bit brings up some good points with Current issues with Microformats.

John Oxton makes us web developers all feel a little bit better about ourselves with No I am not bloody sorry.

Rob Cherney follows up on John Oxton's post (and makes us feel even better) with A Bloody Good Developer.

Justin Palmer at EncyteMedia gives a different way of looking at design issues with Unconscious Interface Design.

Clay Mabbitt of Web Design Businesses Best Practices gives a nice guide to Pricing your web design service.

Joe Kissell at Interesting Thing of the Day gives us an introduction to Wikis.

Ohad's Internet News referees the battle of the giants with Google VS Microsoft.

Gerard at Interweb World wants to help you Perfect Your WordPress Title Tags.

George Papp at the Website Auction Hub answers the question How can I monetize my forum and start making money with it?.

Daniel Scocco of Innovation Zen outlines the top 5 trends of Marketing Under the Information Age.

And finally, Daniel Swiecki wonders what comes after Web 2.0 by asking How Much Rounder Can Corners Get?.

I hate to do posts like "Sorry I haven't posted in so long" or "I won't be posting for the next while" but... I won't be posting for the next while. I'm leaving tomorrow morning to go back to visit Canada for three weeks, and chances are I'll be pretty busy. But don't worry—I'll be back just in time to do Carnival of the Web #2. See ya!

There seems to be a trend towards using floating layers instead of popup windows. Floating layers (sometimes called "Div Popups" or "Floating Divs") are just HTML elements, such as a divs, styled to sit on top of the rest of the page. It's basically like a real window, and usually they are designed with an X in the top-right corner to let the user close the "window" (i.e. hide the layer).

There are some things to consider when deciding to use floating layers:

1. Popup blockers don't block them
2. People have to look at them at least to figure out how to close them
3. If the user clicks a link on the page, the floating layer disappears with the rest of the page
4. JavaScript is required to close them, but not necessarily to display them (popup windows require JavaScript for both)
5. They will never look or act like real windows on every computer
6. There is usually no way to minimize or resize them, or to switch back and forth between windows

If you think about it, each of these points could be a positive or negative. If you're displaying advertising, you'll be glad to sneak around popup blockers and force people to look at the thing. If you're designing a user interface, you might want to let people minimize, move and resize the popup window so they can see what is behind it.

From a usability perspective, floating layers are a bad idea. You have to design a way to close them, maybe even to move them around. But however you design them, they won't match everybody's desktop. Sure, you can design them to match the default Windows XP theme, but they will stick out like a sore thumb on Mac OSX. By using floating layers, you make people have to stop and think and figure out how to close the thing, whereas they would automatically know how to close a regular popup window without thinking.

There is already a very easy way to make a window that fits in with the rest of the operating system that can easily be moved, resized, minimized, maximized. Unless you have a strong need to use a floating layer, you might as well stick with window.open.