Skip to: Navigation | Content | Sidebar | Footer

Full Archives

IE7 CSS Updates

July 28

The first IE7 Beta is out. Yes, there are CSS improvements. No, they're not going to change the world.

Yesterday, Microsoft released a beta of the forthcoming Vista operating system, along with the first beta of IE7. Unfortunately, both are only available to MSDN subscribers.

An XP-compatible version is available from a third party if you have a BitTorrent client. This is probably breaking all sorts of terms and conditions though, and likely won't last. Grab it while you can. (Update: Upon further investigation, the site in question is a BitTorrent tracking site with links to all sorts of other copyrighted material. Since an XP-compatible version of the beta wasn't announced, I'm guessing it's probably not a good idea for me to recommend that anyone download it. So, don't.) My review is based on this version, so if there are significant differences between it and the version that comes with Vista, then this review may be inaccurate.

The first thing you'll notice upon installing is that it completely replaces IE6, which has been typical IE behaviour since, well, forever. Hence the classic problem of testing multiple versions on one system, until Joe Maddalone came along two years ago and solved the problem for us. Now we need to add a new version to the list of IE archives... for the time being, you can grab the IE6 Eolas Edition which isn't functionally different from regular IE6 (except for the annoying 'Click Here to Continue Loading this page' dialogues) and it will work as expected alongside IE7b1 and your older archives.

Functionally, we should all know by now that things like enhanced security, RSS support, and tabs are included. Here's a screenshot of how it came together, which through its incompleteness re-enforces the fact that this is just a beta. What's that blank button next to the tab? Clicking on it opens a new tab. Can anyone spare an icon? (My guess is that this looks a little better in Vista...)

The odd new toolbar layout with dominant back and forward buttons seems to be a new direction for the UI; the only customizable items appear to be the address bar, buttons, and links panels at the bottom, and they cannot be moved higher up within the toolbar. (IE6, in comparison, lets you remix to your heart's content.)

So what about the rendering? Things have changed, but obviously we were promised only very little for a reason—nothing much has been fixed. Yes, now we have PNG transparency. (compare Panic's Audion Faces page in IE6 and IE7) Yes, the Peekaboo (IE6, IE7) and Guillotine (IE6, IE7, how the test case is supposed to look) bugs appear to have been addressed. Though without having had a chance to test either very comprehensively, I'll hold off on saying they've actually been fixed just yet.

Other than that? After running through Position Is Everything's "Explorer Exposed" omnibus, it seems to me that the list of outstanding IE bugs remains long. Line-height bug? Not fixed. Border chaos? Chaotic as ever. Italic overflows? Still buggy. Doubled float margin? Nope. 3px jog? Nuh-uh. Escaping floats? No way.


And what about previously unsupported CSS2 properties? Have we got :hover support on any element other than a yet? Sorry. What about selectors? Same as ever. Could we at least ask for a bit of position: fixed? Keep wishing.

Acid2? IE6. IE7. Not a single pixel has changed.

Yeah, after four years of suspense, all we get is an alpha channel. Sorry to be the bearer of bad news, but the IE team kept their mouths shut for a reason; they delivered what was promised, and nothing more. Here's to IE7.5, I guess...

Update: From the IE7 beta announcement post linked at the beginning of this article:

Our goal is to get feedback from this group, do a bunch more work around quality (performance, security, reliability, etc.) and some features (e.g. additional standards support beyond what’s in beta 1, additional functionality around tabs and RSS, etc.), and release Beta 2 much more broadly.

So, the IE team has committed to the final release of IE7 having improved CSS support over what was released in beta 1. Let's hope the improvement is substantial. (Thanks, Kevin)

Second Update: More from Molly on WaSP's role in IE development, what you can do to help, and a plea for patience.

Third Update: Oh good, I was hoping we'd get something like this. The IE team has responded to the IE7 Beta feedback with a roadmap of sorts, which clarifies that yes, contrary to the expectations of many, Beta 2 will see quite a bit more CSS support than the first beta.

Permalink › | 101 comments

JPG Quality

July 27

The age old choice between image quality and file size, thanks to our friend JPG.

One from the inbox this morning. I suppose it couldn't hurt to share my response here:

Let's say you've a JPEG file, a photo straight from your camera-phone, and its filesize is 32k. You open that file into Photoshop, don't make any changes to it, and then want to save it again (don't ask why, you just do). You're asked to choose a quality/compression level. You select one, and save your new image over the old one.

Now, my question is: how do you save the file so that it's not loosing any more detail to the JPEG compression algorithm, but at the same time you're not tripling the file size?

Short answer: you can't.

Because JPG is a lossy compression, no matter what you do with the settings, if you open up a file and re-save it as a JPG, you will lose image quality (whether you perceive it or not).

When you open a JPG, it's converted to the internal bitmapping model of the editor (we'll again assume Photoshop here) and converted to a full, uncompressed 24-bit image. From that point on it's lossless—aside from any quality degradation from the camera's original save—until the point when you save it again.

