In-Box Twenty

Found in my in-box on this gloriously muggy morning:


  • E-mail from a neighborhood mom interested in hiring our child’s nanny in September, when the girl enters kindergarten. Would our nanny work part-time? (No, she would not.)
  • Invitation to speak.
  • Account status message from American Express, freezing my business account.
  • Personal letter from a co-author of CSS.
  • Correspondence from one half of a feud, demanding that A List Apart delete “libelous” comments made by the other half.
  • QA correspondence on Brighter Planet beta.
  • Photo of kid on general store porch-front rocking horse, sent by ex, from mini-vacation they’re taking together.
  • Responses from speakers selected to present at An Event Apart in 2010.
  • Discussion of “send to friend” links in context of COPPA compliance.
  • Raw personal truth from my dear sponsee.
  • Notes from a developer whose web fonts platform I’m beta testing.
  • Query from a mom whose friend is expecting: what do we pay our nanny? Would she take less? (I hope not.)
  • Basecamp notifications concerning Chapters 7, 9, 2, and 4 of Designing With Web Standards, 3rd Edition.
  • Invitation from a social media network’s director of strategic relationships.
  • Milestone reminder.
  • Note from my brother about the release of his CD.
  • Case study for review.
  • Notice of Credit Limit Reduction on my personal account from American Express. “In this difficult economic environment, we all need to make choices about how we spend and save.”
  • Discussions of Happy Cog new business activities in various stages of ripeness.
  • Note about a magic berry that will make me look like a princess.

Typical day.

Firefox test page

Firefox gurus, a page demonstrating the Firefox long content bug has been created for your browser fixing pleasure. Kindly visit the test page using Firefox 3.0 and Firefox 3.5 for Windows (and possibly also for Linux). The following defects should be evident:

  • At least half the comments should be cut off by the browser.
  • The footer should be cut off by the browser.
  • The form enabling you to add comments may also be cut off by the browser (or it may be incomplete, or the labels for such things as your name and email address may appear in the wrong location).

View the same page in Safari 3+, Opera 9+, or IE7/8, and compare. In the other browsers, all comments are displayed, the footer is displayed, and the content form is viewable and displays correctly. How often does Firefox compare unfavorably with some of these browsers? Hardly ever. Which is precisely why you want to fix it. (That, and you’d like your users to be able to view all the content on a page, not just some of the content.)

The test page is identical to this 2 July post, with comments frozen as of 9 July 2009, and with the site’s original CSS, which revealed the long content bug in Firefox.

A subsequent 8 July post documents the steps I and two other developers took in order to isolate this bug in Firefox, and the CSS workarounds (suggested by two of the site’s readers) which have since been put in place to cover up for this defect in Firefox. The thread also explains what we changed in the CSS to enable Firefox users to read long content on the site.

The CSS cover-up enables Firefox users to read all the content on long pages, but at a cost: there is a flash of red background during slow load times. And, obviously, it’s better to fix Firefox than to create somewhat flawed CSS workarounds that slightly diminish the experience for all users of the site.

Thanks for your help! Let me and this site’s readers know how we can assist you. And remember, please use the test page (not this page or any other page of the site) to isolate the bug in Firefox.

Read more

  • HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]firefox, browser, bug, firefox3, firefox3.5, windows, linux, bugs, buggery, debugging, demo, testpage, mozilla[/tags]

Firefox forces orange background flash

There’s good news and bad news. The good news is that Firefox 3.0 and 3.5 for Windows no longer cut long pages of this site in half, hiding 50% or more of the pages’ content, including the footer, because of a newly discovered bug in Firefox (discovered by this site’s layout).

The bad news is that the price of the “fix” is an annoying flash of reddish-orange background. When you first load a page in any browser, rather than the main content’s off-white background area, you instead see the text against a reddish-orange background, obscuring words (including the drop cap), disrupting user experience, and raising doubts about the professionalism of the site and thus of the opinions it expresses.

