Found in my in-box on this gloriously muggy morning:
Typical day.
Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”
Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.
In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:
Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….
But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….
For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.
Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.
For instance, in the page entitled “Use What Is There,” Bert says:
The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….
And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …
And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.
He then warns:
There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.
In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)
This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.
You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.
Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.
If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.
It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).
And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.
To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.
I urge everyone to read “What is a Good Standard?“, and I thank my friend Tantek for pointing it out to me.
[tags]W3C, design, principles, bertbos, maintainability, accessibility, extensibility, learnability, simplicity, specs, standards, css, markup, code, languages, web, webdesign, webstandards, webdevelopment, essays[/tags]
In Issue No. 288 of A List Apart, for people who make websites: Margit Link-Rodrigue advises us to integrate accessibility with front-end development instead of treating it as an afterthought—an item on a checklist. And Joe Clark analyzes why some forms of writing resist being expressed as semantic HTML.
[tags]alistapart, semantics, accessibility, design, webdesign, markup, XML, link-rodrigue, joeclark[/tags]
Over the weekend, as thoughtful designers gathered at Typecon 2009 (“a letterfest of talks, workshops, tours, exhibitions, and special events created for type lovers at every level”), the subject of web fonts was in the air and on the digital airwaves. Worthwhile reading on web fonts and our other recent obsessions includes:
Responding to a question I raised here in comments on Web Fonts Now, for Real, Richard Fink explains the thinking behind Ascender Corp.’s EOT Lite proposal . The name “EOT Lite” suggests that DRM is still very much part of the equation. But, as Fink explains it, it’s actually not.
EOT Lite removes the two chief objections to EOT:
Essentially, then, an “EOT Lite file is nothing more than a TTF file with a different file extension” (and an unfortunate but understandable name).
A brief, compelling read for a published spec that might be the key to real fonts on the web.
@ilovetypography tackles the question we’ve been pondering. After setting out what web designers want versus what type designers and foundries want, the author summarizes various new and old proposals (“I once heard EOT described as ‘DRM icing on an OpenType cake.’”) including Tal Leming and Erik van Blokland‘s .webfont, which is gathering massive support among type foundries, and David Berlow’s permissions table, announced here last week.
Where does all of this net out? For @ilovetypography, “While we’re waiting on .webfont et al., there’s Typekit.”
(We announced Typekit here on the day it debuted. Our friend Jeff Veen’s company Small Batch, Inc. is behind Typekit, and Jason Santa Maria consults on the service. Jeff and Jason are among the smartest and most forward thinking designers on the web—the history of Jeff’s achievements would fill more than one book. We’ve tested Typekit, love its simple interface, and agree that it provides a legal and technical solution while we wait for foundries to standardize on one of the proposals that’s now out there. Typekit will be better when more foundries sign on; if foundries don’t agree to a standard soon, Typekit may even be the ultimate solution, assuming the big foundries come on board. If the big foundries demur, it’s unclear whether that will spell the doom of Typekit or of the big foundries.)
Applauding HTML 5’s introduction of semantic page layout elements (“Goodbye div soup, hello semantic markup”), author Jeff Starr shows how HTML 5 facilitates cleaner, simpler markup, and explains how CSS can target HTML 5 elements that lack classes and IDs. The piece ends with a free, downloadable goodie for WordPress users. (The writer is the author of the forthcoming Digging into WordPress.)
Just like it says.
[tags]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb, HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards, typography[/tags]
David Berlow of The Font Bureau has proposed a Permissions Table for OpenType that can be implemented immediately to turn raw fonts into web fonts without any wrappers or other nonsense. If adopted, it will enable type designers to license their work for web use, and web designers to create pages that use real fonts via the CSS @font-face standard.
My April 21, 2009 A List Apart interview with Berlow explains how a permissions table would enable type designers to support @font-face without DRM or intermediary hosted licensing. A press release provides more detail:
Future web users will not want their browsers clogging the workings of their Operating Systems with fonts, or the browsers’ presenting the users with web content that the user cannot read. In addition, web users do not want imprecisely or un-aesthetically presented content where a simple type-bearing graphic would suffice. Lastly, users do not want fonts to be able to give fraudulent users the unique corporate appearance of a genuine company.
So far, the browsers allowing use of the @Font-face font linking are installing and removing fonts in an invisible way, but future browsers may need to more intelligently manage web fonts for users as more sites employ them. Here, the proposed table can help by containing the links from which the fonts came, and determining their cacheability based on the user’s browsing history. More importantly, the recommendations section of the proposed table could allow a browser to offer reconcileablilty of any font treatment in conflict with a user’s ‘preferenced’ desires in areas such as sizing of type, presentation of line length and potentially dangerous type treatments such as rapid text blinking.
The Permissions Table proposal will be announced tomorrow on newsgroups and forums frequented by type designers.
[tags]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb[/tags]
The Happy Cog-designed social network for Brighter Planet is now in public beta. Come on down and kick the tires. Brighter Planet helps you take control of your environmental footprint: measure your climate impact, discover simple ways to reduce it, track your progress, and share your experiences with other people who who want to make a difference.
Happy Cog‘s New York office developed this project. The team:
This truly collaborative project could not have been conceived or completed without the brilliant and generous work of Brighter Planet team members including:
Not only is this young, passionate team dedicated to reducing climate change and all things green, they are also marketing kingpins, shrewd user experience designers, and badass developers.
We love our clients. These folks and this project are dear to us. And it’s a fun way to make a difference. I hope you’ll check out Brighter Planet’s new beta social network.
[tags]brighterplanet, climatechange, beta, site, launch, launches, webdesign, projects, work, happycog[/tags]
A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes:”
[I]f you were building a mark-up language from scratch you would include elements like
footer,headerandnav(actually, HTML 2 had amenuelement for navigation that was deprecated in 4.01).You probably wouldn’t have loads of computer science oriented elements like
kbd,var,sampin preference to the structural elements that people “fake” with classes. Things liketabindexwouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, andaccesskeywouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. …
There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.
The third point is Lawson’s key insight, for it illuminates the dilemma faced by HTML 5 or any other honest effort to move markup forward. Neither semantic purity nor fault-tolerance will do, and neither approach can hope to satisfy all of today’s developers.
A markup based on what we now know, and can now do thanks to CSS’s power to disconnect source order from viewing experience, will be semantic and accessible, but it will not be backward compatible. That was precisely the problem with XHTML 2, and it’s why most people who build websites for a living, if they knew enough to pay attention to XHTML 2, soon changed the channel.
XHTML 2 was conceived as an effort to start over and get it right. And this doomed it, because right-wing Nativists will speak Esperanto before developers adopt a markup language that breaks all existing websites. It didn’t take a Mark Pilgrim to see that XHTML 2 was a dead-end that would eventually terminate XHTML activity (although Mr Pilgrim was the first developer I know to raise this point, and he certainly looks prescient in hindsight).
It was in reaction to XHTML 2’s otherworldliness that the HTML 5 activity began, and if XHTML suffered from detachment from reality, HTML 5 is too real. It accepts sloppiness many of us have learned to do without (thereby indirectly and inadvertently encouraging those who don’t develop with standards and accessibility in mind not to learn about these things). It is a hodgepodge of semantics and tag soup, of good and bad markup practices. It embraces ideas that logically cancel each other out. It does this in the name of realism, and it is as admirable and logical for so doing as XHTML 2 was admirable and logical in its purity.
Neither ethereal purity nor benign tolerance seems right, so what’s a spec developer to do? They’re damned either way—which almost suggests that the web will be built with XHTML 1.0 and HTML 4.01 forever. Most importantly for our purposes, what are we to do?
As the conversation about HTML 5 and XHTML has played out this week, I’ve felt like Regan in The Exorcist, my head snapping around in 360 degree arcs as one great comment cancels out another.
In a private Basecamp discussion a friend said,
Maybe I’m just confused by all the competing viewpoints, but the twisted knots of claim and counterclaim are getting borderline Lovecraftian in shape.
Another said,
[I] didn’t realize that WHATWG and the W3C’s HTML WG were in fact two separate bodies, working in parallel on what effectively amounts to two different specs [1, 2—the entire thread is actually worth reading]. So as far as I can tell, if Ian Hickson removes something from the WHATWG spec, the HTML WG can apparently reinsert it, and vice versa. [T]his… seems impossibly broken. (I originally used a different word here, but, well, propriety and all that.)
Such conversations are taking place in rooms and chatrooms everywhere. The man in charge of HTML 5 appears confident in its rightness. His adherents proclaim a new era of loaves and fishes before the oven has even finished preheating. His articulate critics convey a palpable feeling of crisis. All our hopes now hang on one little Hobbit. What do we do?
As confused as I have continually felt while surfing this whirlwind, I have never stopped being certain of two things:
[tags]HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards[/tags]
Today the pain woke me at 5:00 AM. One week ago today I had surgery. While most of me has bounced back, parts look like I disagreed with a mule. There is tenderness where a hernia repair botched by NYU interns 20 years ago finally got fixed. There’s throbbing, tumescent, Tim-Burton-directed pain in other places, where other things were done.
The past 12 months have been … interesting. I fired a client. My lead designer in New York decided to strike out on his own. I woke one morning with a toe the size of Cleveland, and after four months of practitioner hot potato, was diagnosed with gout and osteoarthritis. My dad had heart surgery, and airline incompetence got me to his side after it was over. (Fortunately he survived.) One of my businesses yielded a tax bill I couldn’t pay. I required intensive periodontal care. My hernia, supposedly fixed two decades ago, popped open again.
Somewhere in the middle of this—around Thanksgiving—my beloved wife screwed up the courage to confess that she was unhappy.
A year of couples counseling could not save the marriage. We did, however, save the family. Our child is well, we co-parent beautifully, and, with a lot of work on both sides, the ex and I have become good friends. Better friends, maybe, than when we were husband and wife. Friends for life. Lemonade for 200, Alex.
The dizzying marital sea change dwarfed everything else. At first I was stunned, like an accident victim. During one of the comic episodes of my toe enlargement mystery, I found myself alone in a hospital gown, about to have an MRI. In the mirror I reminded myself of my hospital-gowned father, whose surgery I had just attended. The doctor bustled in to ask me questions before the test. “How you doing,” he said. It took all my strength not to babble, “My wife is leaving me.”
We threw a Christmas party in the studio. My wife and child were among the guests, the wife looking radiant, the child frolicking adorably. I sensed that people viewed me as lucky and successful, and most were happy for me. They didn’t know that I was about to lose the only thing that matters. In the midst of happy celebrants, I felt alone.
During the inauguration of President Obama, while much of the world experienced hope, I focused on Laura Bush standing beside George Bush, and wondered why their marriage endured, while mine was falling apart.
It was like that. Then it got better.
One day I realized I could not change what would happen, but I could influence how it happened. I could be the angry denier, hanging onto what no longer exists. Or I could embrace change with love and no conditions. After all, it was not about me, it was about us. And the most important thing was that the most important one of us be protected and continue to feel safe and loved.
Once you figure that out, the rest is easy, if you have a good partner.
By the time I started letting people know about the divorce, I was almost okay with it. I had stopped feeling that things were happening to me, and started taking control of my life. I enjoyed family time and single time. Although my depressed mother had raised me to view self-love as narcissism, I began taking care of myself. I ate sensibly, exercised, saw friends, took time to relax.
As part of that self-care, I opted not to leave unexploded land mines in my system.
During yesterday’s initial follow-up, the surgeon told me I was doing well—recovering fast. I celebrated by walking three miles down Fifth Avenue and meeting a friend for lunch. Then the pain told me to rush home and lie down, and I did as the pain commanded.
The pain that wakes me is good pain. It is the pain of taking care of yourself. The pain of recovery.
[tags]myglamorouslife, zeldman[/tags]
AN EMAIL from Chairman Hickson resolves an ambiguity in the nav element of HTML 5.
One of the new things HTML 5 sets out to do is to provide web developers with a standardized set of semantic page layout structures. For example, it gives us a nav element to replace structures like div class="navigation".
This is exciting, logical, and smart, but it is also controversial.
The controversy is best expressed in John Allsopp’s A List Apart article, Semantics in HTML 5, where he worries that the new elements may not be entirely forward-compatible, as they are constrained to today’s understanding of what makes up a page. An extensible mechanism, although less straightforward, would offer more room to grow as the web evolves, Allsopp argues.
We’re pretty sure Ian Hickson, the main force behind HTML 5, has heard that argument, but HTML 5 is proceeding along the simpler and more direct line of adding page layout elements. The WHAT Working Group Mr Hickson chairs has solicited designer and developer opinion on typical web page structures in order to come up with a short list of new elements in HTML 5.
nav is one of these elements, and its description in the spec originally read as follows:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element.
The perceived ambiguity was expressed by Bruce Lawson (AKA HTML 5 Doctor) thusly:
“Primary navigation blocks” is ambiguous, imo. A page may have two nav blocks; the first is site-wide naviagtion (“primary navigation”) and within-page links, eg a table of contents which many would term “secondary nav”.
Because of the use of the phrase “primary navigation block” in the spec, a developer may think that her secondary nav should not use a
Chairman Hickson has resolved the ambiguity by changing “primary” to “major” and by adding an example of secondary navigation using nav.
When Apple chose KHTML rather than Mozilla Gecko as the basis for its Safari browser, some of us in the web standards community scratched our heads. Sure, KHTML, the rendering engine in Konqueror, was open-source and standards-compliant. But, at the time, Gecko’s standards support was more advanced, and Gecko-based Mozilla, Camino, and even Netscape 6 felt more like browsers than Konqueror. Gecko browsers had the features, the comparative maturity, and the support of the standards community. Apple’s adoption of KHTML, and creation of a forked version called Webkit, seemed puzzling and wrong.
Yet, thanks largely to the success of the iPhone, Webkit (Apple’s open source version of KHTML) 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. Had Apple chosen Gecko, they might not have been able to so powerfully influence mainstream consumer opinion, because the fully formed, distinctly mature Gecko brand and experience could easily have overshadowed and constrained Apple’s contribution. (Not to mention, tolerating external constraint is not a game Apple plays.)
Just how has mobile Safari, a relative latecomer to the world of standards-based browsing, been able to make a difference, and what difference has it made?
Firefox and Opera were wonderful before any Webkit-based browser reached maturity, but Firefox and Opera were and are non-mainstream tastes. Most people use Windows without thinking much about it, and most Windows users open the browser that comes with their operating system, again without too much thought. This doesn’t make them dumb and us smart. We are interaction designers; they are not.
Thus, the paradox: even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a comparatively poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. If you knew enough to want Firefox and Opera, those browsers delivered features and experience that confirmed the wisdom of your choice. If you didn’t know to want them, you didn’t realize you were missing anything, because folks reading this page sweated like Egyptian pyramid builders to make sure you had a good experience despite your browser’s flaws.
Firefox and Opera are great browsers that have greatly advanced the cause of web standards, but because they are choices in a space where most people don’t make choices, their power to convert is necessarily somewhat truncated. The millions mostly don’t care what happens on their desktop. It’s mostly not in their control. They either don’t have a choice or don’t realize they have one, and their expectations have been systematically lowered by two decades of unexciting user experience.
By contrast, the iPhone functions in a hot realm where consumers do make choices, and where choices are badges. Of course many people are forced economically to choose the cheap or free phone that comes with their mobile service. But many others are in a position to select a device. And the iPhone is to today’s urban professional gym rat what cigarettes and martinis were to their 1950s predecessors. You and I may claim to choose a mobile device based on its features, but the upwardly mobile (pardon the pun), totally hot person standing next to us in the elevator may choose their phone the same way they choose their handbag. And now that the iPhone sells for $99, more people can afford to make a fashion decision about their phone—and they’ll do it.
Although there were great phones before the iPhone, and although the iPhone has its detractors, it is fair to say that we are now in a Mobile 2.0 phase where people expect more than a Lynx-like experience when they use their phone to access the internet. Mobile Safari in iPhone, along with the device’s superior text handling thanks to Apple and Adobe technologies, is changing perceptions about and expectations of the web in the same way social networking did, and just at the historical moment when social networking has gone totally mainstream.
Oprah’s on Twitter, your mom’s on Twitter, and they’re either using an iPhone or a recently vastly upgraded Palm or Blackberry that takes nearly all of its cues from the iPhone. Devices that copy the iPhone of course mostly end up selling the iPhone, the same way Bravo’s The Fashion Show would mostly make you miss Project Runway if you even watched The Fashion Show, which you probably haven’t.
Safari isn’t perfect, and Mobile Safari has bugs not evident in desktop Safari, but Webkit + Apple = secret sauce selling web standards to a new generation of consumers and developers.
[tags]webdesign, webstandards, design, standards, browsers, CSS, webkit, gecko, mozilla, firefox, opera, safari, mobile, mobilesafari, iphone[/tags]
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:
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[/tags]
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.
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.
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.
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.
Nikolay Bachiyski, a lead developer at Automattic, then conducted a series of tests:
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.
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.)
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[/tags]
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[/tags]
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. — JZ
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 has been updated with useful comments and links that help make sense of the emergence of HTML 5, the death of XHTML 2.0, and what designers and developers need to know about the present and future of web markup.
[tags]W3C, XML, XHTML, HTML, HTML5, WTF[/tags]