The JPG algorithm isn't reversible so nothing from the original save influences the new save, which is why you won't be able to achieve an identical file size or quality level. Instead, Photoshop recalculates the compression as if it's working on an uncompressed image, which it technically is. Therefore the results you get when saving are entirely dependent on Photoshop's JPG saving options.

The choice between a huge file size or better image quality is simply a consequence of using a lossy format. The only way to maintain the integrity of the image after the save is to choose a lossless format like PNG or TIF, but then your file sizes suffer. The only way to keep file size down is to drop the quality settings, but then your image suffers.

But hey, we've been dealing with that choice on the web for years now anyway.

Permalink › | 32 comments


July 25

Oh, the fun to be had with Unicode.

Unicode, for those still unfamiliar, is a universal character encoding standard, jointly developed by a consortium with dozens of corporate and individual members around the world. The Unicode character set currently tops out at over 70,000 characters, and contains character sets from around the world, in both modern and ancient forms.

A bit more background follows, and then some usage analysis. Interspersed throughout this article are various Unicode characters; it’s highly unlikely that your browser/OS knows what to do with all of them. So unless you're running Safari, click on any set to view an image-based equivalent (which is a screenshot of how they actually do render in Safari).

Pictographs and Icons: ☣ ✈ ☎ ☠ and

Although Unicode is meant for characters, the term 'character' appears to be used rather loosely. The scope of Unicode is quite broad:

Unicode covers all the characters for all the writing systems of the world, modern and ancient. It also includes technical symbols, punctuations, and many other characters used in writing text. The Unicode Standard is intended to support the needs of all types of users, whether in business or academia, using mainstream or minority scripts.

Ѭ ش

Intricate non-Latin characters: Ѭ ش だ ༃ and

If you've never opened a character selection utility, there are a whole bunch of goodies waiting to be discovered. Both Mac OS X and Windows have useful utilities that allow you to get at the extended characters you won't find on the average keyboard. Windows has the Character Map (All Programs ➝ Accessories ➝ System Tools ➝ Character Map) while OS X has the more functional and comprehensive Character Palette (System Preferences ➝ International ➝ Input Menu ➝ Character Palette). Both of these will enable you to browse around the higher Unicode characters that one normally can't get at directly from the average keyboard.

Strange decoration: ℄ ❣ ᴞ ℟ and

Given the current state of internationalization amongst modern operating systems and browsers, we're coming close to actually being able to use some of these advanced characters on the web. The issues are similar to those of specfying typefaces for a browser: the user's system must be able to render the character in question.

The biggest advantage I can see, aside from the obvious foreign language support, is the ability to include pictographs and icons within a document, without having to send an image over the wire. A little CSS styling means they can be set to any size, without consuming any more bandwidth, so the visual opportunities are promising.