With the annoying flash of colored background, everyone who reads this site suffers. But without it, Firefox 3/3.5 cuts long pages in half. Until Firefox fixes the bug, all readers of this site will experience what I’ll label “the Flash of wrongly styled background color.” (Note: although the browser is still broken, the color flash has since been “fixed.” Impatient ones, skip ahead to the 9 July update. Narrative fans, keep reading.)

Here’s the story.

Validators were no help

My 2 July post, XHTML DOA WTF, has thus far received 194 comments. Firefox users told me the thread “died” after comment #44049 in Firefox 3 and 3.5 for Windows. The problem also later surfaced on In Defense of Web Developers, written yesterday morning just prior to my surgery. Let’s stick with the 2 July post, though, which is where we did our Q&A.

W3C and WDG validation services both indicated that there was an error on the page, but neither validator could explain it.

  • The W3C showed a long list of unclosed elements (which in fact were closed), a typical W3C validation error when that validator misidentifies the actual problem. The W3C validator has made this mistake since at least 2001. Whenever I complain to the W3C, I’m told they need volunteers to help them fix the validator. So I more often rely on the WDG validation service.
  • The WDG validator (usefully and apparently correctly) indicated that a single illegal UTF character in a comment it could not show me was causing the dilemma. This validator gave me a line number, but no code output—making the line number useless, and forcing me to go into my database and examine each of 194 comments visually for unsupported character problems.

In search of a single UTF-16 character

I next spent two hours of an insanely busy pre-surgery day unsuccessfully attempting to manually track down UTF errors in comments that no validation service was able to pointpoint. I had to apologize to colleagues and clients to whom I owed work, since the quest to make my personal site legible and usable to Firefox users took precedence over paying work in my sad little mind. (Call it a mark of the high esteem in which I hold Firefox; also call it a concern for readers.)

Automattic’s designer/developer (and my friend) Noel Jackson then took over for me and was eventually able to locate a single UTF error in a Japanese pingback. Or so it seemed.

WordPress, the power behind this site, is supposed to convert illegal UTF-16 to legal UTF-8, and we thought it had done so. Nevertheless, the only validation service to have claimed anything semi-coherent said otherwise. To solve the problem required brute force: we deleted the entire Japanese comment. To the clients and colleagues to whom I owed work I was unable to finish while tracking down a Firefox bug, I now also owed an apology to a Japanese blogger. Personally, I blamed Firefox for ludicrously Draconian error handling, but at least I thought we had “solved” the needless problem raised by such behavior.

Drudge work for nothing

I owe Firefox an apology. Draconian error handling of impossible-to-trace possible UTF errors was not the cause of its failure to display pages correctly. Inability to parse valid CSS on long pages was the actual cause.

Although my page now validated, Firefox still cut it off at the waist. Thanks to this bug, users of Firefox—many of whom care greatly about web standards (it’s one reason so many developers choose Firefox)—were unable to read more than half the comments about XHTML 2 and HTML 5 from their fellow standardistas. They were also unable to post comments or view the footer (thus making them unable to view other content on this site, as well as third-party site highlighted in the footer). This was a win for nobody, except maybe Microsoft, Opera, and Safari. And, like I said, we like Firefox and people who use it. Back to the drawing board.

Seek and ye shall not find

Nikolay Bachiyski, a lead developer at Automattic, then conducted a series of tests:

  1. He established that only Firefox 3.0/3.5 (and only in Windows) cut the valid web page’s content in half.
  2. He verified that the page’s content was valid (UTF-8) as was its markup.
  3. The DOM loaded properly.
  4. There wasn’t an (X)HTML parsing problem.
  5. Disabling JavaScript made no difference.
  6. Disabling CSS enabled all the page’s content to display in Firefox; turning CSS back on cut the page in half again. Clearly, the issue was with CSS.
  7. Nikolay then disabled the lines of Mozilla- and Webkit- oriented CSS3 that generate “warnings” or “errors” in the W3C validation service. But even with those lines disabled and the CSS completely valid, the page’s content failed to display completely in Firefox. The bottom of the page was still cut off.

A CSS “fix” with a drawback

