Loving HTML5

Half of standards making is minutia; the other half is politics. Rightly or wrongly, I’ve long suspected that Atom was born, not of necessity, but because of conflicts between the XML crowd and the founders of RSS. Likewise, rightly or wrongly, I reckoned HTML5 was at least partly Hixie’s revenge against XHTML served as text/html.

And then a funny thing happened. Some friends and I gathered at Happy Cog’s New York studio to hash out the pros and cons of HTML5 from the perspective of semantic-markup-oriented web designers (as opposed to the equally valid perspectives of browser engineers and web application developers—the two perspectives that have primarily driven the creation of HTML 5).

Our first task was to come to a shared understanding of the spec. During the two days and nights we spent poring over new and changed semantic elements, we discovered that many things we had previously considered serious problems were fixable issues related to language.

Easy language problems

Some of these language problems are trivial indeed. For instance, on both the WHATWG and W3C sites, the specification is sometimes called “HTML 5” (with a space) and sometimes called “HTML5” (with no space). A standard should have a standard name. (Informed of this problem, Hixie has removed the space everywhere in the WHATWG version of the spec.)

Likewise, as an end-user, I found it confusing to be told that there is an “HTML5 serialization of HTML 5,” let alone an “XHTML 5 version of HTML5.” I requested that the two serializations be referred to as “HTML” and “XHTML”—emphasizing the distinction between the two kinds of syntax rather than drawing needless attention to version numbers. (Again, Hixie promptly updated the spec.)

Names and expectations

Some language problems are tougher—but still eminently fixable, because they are language problems that mar the presentation of good ideas, not bad ideas that require rethinking.

For example, in order to choose suitable names for the new semantic elements in HTML 5, Hixie analyzed classnames on thousands of websites to see what web designers and developers were already doing. If many designers and developers use classnames like “header” and “footer” to contain certain kinds of content, then HTML 5 should use these labels, too, Hixie and his colleagues reasoned. Doing so would make the purpose of the new elements intuitively obvious to working web professionals, removing the learning curve and encouraging proper element use from the get-go.

It’s a beautiful theory that comes straight out of Bert Bos’s W3C Design Principles. There’s just one problem. Header, and especially footer, behave differently from what their names will lead web designers and developers to expect. Developers will use it for the footer of the page—not for the footer of each section. And they will be frustrated that the footer in HTML5 forbids navigation links. After all, the footer at the bottom of web pages almost always includes navigation links.

To avoid misuse and frustration, the content model of footer should change to match that of header, so that it may be used concurrently as a template level element (the expected use) and a sub-division of section (the new use). Alternately, the element’s name should be changed (to almost anything but “footer”). Expanding the content model is clearly the better choice.

For the love of markup

HTML5 is unusual in many ways. Chiefly, it is the first HTML created in the time of web applications. It is also the first to be initiated outside the W3C (although it now develops there in parallel).

Not surprisingly in a specification that goes on for 900 pages, there are at least a dozen places in HTML5 where a thoughtful standardista might request clarification, suggest a change, or both. My friends and I have taken a stab at this ourselves, and will soon publish our short list of recommendations and requests for clarification.

Nevertheless, the more I study the direction HTML5 is taking, the better I like it. In the words of the HTML5 Super Friends, “Its introduction of a limited set of additional semantic elements, its instructions on how to handle failure, and its integration of application development tools hold the promise of richer and more consistent user experiences, faster prototyping, and increased human and machine semantics.”

Update

[4:47 PM EST] Calling all cars! The HTML5 Super Friends declaration of support is now live, as is the Super Friends Guide to HTML5 Hiccups (i.e. our technical recommendations).

ShortURL: zeldman.com/?p=2438

DWWS 3e mini-site updates

Designing With Web Standards, 3rd Edition

The new mini-site for the 3rd Edition of Designing With Web Standards has been updated, with additional information about the substantially revised web standards guidebook, and with tweaks to the CSS which, one hopes, now bring embedded web font goodness to Internet Explorer users, as well as our friends on Safari, Firefox, and Opera. We love the smell of Franklin in the morning.

Short URL: zeldman.com/x/60

What’s new in DWWS 3e

Designing With Web Standards, 3rd Edition

The 3rd Edition of Designing With Web Standards is coming soon to a bookstore near you. Abetted mightily by our secret cabal of interns, co-author Ethan Marcotte, technical editor Aaron Gustafson, copyeditor Rose Weisburd, editor Erin Kissane and I have worked hard to create what we hope is not merely an update, but a significant revision to the foundational web standards text.

