Contrast comparisons

A color of rgb(100, 100, 100) on black has a luminosity contrast ratio of 3.550595556268441, falling short of both Level 2 and Level 3. When enhancing contrast and having such similar colors, it actually lessens the readability.

A color of rgb(150, 150, 150) on black has a luminosity contrast ratio of 7.2236099811596866, which meets Level 2, but falls short of Level 3. Enhancement at this level sharpens the letters more than increasing the contrast between the text and the background.

A color of rgb(200, 200, 200) on black has a luminosity contrast ratio of 12.719459678993227, which exceeds Level 2 and Level 3. Enhancement at this level also sharpens the letters.

Side note: I kind of wish I had found the Colour Contrast Analyser Firefox Extension before writing the "High Contrast Design" section of the chapter.

CSS3

I know we still have quite a bit of lobbying and pestering to go before IE7 version X supports even CSS2 in its entirety. That said, the Opera team has continually updated their progress in support for CSS3. Several browsers, at this point, have adapted rudimentary versions of CSS3 columns support, as well as transparency, shadows, and background manipulation.

The latest post on Opera's CSS3 support has some very promising aspects to it, considering that functionality such as alternating table row styles, special formatting of empty elements, all off the of-type rules, and many more have the potential to reduce the workload of designers and developers by quite a bit. I know that I, for one, have emulated most of those mentioned using extra markup, scripting, or both throughout the last few years...

JSON vs. XML vs. XHTML

I've come to the conclusion that, abstracted properly, I really don't have a preference as to which one you use. The book will stay as messaging transportation method agnostic as possible, only using one method over another when it makes the most sense for that particular use case1.

Server-side validation

The result should return in a format easily parsed by JavaScript in order to highlight problem areas and provide a little metadata (such as the answer to "did it pass?"). Though XHTML, technically can get parsed as XML, the JavaScript then relies heavily on the markup structure of the page itself, which can lead to Very Bad Things. For this usage, either JSON or XML would work much better, but which one I would leave completely up to you.

Content replacement

By content replacement, I mean swapping out a large block where it really doesn't matter as to the contents (ie. navigating blog posts or looking up a word in reference materials). This one doesn't really matter which way you go about it. Even just swapping innerHTML with the responseText would work fine if you really wanted to go that route.

General server-side to client-side communication (and vice-versa)

Same story as with server-side form validation: it really doesn't matter...unless you either need to squeeze every last bit of performance out of your application (go with JSON), or you need output easier to consume by 3rd party applications (go with XML).

As a personal preference, I generally stick with (but no longer get into religious arguments about) using XML for the following reasons, in no particular order:

• Easier to read when viewing the raw traffic
• Easier to use from other, non JavaScript tools (though JSON libraries exist almost everywhere now)
• I would rather use a transport method that, by default, does not have even the slightest chance of executing statements when parsed.
• Habit
• More portable, since many already-built applications need to keep the current language versions, many older installations of which do not yet have JSON libraries (which you can usually include, yes...but that gets into other issues)

The JSON vs. XML argument has gone on entirely too long for something that doesn't even really matter when it comes down to it. At this point, I might even implement some of the examples in a way that you can just change out the method you want to use and have it switch on the fly, since the architecture of the application that matters to the examples won't know or care how the data arrives or gets sent, anyway.

• 1 All of these cases assume the normal, necessary error checking and validation routines before actually inserting anything into the page itself.

Okay, I'll give you a hint

Since nobody exactly leapt at guessing the rendering engine, I'll provide a hint:

They1 appear in alphabetical order by browser name.

1IE6, IE7, Mozilla, Opera, and Safari

Guess the rendering engine

Given the following block of CSS, which rendering engine goes with which number?

p {
    clear: both;
    margin: 1em;
}
p:first-child:first-letter {
    display: block;
    float: left;
    font-size: 3em;
    font-style: italic;
    line-height: .7em;
    text-indent: .2em;
    text-shadow: 4px 4px 3px #000;
    width: 1em;
}

Hint: four rendering engines shown, but one has two versions represented, since they have drastically different CSS support.

P.S. Any graininess stems from image optimization rather than browser rendering.

From "What CSS and JavaScript have in Common"

Another excerpt from Chapter 2

An increasing amount of users use tools such as the NoScript Firefox extension in order to white-list sites the browser will allow to run JavaScript. This greatly increases the likelihood of users seeing what your Ajax-driven web application looks and behaves like without any scripting at all, let alone the XMLHttpRequest object.

This also applies on a less substantial, though more frequent level, as different browsers have varying degrees of support for CSS, JavaScript, and the DOM itself. As such, code will either need to branch for each different implementation of a layout or function in order to support each major browser, or it will need to degrade gracefully enough that the user should not even realize they have missed out on something unless they compare the interface in two browsers side by side.

Coding CSS and JavaScript unobtrusively not only makes it easier for the interface to degrade gracefully, it also encourages clearer lines between interface structure, design, and behavior. When keeping the markup clean of inline styles and scripts (including inline event listeners such as onclick or onsubmit), it rewards good coding practices by making maintenance easier and faster. It also means that redesigning an application can happen entirely in the stylesheets, as long as the JavaScript only references class names and element IDs. Likewise, re-architecting the client-side application does not need to impact the interface design or page structure as long as the structure, style, and scripting have sufficient decoupling to allow it.

Inline Image Replacement (warning: hack alert)

In the process of designing the UI for indicating user's progress in a tabbed form, I realized I needed inline image replacement in order to accomplish exactly what I needed. The pure CSS solution works in Mozilla, Safari, and Opera, and should work in IE7 with some tweaking. IE6 will only work with JavaScript in place to convince it of what it should do.

The hack comes in, since I have only tried this with one set of transparent PNGs and this will probably take a fair amount of pounding on before it can stand up to wide usage. It also (for now) requires a solid background color.

Nevertheless, IIR. Suggestions actively encouraged... So far it works transparently (no pun intended) with screen readers, though the replaced text does go missing without the image there.