Valid CSS was somehow to “blame” for Firefox’s inability to show a long page without hiding half the content.

You may ask why I didn’t discover this problem during the building and testing of my site’s redesign. You might even ask why my readers didn’t discover it (since I beta tested the redesign at several stages). The answer is simple. I never tested a dummy blog post with nearly 200 comments. It didn’t occur to me that more than 40 comments would be necessary to test whether valid CSS and XHTML would work in good modern browsers, let alone in one as excellent as Firefox.

Michel Bozgounov and Kyle Weems then proposed a simple CSS fix:

div#wrapper {overflow: visible;}

My friend Noel implemented the CSS fix while I was unconscious and having stuff cut out of me.

It works, and I thank all these gentlemen. But it has the unfortunately side-effect of inflicting a flash of reddish-orange background on the page until most or all content has loaded. (I had previously spent over two weeks eliminating that flash of background.) And it does this in all browsers (or nearly all), not just Firefox. To force Firefox to display all content on a page, I have to force every other browser to flash red before it shows content.

Obviously, it’s vital that Firefox users be enabled to read and comment on long or popular posts. But there must be a better way than deforming the CSS. And there is a better way: namely, a Firefox bug fix.

Our friends at WordPress have contacted our friends at Mozilla, so we are hopeful that this will be fast-tracked. Mozilla friends, call on me to help at any time.

9 July Update: 99% solution

With the addition of 1000px of min-height to #wrapper, the reddish-orange flash has been eliminated, at least in pages that load quickly. (On long pages, or with slow connections, the reddish-orange background remains painfully visible until the page finishes loading.) Read more about this CSS adjustment. Note that adding CSS workarounds is not the same thing as fixing browser bugs. (Indeed, CSS workarounds may retard browser development by removing the problem so it never gets fixed.)

A Firefox Test Page

As I am not entirely satisfied with this CSS workaround (despite my gratitude to its authors) and as I do not want Mozilla’s engineering wizards to be unable to fix Firefox because of changes to my CSS, I have posted a Firefox test page using the site’s original (perfectly fine, background-flash-less) CSS, and a page explaining the Firefox test page.—JZ

Read more

  • HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]browser, bugs, Firefox3, Firefox3.5, Firefox/Windows, browsers, firefoxbugs[/tags]

Apple OS X 10.5.7 overheats some Macs

Robert Black was right. OS X 10.5.7 adversely affects the internal heat management of some iMacs (and apparently also some MacBooks), causing the machines to overheat. Overheating, in turn, leads to such problems as freezes during iCal sync; freezes during iTunes sync; and the inability of attached hard drives to complete a backup.

Blah blah

I confirmed this by installing smcFanControl and watching my Mac get hotter and hotter as it tried to complete a SuperDuper backup. Disk Utility confirmed nothing was wrong with the attached drive. Swapping cables proved a faulty cable was not to blame for previous failed backups. Maddeningly, the backup got within 4GB of completion before locking up due to the overheating of my iMac.

Not every iMac or MacBook is affected. It probably varies by factory run and by model. (My MacBook Pro, for instance, is fine.) Third-party stuff and Migration vs. Tabula Rasa System Install seems to have no bearing on whether or not your Mac will choke on the update.

Since even running smcFanControl at settings recommended by Robert Black and others doesn’t cool the iMac enough to finish a backup or verify the quality of the attached drives, it may not make sense to replace my external hard drives (as new drives will likely also fail as the iMac overheats during backup).

With smcFanControl in place, I can use my iMacs but not back them up.

Apple needs to release an update that fixes the hardware problems this one created.

(And someone else needs to install it before I do.)

[tags]OSX10.5.7, bugs, Apple, Macintosh, update[/tags]

Quick survey on OS X 10.5.7 bug triggers

Update: see OS X 10.5.7 overheats some Macs.

Fellow Mac users, let’s see if we can isolate the triggers of the OS X 10.5.7 blues. If we learn the cause, others may know whether it’s safe for them to update, and we may provide Apple’s engineers with a clue on how to fix the problem in a subsequent update.

