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.

Tags: firefox, browser, bug, firefox3, firefox3.5, windows, linux, bugs, buggery, debugging, demo, testpage, mozilla

Filed under: Browsers, CSS, Design, Mozilla, Web Design, Web Standards, bugs, firefox, work, zeldman.com

This post has earned 43 responses so far.

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 in all but edge cases. Read more about this CSS adjustment. Note that adding CSS workarounds is not the same thing as fixing browser bugs. My fear now is that the Firefox bug will not be fixed, as the primary page demonstrating the Firefox bug has now been Firefox-bug-proofed via CSS workarounds. This is always the problem with “fixing” browsers by changing CSS.

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

Tags: browser, bugs, Firefox3, Firefox3.5, Firefox/Windows, browsers, firefoxbugs

Filed under: Browsers, Design, Mozilla, Web Design, Web Standards, bugs, firefox, work, zeldman.com

This post has earned 58 responses so far.

It has only been a few days but I am already sick of the “XHTML is bullshit, man!” crowd 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.

A coterie of well-informed codemeisters, from ppk to Ian Hickson, has always had legit beefs with XHTML, the most persuasive of which was Hickson’s:

It is suggested that HTML delivered as text/html is broken and XHTML delivered as text/xml is risky, so authors intending their work for public consumption should stick to HTML 4.01, and authors who wish to use XHTML should deliver their markup as application/xhtml+xml.

This problem always struck me as more theoretical than real, but I pointed it out in every edition of Designing With Web Standards and left it to the reader to decide. When I wrote the first edition of the book, some versions of Mozilla and IE would go into Quirksmode in the presence of HTML 4, breaking CSS layouts. To me, that was a worse problem than whatever was supposed to be scary or bad about using well-formed XHTML syntax while delivering it as HTML all browsers could support.

The social benefit of rethinking markup sealed the deal. XHTML’s introduction in 2000, and its emphasis on rules of construction, gave web standards evangelists like me a platform on which to hook a program of semantic markup replacing the bloated and unsustainable tag soup of the day. The web is better for this and always will be, and there is much still to do, as many people who create websites still have not heard the call.

A few who became disenchanted with XHTML early retreated to HTML 4, and as browsers stopped going into Quirksmode in its presence, valid, structural HTML 4 became a reasonable option again. But both HTML 4 and XHTML 1 were document languages, not transactional languages. They were all noun, and almost no verb. So Ian Hickson, XHTML’s biggest critic, fathered HTML 5, an action-oriented toddler specification that won’t reach adulthood until 2022, although some of it can be used today.

And guess what? HTML 5 is as controversial today as XHTML was in 2000, and there are just as many people who worry that a specification of which they don’t entirely approve is being shoved down their throats by an uncaring elite. Only this time, instead of the W3C, the uncaring elite is Mr Hickson, with W3C rubber stamp, and input from browser makers, including his employer.

All of this is to say that XHTML is not dead (XHTML 2 is dead, thank goodness), and HTML 5 is not here yet. Between now and 2022, we have plenty of time to learn about HTML 5 and contribute to the discussion—and browser makers have 13 years to get it right. Which is also to say all of us—not just those who long ago retreated to HTML 4, or who became fans of HTML 5 before it could even say “Mama”—are entitled to be pleased that standard markup activity will now have a single focus, rather than a dual one (with XHTML 2 the dog spec that no one was willing to mercy-kill until now).

Entitled to be pleased is not the same as entitled to gloat and name call. As DN put it in comment-44126:

What is really rather aggravating is how many people are using this news as a stick with which to beat any developer or freelancer who’s had the audacity to study up on and use XHTML in good faith–or even, much to the horror of the Smug Knowbetters, admire XHTML’s intelligible markup structure–for the brand-new-minted sin of doing the most with XHTML that’s possible. The ‘unofficial Q&A’ is ripe with that kind of condescension. …[D]on’t pin users (front-end developers are merely users of specifications) with Microsoft’s failure to support the correct MIME type.

Tags: HTML, HTML5, W3C, WTF, XHTML, XML

Filed under: Community, HTML, Standards, Web Design, Web Design History, Web Standards, XHTML, spec

This post has earned 194 responses so far.

Firefox bug repair note

Firefox developers who were initially alerted to a problem on this page, please view the Firefox test page and the page that explains its use.

The web’s future isn’t what the web’s past cracked it up to be. 1999: XML is the light and XHTML is the way. 2009: XHTML is dead—kind of.

From the W3C news archive for 2 July 2009:

XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity. (Permalink)

Please note that this thread is continually updated with useful commentary and links that help make sense of the emergence of HTML 5, the death of XHTML, and what working designers and developers need to know about the present and future of web markup. (There are also comments that add little wisdom to the conversation, but that’s … okay.)

Tags: W3C, XML, XHTML, HTML, HTML5, WTF

Filed under: HTML, HTML5, Markup, Web Design History, Web Standards, XHTML