Packed with new ideas

After years of stasis, the world of standards-based design is exploding with new ideas and possibilities. Designing With Web Standards 3rd Edition captures this moment, makes sense of it, and keeps you smartly ahead of the pack.

From HTML 5 to web fonts, CSS3 to WCAG2, the latest technologies, claims and counter-claims get broken down in classic DWWS style into their easy-to-understand component ideas, helping you pick the course of action that works best for your projects. As always, the core ideas of standards-based design (which never change) get presented with clear insights and up-to-date examples. You’ll find strategies for persuading even the most stubborn boss or client to support accessibility or reconsider what “IE6 support” means—and for handling the other problems we face when trying to bring rational design and development to the unruly web.

Now with more “how”

While this 3rd Edition, like its predecessors, spends a great deal of time on “why,” it also features a lot more “how” than past editions. If you loved the ideas in DWWS, but wished the book was a bit more hands-on, this is the edition you’ve waited for.

Oh, and the color this time? It’s blue, like l’amour.

Pre-order and save

A few chapters remain to be written, but the goal is in sight, and the book will be out this Fall. To celebrate, you can now save 37% when you pre-order Designing With Web Standards 3rd Edition from Amazon.com.

There’s a new book mini-site as well, with more content and features to come. The sharp-eyed will notice that the mini-site is set in Franklin Gothic. A web-licensed version of ITC Franklin Pro Medium from Font Bureau has been embedded via standard CSS. It works everywhere, even in IE. (View Source if curious.)

ShortURL: zeldman.com/x/57

Web fonts and standards

AS FAR back as 1998, CSS2 provided a way to link to real fonts from your style sheet:


  @font-face {
  font-family: "Watusi";
  src: url("http://www.example.com/fonts/watusi.ttf") 
  format("truetype");
	}

  h1 { 
  font-family: "Watusi", sans-serif; 
	}

	

Instead of static pictures of fonts, linked font files can be retrieved from the web and used to display HTML text. And not just for headlines, but for body copy, too. It’s brilliant! It’s magnificent! There are just two problems:

  • Unless they are specifically licensed for web use (and few fonts are), if you embed fonts you own on a web page, you may be violating your End User Licensing Agreement (EULA) with the font foundry.
  • While Safari (and other Webkit browsers, including Google Chrome), Opera, and Firefox support @font-face for TrueType (TTF) and OpenType (OTF) fonts, guess which browser does not? That’s right, Internet Explorer. That’s not because IE is technically inferior to the other browsers. Rather, it’s because Microsoft does not wish to provide technology that might infringe on the rights of type designers. Instead, Microsoft supports @font-face only for the Embedded OpenType (EOT) format—which Microsoft itself invented. EOT discourages the copying of copyrighted font files via encryption, “subsetting” (using only needed characters rather than the entire font), and other techniques. Microsoft has supported EOT—and proposed it as a W3C standard—since IE4 was young. No other browser maker supports EOT.

The Tan method and IE

It’s the perennial web standards problem, but until Microsoft joins the party, Jon Tan offers a commendable workaround, combining standard @font-face with EOT served via IE conditional comments. It’s a hack, perhaps, but a clean one—and one that even Microsoft would approve. Nice work, Jon Tan. That’s one hurdle cleared.

The licensing hurdle

Type foundries are on the verge of agreeing to standards that will protect their rights and enable designers to embed real fonts on their web pages via standard CSS. They are on the verge, but not there yet. Competing proposals include Erik van Blokland and Tal Leming’s .webfont, a compressed format containing XML and font data; Ascender’s EOT Lite, which removes the chief objections to Microsoft’s EOT while still working in IE; and David Berlow’s OpenType Permissions and Recommendations Table, a mechanism for showing that the designer has paid for the right to use a particular font on a particular domain.

Using @font-face in all browsers today

Some of these methods work already. For instance, on Font Bureau’s website, you will soon be able to buy a web- and print-licensed version of one of their fonts for 20% more than a print-only-licensed version, and embed it on a given domain via @font-face. It will be legally licensed, and it will work in Safari, Firefox, and Opera. It will even work in IE, if you use Jon Tan’s workaround.

Rise of the middlemen

Until type designers agree to a standard and all browsers support @font-face embedding of TrueType and OpenType fonts, “middleman” platforms such as Typekit and Typotheque will make real web fonts possible by handling licensing and technological hassles.