Theory 1: Migration Assistant

My affected iMacs have systems that were migrated. That is, when I bought the machines in December 2007, after running them for a while as-is to ensure that they worked properly, I ran Migration Assistant to bring over applications, preferences, network settings, and so on from my previous work machine (a non-Intel white powerbook).

Blah blah

Theory: Possibly OS X 10.5.7 update becomes unstable in the presence of a leftover something migrated from an older system.

Test: If you’re suffering from the 10.5.7 blues, did you run Migration Assistant on the afflicted machine? Did you migrate from a non-Intel machine?

Theory 2: Third-Party Stuff

When something goes wrong with a Macintosh update, a third-party add-on is often the trigger. Here are the add-ons on my sufferin’ iMacs:

Items marked “removed!” were my initial suspects. After the update, iTunes froze on sync. I reckoned the iLike plug-in was to blame, and after removing it, was able to sync again for a while.

Then the Mac froze during an iCal sync, so I removed MenuCalendarClock.

But removing these little guys didn’t fix anything. Soon enough, even without these add-ons, the Macs were freezing during iTunes sync and during MobileMe iCal sync. Eventually they froze on any app, doing anything. (Only to inexplicably resume normal operation again for hours at a time. But enough of this.)

And you? If your Mac is misbehaving after running OS X 10.5.7 update, are any of these add-ons on the machine?

[tags]OSX, bugs, OSX10.5.7, 10.5.7, apple, software, updates[/tags]

Browser compatibility updates

DOM whiz and loyal-opposition/web standards advocate Peter-Paul Koch has been working overtime preparing detailed findings on CSS and DOM compatibility in modern browsers, including:

A Compatibility Master Table provides a snapshot of the status and results of all testing; Mobile Compatibility Tests are also in development.

It’s a great resource from an expert who really cares, and who has the time and expertise to find things out for the rest of us. Thanks, PPK!

Real type on the web?

A proposal for a fonts working group is under discussion at the W3C. The minutes of a small meeting held on Thursday 23 October include a condensed, corrected transcription of a discussion between Sampo Kaasila (Bitstream), Mike Champion (Microsoft), John Daggett (Mozilla), Håkon Wium Lie (Opera), Liam Quin (W3C), Bert Bos (W3C), Alex Mogilevsky (Microsoft), Josh Soref (Nokia), Vladimir Levantovsky (Monotype), Klaas Bals (Inventive Designers), and Richard Ishida (W3C).

The meeting started with a discussion of Microsoft’s EOT (Embedded OpenType) versus raw fonts. Bert Bos, style activity lead and co-creator of CSS, has beautifully summarized the relevant pros and cons discussed.

For those just catching up with the issue of real type on the web, here’s a bone-simple intro:

  1. CSS provides a mechanism for embedding real fonts on your website, and some browsers support it, but its use probably violates your licensing agreement with the type foundry, and may also cause security problems on an end-user’s computer.
  2. Microsoft’s EOT (based on the same standard CSS mechanism) works harder to avoid violating your licensing agreement, and has long worked in Internet Explorer, but is not supported in other browsers, is not foolproof vis-a-vis type foundry licensing rules, and may also cause PC security problems.

The proposed fonts working group hopes to navigate the technical and business problems of providing real fonts on the web, and in its first meeting came up with a potential compromise proposal before lunch.

Like everyone these days, the W3C is feeling a financial pinch, which means, if a real fonts working group is formed, its size and scope will necessarily be somewhat limited. That could be a good thing, since small groups work more efficiently than large groups. But a financial constraint on the number of invited experts could make for tough going where some details are concerned—and with typography, as with web technology, the details are everything.

I advise every web designer who cares about typography and web standards—that’s all of you, right?—to read the minutes of this remarkable first gathering, and to keep watching the skies.

[tags]web typography, typography, standards, webstandards, W3C, fonts, embedded, @fontface, EOT, workinggroup[/tags]

A bug in Google Chrome