Though, the biggest caveat is that any character you choose must have a representative glyph (the character pictograph itself) in the font you're displaying it with. It's unlikely that we'll ever be able to rely on a specific glyph/font combination being present on the computers of every user. It's also pretty much a given that the average typeface simply won't have glyphs for all 70,000+ characters, considering the work that goes into producing even a basic latin character set. We're lucky, though, that most of the standard web sets—Verdana, Georgia, Arial, etc.—have a larger number of glyphs designed than an average font (thank you, Microsoft).

Religious and symbolic glyphs: ☦ ☬ ☤ ☮ and

Browsers are not equal in their rendering, unfortunately. This article was composed while testing in Safari, and looks absolutely great. Any other browser, including Firefox, doesn't. I can't even begin to speculate why this is, as I had assumed Unicode character assignment occured on the operating system level. Suffice it to say, all browsers are not equal when it comes to rendering advanced Unicode characters.

Although it's probably easier and more reliable to embed these in an image for now, if you pay attention to the character sets and font combinations, it's possible to render them as text within a browser. Once you have a Unicode number (which you can find in your character viewer of choice) you've got enough to start playing. There are at least three ways to include them as character data, and likely more:

  1. As a literal character, copied and pasted into your markup from the character viewer. Make sure your site uses a Unicode encoding like UTF-8. (Although this is true for all three options in this list.)
  2. As an escaped character entity in your markup, using the &#xNNNN; format (for example, ) where NNNN is the Unicode number (can be less than 4 digits, e.g. ·) (Unicode Character Lookup)
  3. As generated content via your CSS, using the :before and :after pseudoselectors and the "\NNNN" format. (eg. li:before {content: "\203A";}

Vaguely meteorological glyphs: ☼ ☁ ☂ ✮ and

But it can be hit and miss since so many variables are involved. Still, the opportunity to experiment is there, and you may have noticed certain Unicode characters showing up in the wild—from the mundane © copyright symbols all over the web, to accents like John Gruber's stars on the Daring Fireball Linked List (they appear after each link).

It might be nice to have a reference sheet with a bunch of reliable cross-browser glyphs that work today, were anyone up to experimenting. Otherwise, consider all this a simple look at the possibilities of what we might get to play with in a few years, if all the major browsers play ball. I'll leave you with a couple of enhanced, gracefully-degrading generated content examples (screenshot here) to show how you might consider using these characters in a non-harmful way.

  • Mercury
  • Venus
  • Earth
  • Mars
  • Jupiter
  • Saturn
  • Uranus
  • Neptune
  • Pluto

The Road to Enlightenment

Littering a dark and dreary road lay the past relics of browser-specific tags, incompatible DOMs, and broken CSS support.

Update: It sounds like more than just Safari is doing justice to this page. As it's obviously not purely a browser issue, there are a number of reasons why your setup differs from mine, and why my copy of Firefox renders it differently than yours, which renders it differently than hers, which renders it... you get the idea. OS version, installed fonts, and international language options are all factors here. So, if you see this page as intended, great!

Permalink › | 37 comments

Book Link List

July 22

Got a copy of The Zen of CSS Design? Getting tired of typing in all the links we referenced? Good news — now you don’t have to, thanks to the book link list.

Since shortly after 'The Zen of CSS Design' hit the shelves this past February, a common request that keeps coming up is for a list of links to the designs referenced in the book. Well, now it finally exists, but I've gone one better.

Our writing process highlighted the need to pick and choose the topics we covered, leaving some material on the cutting room floor, so to speak. We came across a wealth of information while writing that we had no chance of including, so we did what any other self-respecting web author would do: we hyperlinked. Only, manually. So that left you, the reader, in the awkward position of having to type in these longish URIs to get at the information we wanted to share. Ugh? Ugh.

But we're done with that. I've spent the day compiling a list of all articles and books mentioned within the book, linked them, and annotated with page number of the original reference as well as corresponding descriptive text from the book. Now you have one page to remember, or you can just go to the Zen Garden All Designs page and find a link there from now on.

And while I was at it, I updated those that needed updating. Who knew that Bobby no longer existed? It was rebranded as 'WebXACT', a suite of tools from Watchfire... I must have missed that whenever it happened. And as any of the other links go offline, I'll do my best to find alternates and update the list accordingly.

Permalink › | 12 comments

Canadian Language Laws | July 14

Left: HP Officejet 5510 all-in-one

Right: HP Officejet 55100 tout-en-un

Yes, redundant sets of plastic interface plates, one for each language. The mind boggles.

View on Flickr › | 0 comments


July 11

Here's one for any fellow countrymen who intend to work with companies in the United States.

Live in Canada? Run a small web design studio or development business? Looking to work with a company based in the US? Got hit with IRS paperwork? There's good news.

First and foremost though, the legal stuff: I am not a lawyer, this can not be construed as legal advice, and I can't guarantee the accuracy of these statements. This is for informational purposes only. You'll want to consult with a lawyer who specializes in US tax law to analyze your own situation, as there are bound to be various specifics that need the attention of a professional. If printed, this article must be printed in its entirety and feature this notice.

As the owner of a small Canadian design studio, I frequently take on contracts with US-based businesses. The flow of money across the border is obviously important to the governments involved, as it's taxable income. I've consulted with US tax lawyers on this issue to make sure I'm on solid legal ground, and I'm simply passing on what I've been able to interpret about what I found out during these consultations. Again, it's simply my interpretation, not genuine legal advice. (Yes, it's tricky to know when to quit with the disclaimers...)

When initiating a new contract, the foreign company I'm working with usually passes along paperwork that needs to be completed before any payment can be issued. The larger the company, the more likely it is to happen. The paperwork usually consists of an IRS form W8-BEN (PDF link), along with any internal forms their accounting department requires. The latter are for the company's own records, and a necessary hoop to jump through. What interests us here is the W8-BEN. This is where it gets tricky.

The accounting department is usually working on the basis of local tax laws, whereas in your case, if you're working on Canadian soil, those laws may not apply. (The laws are different for Canadian citizens working on US soil, but I still have yet to figure out how THAT works.) The important point to note here is that the international US-Canada tax treaty supersedes any local law where there's overlap or potential conflict. Getting your hands on a copy, and then deciphering it, though, is no easy task. Again for information purposes only, here's an online version which may or may not be accurate. If you can find all the articles that apply to you, and then actually understand their implications, you'll be fine. Unfortunately, for pretty much all of us who didn't study law in school, doing so means hiring a lawyer.

Essentially, the Article relevant to the situation in which you and I find ourselves is Article VII. When working for hire, you're on the hook for paying taxes only to the country in which you reside. Sorry, that does mean your US income is taxable by the Canadian government just the same as any Canadian income, and you are responsible for filing your own return. But on the bright side, no, you don't have to pay tax on it twice. Canada has tax jurisdiction, and you are only accountable to the Canada Revenue Agency. (And if you have a GST number you probably know this already, but it's relevant to point out here that you shouldn't be charging GST when billing foreign companies.)

So what about the paperwork? You aren't required to do it. But that comes with a caveat: convincing the foreign accounting department of that may be difficult, if they don't have anyone on staff familiar with the tax treaty. This article may provide you with a bit of negotiating power when dealing with them. Though you don't need to, you may find it less burdensome simply to keep a completed W8-BEN on hand and send it in when requested, instead of arguing out the specifics every time. There's no real harm in doing so, other than the fact that a foreign government agency has a clear trail of your income. (And considering your clients will be reporting the payments, they probably do anyway.)

The W8-BEN does exist for a reason though; the case we've been looking at here depends on a few things:

  • You must reside in, and perform all services in Canada.
  • The compensation is received strictly for work for hire, and not for other services, or forms of royalties, capital gains, or other types of income.

In the case of other types of income (royalties became relevant to me last year, for example), the W8-BEN is a way to claim additional treaty benefits. In very few instances will you actually have to pay the IRS anything, but there are various other reasons why you may need to fill out the form to make sure a percentage of your income isn't withheld.

When a W8-BEN is required, unfortunately you first need to apply for a US taxpayer number, whether that's an Employer Identification Number (EIN) or an Individual Taxpayer Identification Number (ITIN). If you own a business, you have the ability to call the IRS directly and get an EIN for your business; expect the number to arrive by mail within a month. If you apply for an ITIN, the wait will take a lot longer and you must visit a US consulate (or visit the country itself) to have your application notarized by an approved US notary. Considering the narrow window the notary was available at my own local consulate (M,W,F, 1:30-4:30pm only) and the long wait for approval, I would highly recommend trying for an EIN first if at all possible.

I'll leave you with some parting advice. If you think you might find yourself in a situation where any of this advice is relevant, consult with a tax lawyer now. Bring a laptop or a notepad and write down everything you possibly can during that consultation. The time and effort you save will more than offset the few hundred dollars an hour; researching this information on your own will not be worth the effort, and misunderstandings can lead to litigation, even if they're honest mistakes.

Permalink › | 8 comments

Made for All of Us

July 5

Accessible design, unobtrusive scripting, and terrible cell phone browsers.

From all accounts, the recent @Media conference in London was a smash hit. One take-away that has appeared everywhere is a renewed interest in accessibility issues. Given the creation of the WaSP ATF and resulting discussion, the eye being kept on the under-development WCAG2, the interest in zoom layouts, and even the questioning of what we know, there's a lot going on right now.

At the moment, accessibility practices attempt to assist those with disabilities. This is a reasonable starting point. A founding goal of the web, after all, is to allow access to anyone, anywhere, at any time, on any device. It's going to take a lot of work to get there, but if you're looking for the ultimate definition of accessibility, that's it. Over the long term, the concept of accessibility must become this broader definition.

During the recent North American long weekend, I spent time out of town, sans computer. Accessing any web site on the cell phone I'm cursed with is an exercise in frustration, however I had time one afternoon to make a determined attempt to use various sites. Those built with standards worked. Those built with accessibility in mind worked well. Those built by developers stuck in 1997-era development habits were completely useless.

One site in particular stood out. This popular web application is relatively standards-friendly, although built with AJAX in mind. I could log in. I could view my data. But the nag message informing me I really should enable Javascript hinted at what I quickly discovered: without script enabled, I couldn't manipulate my data in any meaningful way. The developers had obviously tied the core functionality to the scripting, without providing a graceful degradation that would allow simple HTML form elements to get the job done.

As a normal user on a desktop browser, I observe no problems with this application. As a remote user without access to the same level of technology I'm accustomed to, I can't even use it. Solving this problem would mean employing methods to make the site work without CSS, without script, and essentially allow unstyled and unscripted HTML to accomplish the same task. Funny enough, doing so would likely boost the overall accessibility of the site as well, allowing users with assistive devices to accomplish the same goals in a similar fashion.

Of course, this isn't an easy thing to accomplish. Retrofitting an existing application is tough, and building the same thing twice isn't cost-effective. Those advocating unobtrusive javascript will likely suggest that you should ideally build your application without script at first, and enhance with script afterward. Unfortunately this will collide head-on with most development schedules and methodologies. A middle ground is needed, some process of maintaining graceful degradation throughout the development of a project.

So for me, the obvious take-away in all of this is that, by building sites and applications in an accessible manner, the payoff will extend beyond the immediately obvious. The question remaining is, how do we go about doing so? Though there are lingering doubts about the effects of CSS on assistive technologies, a properly-built site will degrade gracefully when CSS isn't rendered; there is clean-up work yet to do to solidify the particulars, but we have figured out that the separation of structure and presentation goes a long way to accomplishing this goal.

But what about scripting? The myth persists that Javascript is inaccessible, but it doesn't have to be. There is yet plenty of work to be done toward figuring out just how accessible it can be made, but I'm willing to wager that the separation of structure and behaviour will ultimately prove a healthy start. I've yet to read the books on this topic by Stuart Langridge (published 2005) and Jeremy Keith (coming soon), but I'll bet answers to my remaining questions start in there.

Permalink › | 19 comments