This post has earned 199 responses so far.

Clusterfuck, despite its saucy name, does not refer to a pleasurable group activity. Its origins are military, its antecedents bloody. The Urban Dictionary offers ten pages of definitions. Our favorite is a double entendre on “cluster bomb” and the oak leaf or star cluster insignia worn by incompetent military brass whose bad decisions result in a needless bloodbath—a “clusterfuck.”

Most web design and development projects turn into clusterfucks. The problem is not unique to web-based client services. Advertising projects, graphic design jobs, architecture assignments, filmmaking, and pretty much every other professional creative service usually begins with smart, talented people shaking hands across a table, and ends in finger-pointing and regret—like a Country & Western love song.

Great work cannot emerge from such environments. Not even good work can crawl from that wreckage. If a fine portfolio, a delightful career, and the satisfaction of earning your bread by providing a genuine service are to be had, you must first learn to manage your clients and colleagues.

Managing your way out of a paper bag

Although I teach this skill, I confess I am not nearly as good at it as I should be. The trick to great projects, I have found, is (a.) landing clients with whom you are sympatico, and who understand language, time, and money the same way you do, and (b.) assembling teams you don’t have to manage, because everyone instinctively knows what to do. I have been lucky at those two things, and thus poor at coping when a design job very occasionally lights its own genitals on fire and leaps into a bucket of oil.

For those who have no control over which clients and projects come to them, there is still hope, because everyone on the web (not just professional designers and developers) has the ability to produce meaningful content, and every designer and developer additionally has the power to create products and services. As your own client, working alone, or with a carefully hand-picked team, you can produce great things. If you suck at management, you’ll have problems, but not the kind of problems that create mediocre websites while emptying your company’s bank account and draining all the joy and color out of life.

Producing a well-edited zine or a useful and skillfully designed web application may produce income. It will almost certainly generate job satisfaction. And once it finds the right audience, it should yield more sympathetic clients, resulting in fewer clusterfucks, and a greater ability to get on the phone and straighten out a mess if you still occasionally fumble as a manager.

Tags: business, webdesign, project management

Filed under: Design, project management, work

This post has earned 52 responses so far.

The earliest websites were minimal in the extreme, but without the style and flair to make a virtue of their simplicity. 37signals and Kottke pioneered the combination of simplicity with deft design sense. Cardigan made it art.

Although it is never popular, never the dominant trend, rarely wins design awards, and almost never earns acclaim from designers, design stripped down to its essentials is always a good idea, and especially on the web, where every byte counts. We salute the old and new practitioners of minimalist web design, and solicit your thoughts on pioneers or present practitioners who combine a minimalist aesthetic with significant design chops.

• 37signals home page, 27 November 1999
• 37signals detail page (first signal), 27 November 1999
• Kottke.org, home of fine hypertext products, 9 March 2000
• Kottke.org, home of fine hypertext products today
• Drudge Report, 10 December 1997
• Drudge Retort
• cardigan.com by Dean Allen (abandoned 2001)
• Wilson Miner
• Subtraction.com by Khoi Vinh
• WordPress Neutica theme designed by Allan Cole (Hat tip: Oliver Lorton)

Tags: design, webdesign, minimalism, history, web design history

Filed under: Design, Web Design, Web Design History, Websites, links, style

This post has earned 76 responses so far.

It’s outrageous that the CSS standard created in 1996 is not properly supported in Outlook 2010. Let’s do something about it.

Hundreds of millions use Microsoft Internet Explorer to access the web, and Microsoft Outlook to send and receive email. As everyone reading this knows, the good news is that in IE8, Microsoft has released a browser that supports web standards at a high level. The shockingly bad news is that Microsoft is still using the Word rendering engine to display HTML email in Outlook 2010.

What does this mean for web designers, developers, and users? In the words of the “Let’s Fix It” project created by the Email Standards Project, Campaign Monitor, and Newism, it means exactly this:

[F]or the next 5 years your email designs will need tables for layout, have no support for CSS like float and position, no background images and lots more. Want proof? Here’s the same email in Outlook 2000 & 2010.

It’s difficult to believe that in 2009, after diligently improving standards support in IE7 and now IE8, Microsoft would force email designers to use nonsemantic table layout techniques that fractured the web, squandered bandwidth, and made a joke of accessibility back in the 1990s.

Accounting for stupidity

For a company that claims to believe in innovation and standards, and has spent five years redeeming itself in the web standards community, the decision to use the non-standards-compliant, decades-old Word rendering engine in the mail program that accompanies its shiny standards-compliant browser makes no sense from any angle. It’s not good for users, not good for business, not good for designers. It’s not logical, not on-brand, and the very opposite of a PR win.

Rumor has it that Microsoft chose the Word rendering engine because its Outlook division “couldn’t afford” to pay its browser division for IE8. And by “couldn’t afford” I don’t mean Microsoft has no money; I mean someone at this fabulously wealthy corporation must have neglected to budget for an internal cost. Big companies love these fictions where one part of the company “pays” another, and accountants love this stuff as well, for reasons that make Jesus cry out anew.