As nearly all of you reading this know, here’s how it works: First, companies like Typekit get font vendors to sign on. The companies agree to license their fonts through Typekit. Designers pay a monthly fee to Typekit for arranging the license and hosting the fonts. Typekit also provides a technology solution, ensuring that the fonts show up in browsers that support standard font formats via @font-face (Safari, Firefox, Opera) as well as the one that does not (Internet Explorer).

Worth noting is that Typekit is font foundry agnostic, welcoming all, whereas Typotheque is a foundry-specific solution. The wizards at Clearleft have their own middleman platform in the works. All these solutions are currently in beta.

As of this writing, their pricing models are unknown—and price is sure to have an impact on acceptance.

Moreover, by definition, no web font middleman (or font developer, like Typotheque) offers every font you could wish for, and ultimately, designers will only choose a service that provides fonts they wish to use. Nor is it yet known whose technical solution will be best, whose font file will load fastest, how reliable each hosting platform will be as usage scales up, and so on.

The effect of font services on web standards

It remains to be seen whether a font-licensing standard and universal browser support for @font-face will kill the middlemen, or whether the middlemen will prove so successful that they delay or stifle the adoption of a font-licensing standard and allow Microsoft to shrug its shoulders indefinitely at supporting @font-face for anything beyond its proprietary EOT file format.

There is also the possibility that the middlemen, by increasing acceptance of web fonts, will hasten the arrival of a licensing standard—and that this will, in turn, prompt Microsoft to support @font-face for any licensed font.

ShortURL: zeldman.com/x/54

Styles Council

I just spent an intensely magical two days discussing web standards with Nicole Sullivan, Dan Cederholm, Jeremy Keith, Eric Meyer, Wendy Chisholm, Tantek Çelik, and Ethan Marcotte in Happy Cog’s New York studio. (Photos.) We laughed, we cried, we thin-sliced the changing semantics of the b element.

To keep the wonderfulness flowing, I’ll spend today attending Tantek’s New York City microformats workshop.

Why Standards Fail

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.

Design is for people

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.

Shrinkage and seduction

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.

What were once vices are now habits

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.

The future of the future of standards

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]

Web fonts, HTML 5 roundup

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:

Jeffrey Zeldman Questions The “EOT Lite” Web Font Format

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:

  • it bound the EOT file, through rootstrings, to the domain name;
  • it contained MTX compression under patent by Monotype Imaging, licensed by Microsoft for this use.

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.

Web Fonts—Where Are We?”

@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.)

The Power of HTML 5 and CSS 3

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.)

Surfin’ Safari turns up new 3-D HTML5 tricks that give Flash a run for its money

Just like it says.

Read more

  • Web Fonts Now, for Real: David Berlow of The Font Bureau publishes a proposal for a permissions table enabling real fonts to be used on the web without binding or other DRM. — 16 July 2009
  • Web Fonts Now (How We’re Doing With That): Everything you ever wanted to know about real fonts on the web, including commercial foundries that allow @font-face embedding; which browsers already support @font-face; what IE supports instead; Håkon Wium Lie, father of CSS, on @font-face at A List Apart; the Berlow interview at A List Apart; @font-face vs. EOT; Cufón; SIFR; Cufón combined with @font-face; Adobe, web fonts, and EOT; and Typekit, a new web service offering a web-only font linking license on a hosted platform; — 23 May 2009
  • HTML 5 is a mess. Now what? 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.” Given all that, what should web designers and developers do about it? — 16 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]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb, HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards, typography[/tags]

Web Fonts Now, for real

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.

Read more

  • Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
  • Web Fonts Now (How We’re Doing With That): Everything you ever wanted to know about real fonts on the web, including commercial foundries that allow @font-face embedding; which browsers already support @font-face; what IE supports instead; Håkon Wium Lie, father of CSS, on @font-face at A List Apart; the Berlow interview at A List Apart; @font-face vs. EOT; Cufón; SIFR; Cufón combined with @font-face; Adobe, web fonts, and EOT; and Typekit, a new web service offering a web-only font linking license on a hosted platform; — 23 May 2009

[tags]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb[/tags]

Web standards secret sauce

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?

The platform paradox

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.

The power to convert

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.

Mobile 2.0

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.

Read more

  • Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
  • 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
  • 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]webdesign, webstandards, design, standards, browsers, CSS, webkit, gecko, mozilla, firefox, opera, safari, mobile, mobilesafari, iphone[/tags]

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]