Between hurricanes and hericanes, you could easily have missed the technology news. Released yesterday in public beta, Google Chrome is a standards-compliant web browser created to erode Microsoft’s browser dominance (i.e. to boost Google’s web dominance) while also rethinking what a browser is and does in the age of web apps and Google’s YouTube.

The new browser is based on Webkit, the advanced-standards-compliant, open source browser engine that powers Apple’s Safari for Mac and PC, but Chrome currently runs only in Windows. You figure that out.

Here are the new browser’s terms of service.

And here’s an important early bug report from Jeremy Jarratt: Google Chrome wrongly displays alternate styles as if active, thus “breaking” websites that use them. (Here’s more about alternate style sheets, from Paul Sowden’s groundbreaking 2001 A List Apart article.)

To compete with Microsoft, the new browser must offer what other browsers do not. The risk inherent in that proposition is a return to proprietary browser code. It is not yet clear to me whether Chrome will compete the wrong way—offering Chrome-only features based on Chrome-only code, thus prompting Microsoft to rethink its commitment to standards—or the right way.

Competing by offering features other browsers do not (easier downloads, streamlined user interface) or by consolidating other browsers’ best features (Opera’s Speed Dial, Firefox’s auto-complete) avoids this risk, as improvements—or at any rate, changes—to the browser’s user interface have no bearing on the display of existing web content.

Competing by supporting web standards ahead of the pack, although not entirely without risk, would also be a reasonable and exciting way to compete. When one browser supports a standard, it goads other browser makers into also supporting it. Because Safari, for instance, supports @font-face, Firefox is not far behind in supporting that CSS spec. @font-face raises font licensing problems, but we’ll discuss those another time. The risk that concerns us here is when a browser supports an emerging specification before it is finalized, thus, essentially, freezing the spec before it is ready. But that is the traditional dance between spec authors and browser makers.

For web standards and web content, we once again live in interesting times. Welcome, Chrome!

[tags]google, chrome, googlechrome, beta, software, browsers, standards, webbrowsers, webstandards, bugs, standards-compliant, alternatestyles, alternatecss[/tags]

Maybe that’s why they call them Kodak moments

It was the last day of our daughter’s first year of school. Party time. All the three-year-olds dressed like dolls; teachers relieved and sad; parents misty-eyed, promising to stay in touch over the summer.

Our children have three teachers. One is leaving for graduate school, the second is off to have a child of her own, and the third—a wonderful woman—will have to be taken out of the school in a box.

The teachers stood together for the last time, hugging each other and our children.

Moments like these are once in a lifetime. Fortunately I carry an iPhone. Unfortunately, my iPhone’s camera is once again taking blanks instead of photographs.

For those who have just missed the photographic opportunity of a lifetime because of this unfortunate iPhone bug, here, once again, is the method that will remove the corrupted file and get your iPhone taking photos again:

  1. Sync iPhone. This also creates a backup of the notes and other items that don’t get synchronized anywhere else.
  2. Go to Settings, General, Reset: “Erase All Content and Settings.”
  3. Once complete, reconnect the iPhone to begin syncing with iTunes.
  4. iTunes will ask if you want to sync from backup. Choose not to. Instead, “Set up as new phone.” This sounds scary, but it’s really not. (You don’t lose your phone number or anything. It’s just a dumb, needlessly scary Apple label.)

From resourcesforlife.com, whose solution this is: “You will lose notes, SMS history, and iPhone settings as well as data that is normally synchronized. However, corrupted system files (such as the internal camera roll files) will be replaced with fresh non-corrupted versions and everything should work.”

I didn’t post this to complain about not getting to photograph the last day of our kid’s first year of school. Nor did I post it to take a swipe at Apple for building an amazingly creative, industry-leading product that is, however, a computer, and thus subject to bugs and glitches.

I posted it because every six months or so, when my iPhone’s camera stops working, I forget how to fix it. Now it’s on my website. When the camera starts failing around Christmastime, I’ll know just where to look.

[tags]apple, iphone, camera, software, bug, whitebox, photo, photos, disappearing[/tags]