But if the rumor’s right, and if the Outlook division couldn’t afford to license the IE8 rendering engine, there are two very simple solutions: use Webkit or Gecko. They’re both free, and they both kick ass.

Why it matters

You may hope that this bone-headed decision will push millions of people into the warm embrace of Opera, Safari, Chrome, and Firefox, but it probably won’t. Most people, especially most working people, don’t have a choice about their operating system or browser. Ditto their corporate email platform.

Likewise, most web designers, whether in-house, agency, or freelance, are perpetually called upon to create HTML emails for opt-in customers. As Outlook’s Word rendering engine doesn’t support the most basic CSS layout tools such as float, designers cannot use our hard-won standards-based layout tools in the creation of these mails—unless they and their employers are willing to send broken messages to tens millions of Outlook users. No employer, of course, would sanction such a strategy. And this is precisely how self-serving decisions by Microsoft profoundly retard the adoption of standards on the web. Even when one Microsoft division has embraced standards, actions by another division ensure that millions of customers will have substandard experiences and hundreds of thousands of developers still won’t get the message that our medium has standards which can be used today.

So it’s up to us, the community, to let Microsoft know how we feel.

Participate in the Outlook’s Broken project. All it takes is a tweet.

Tags: browsers, bugs, IE8, outlook, microsoft, iranelection

Filed under: Browsers, CSS, Compatibility, Design, Marketing, Markup, Microsoft, Standards, State of the Web, The Profession, Tools, W3C, Web Standards, Working, XHTML, software, spec, style

This post has earned 90 responses so far.

In Issue No. 286 of A List Apart, For People Who Make Websites, Patrick Lynch explains why beauty matters in design, and Mark Birbeck introduces us to RDFa.

• Introduction to RDFa: Learn how semantic features normally confined to the head of an HTML document can be used to add semantic richness to the elements of the body. Part One of a two-part primer.
• Visual Decision Making: If it takes only 50 milliseconds for people to form an aesthetic opinion of your site’s credibility and trustworthiness, are designers who create visually compelling sites wasting time and treasure on indulgences?

Comments off.

Filed under: Design

WaSP InterAct is a “living, open web standards curriculum.” Put together by an amazing group of dedicated educators and industry experts, the curriculum is designed to teach students the skills of the web professional—and ease the burden of colleges and universities, struggling to develop timely and appropriate curricula for our fast-moving profession.

Schools that teach web design struggle to keep pace with our industry, and those just starting their curricula often set off in the wrong direction because the breadth and depth of our medium can be daunting. The WaSP InterAct curriculum project seeks to ease the challenges schools around the world face as they prepare their students for careers on the Web. … Its courses are divided into six learning tracks that provide students with a well rounded foundation in the many facets of the web design craft.

The group offers its resources to all who need them (to reuse adapt), and it seeks your content and ideas.

Tags: design, data, webdesign, webstandards, education, curriculum, WaSP, webstandards.org

Filed under: Design, Web Design, Web Standards, Working

This post has earned 10 responses so far.

For the third edition of Designing With Web Standards, I’ve brought in a co-author: the brilliant and talented Mr Ethan Marcotte.

Mr Marcotte is a web designer/developer who “works for Airbag Industries as a Senior Designer, swears profusely on Twitter, and is getting married to an incredible lady.” He is also a technical editor and contributing author to A List Apart, and the co-author of several fine books about the intersection between great code and fine design. Then there’s the fact that I dig him. I dig the hell out of him. I love him like a younger, sweeter, funnier brother.

That’s important because I don’t add a co-author to any book, let alone this book, lightly. In asking Ethan to help me bring the awesome to this substantially revised and rewritten edition, I chose not only on the basis of expertise and writing ability, but also on sheer karma.

In his new role, Ethan joins a SuperFriends™ line-up including technical editor Aaron Gustafson (Twitter), another honey of a guy, and truly one of the smartest, most innovative, and most knowledgeable voices in web standards, and editor Erin Kissane (Twitter), whose mastery of the subtlest details of voice consistency alone makes her the finest editor I have ever been blessed to work with. Behind it all, there’s Michael Nolan (Twitter), New Riders’ sagely seasoned acquisitions editor and a designer and author himself, who first took a chance on me as an author back in nineteen ninety humph.

Designing With Web Standards, 3rd Edition is coming this year to a bookstore near you. I thank my brilliant crew for making it possible. Onward!

Tags: EthanMarcotte, beep, unstoppablerobotninja, airbag, alistapart, CSS, design, webstandards, webdesign, designingwithwebstandards, DWWS, 3rdedition, DWWS3e, writer, writers, authors

Filed under: CSS, DWWS, Design, Education, Publications, Publishing, Respect, Web Design, Web Standards, Zeldman, development

This post has earned 43 responses so far.