In Issue No. 245 of A List Apart, for people who make websites: Sarah B. Nelson of Adaptive Path shows how to create collaborative work sessions that actually work, and Iconfactory’s Craig Hockenberry concludes his remarkable two-part series on designing and coding with the iPhone and its new brethren in mind.
Category: Browsers
Through a viewport, darkly.
In Issue No. 244 of A List Apart, for people who make websites, father of CSS Håkon Wium Lie advocates real TrueType fonts in web design, while Iconfactory’s Craig Hockenberry (developer of Twitterific) describes in detail how to optimize websites for iPhone.
Web content is mostly text. Web interfaces are text-based. Design consists chiefly in arranging text to aid communication—guiding readers to the words and experiences they seek. Better typography means better web experiences. Improving typography without resorting to image or Flash replacement and their attendant overhead is a consummation devoutly to be wished. Will browser makers rise to Håkon’s challenge?
Apple’s iPhone is the new frontier in interface design, offering rich computing experiences while dumping established techniques like mouse use and copy-and-paste. Its browser component, by contrast, pretty much provides a normal desktop experience via the standards-compliant Safari browser and small but high-resolution screen. For the most part, then, designing web content for the iPhone simply means designing web content. Ah, but there are tricks that can help your site more smoothy accommodate Apple’s new device. Some can even improve the web experience for all users.
Craig Hockenberry seems to have found them all, and he shares what he knows in a two part series that begins in this issue. I have known Craig since 1996; we collaborated on web-oriented Photoshop filters before Adobe figured out the web. He is a brilliant, funny, and modest man, and now you can get to know him, too.
Both articles are bound to produce thought and argument. Both are at least somewhat controversial. I love them both, and admire both writers. It is a pleasure to share this issue with you.
This issue of A List Apart was produced by Andrew Fernandez, technical-edited by Aaron Gustafson and Ethan Marcotte, art directed by Jason Santa Maria, and illustrated, as always, by the amazing Kevin Cornell. Krista Stevens is acquisitions editor. Erin Kissane edits the magazine.
[tags]design, webdesign, alistapart, håkon, chockenberry, truetype, fonts, typography, webtype, webtypography, apple, iphone[/tags]
Standardistas adore the Mozilla Firefox browser for its advanced support of web standards. (How good is it? The Web Standards Project considered declaring victory and closing shop when Netscape Corp. announced in 1999 that it would heed our advice and dump its non-compliant software in favor of the Gecko rendering engine that powers Firefox today.)
Though Firefox and related Mozilla browsers deserve credit for their unsurpassed handling of everything from the Document Object Model to MIME types, Firefox’s way with text leaves much to be desired, as the following screen shots show. Indeed, if reading is mostly what you do on the web, and if accurate typography makes reading more of a pleasure and less of a strain, then Apple’s Safari is superior to Firefox.
Lucida, Test One: with genuine italics
Zeldman.com is designed to be read in Lucida Grande, and the site originally listed “Lucida Grande” first in its style sheet. Alas, Lucida Grande lacks true italics. Fortunately, Lucida Sans has them. In a version of our style sheets used to capture the following screen shots, we’ve listed Lucida Sans first, Lucida Grande second, and substitutes thereafter. Both browers handle the site like a dream—but it is only a good dream in Safari. Open the screen shots in tabs:
Questions for discussion
- In Firefox, why does the text “now in its second edition. I can’t” display midway between roman and bold, and why is it so poorly antialiased? Apparently, Firefox bungles roman text that follows italics.
- In Firefox, why doesn’t hyphenation work? My gosh, people, it’s nearly 2007. IE5/Mac supported hyphenation.
Lucida, Test Two: using a font that lacks italics
Remember: Lucida Grande does not have italics; Lucida Sans does. But as Test One showed, Firefox can’t handle Lucida Sans correctly. So we’ve revised the style sheet. With Lucida Grande listed first in the style sheet, and Lucida Sans deleted, Safari still trounces Firefox. The experience of reading text is smoothly beautiful in Safari, much less so in Firefox.
Observations
- Both browsers fake the italics. But Firefox does the job crudely: a child could tell that its “italics” are faked. (Firefox slants the roman text.) By contrast, Safari fakes its italics so well (by substituting a true italic from the next available listed font that contains one) that only graphic designers and type hounds will realize that the font they’re viewing contains no true italics. See reader comments for delicious details.
- In Firefox, hyphenation still does not work.
Notes
It’s worth pointing out that these tests were done on Macintosh computers, which are known for their superior handling of text, and that Lucida is not some strange face chosen to prove a point. It is the default font in Mac OS X (not to mention on apple.com). Moreover, Lucida Sans Unicode, the first Unicode encoded font, shipped with Windows NT 3.1 and comes standard with all Microsoft Windows versions since Windows 98.
When I showed a friend and fellow designer these simple tests as I was working on them, he asked if I had reported “the bug” to the makers of Mozilla. But as I count it, there are multiple, overlapping Firefox bugs happening here—too many to fit into a bug-report form. I suspect that the problems have to do with Mozilla’s reliance on its cross-platform display environment. If you scuttle what an individual operating system does well in favor of what a cross-platform environment does poorly, you get what we’re seeing here. It’s not good enough.
Inferences for best practices
If your content will sometimes include italicized text, you naturally want to specify a font that contains italics. That’s just common sense. Unfortunately, as our screen shots have shown, common sense works against you here, because Firefox, although superior to other browsers in many ways, handles text like a drunken fry-cook.
When you specify the font that contains genuine italics (as we did in Test One), Firefox mishandles the roman text that abuts italicized words. When you replace that font with one that contains no italic (Test Two), Firefox fakes the italics crudely, but overall display and legibility are better than the unusable results of Test One.
Obviously there are fewer problems if you limit your website to Verdana and Georgia, but more constraints on typography are not what the web needs.
Discussion is now closed. Thanks to all who shared.
[tags]design, browsers, webstandards, webdesign, mozilla, safari, apple, lucida, unicode, windows, macintosh, osx[/tags]
Categories
Enable caching to upload files
You’re an Apple Safari browser user. After upgrading to OS X 10.4.8, you are unable to upload files to 37signals’s Basecamp via that application’s easy, web-based uploading tools. Or you are unable to upload your logo to Boxes & Arrows’s events listing. Or you are stymied in your efforts to upload your photos to JPG Mag.
The fault lies not with Basecamp or Boxes & Arrows or JPG. Nor is it strictly because you’re using an Intel Mac. Camino, Firefox, and Opera still let you upload images over http. The problem is Safari. But not every Intel-Mac-wielding Safari user suffers from it. Many continue to upload files after upgrading to 10.4.8. They glance pityingly at you out their passenger windows as they speed past.
What is the problem? You’re a web designer. As a web designer, you’ve used a third-party product like Safari Enhancer to disable caching in your browser.
If you don’t disable caching in your browser, then Safari becomes kind of useless to you as a web development tool, because Safari hangs onto files like a junkyard dog clomps onto a postman’s thigh. Safari will hold onto outdated CSS, outdated text, outdated images. You’ll quit and restart. You’ll check your SFTP settings repeatedly, wondering why you keep uploading updated content to your web project, but Safari keeps showing you outdated content.
Safari shows outdated content for hours after other browsers (even browsers with caching enabled) have recognized that something changed. Safari does this because it makes browsing faster for ordinary users who are not web designers. It works. Unfortunately, what makes Safari fast and fun for ordinary users makes it a pain for web designers—unless they disable caching.
Before 10.4.8, you could disable caching in Safari and still upload files over http. After 10.4.8, you can’t. It’s not a feature, it’s a bug. Until Apple fixes it, you can leave caching disabled in Safari and use Firefox, Camino, or Opera as your default browser—or re-enable caching, and add an hour of Stupid Time to your web development and testing process.
[tags]web design, apple, mac, os x, safari, browsers, web development[/tags]
- Berners-Lee: reinventing HTML
-
Tim Berners-Lee, inventor of the web and founder of the W3C, announces reforms:
It is really important to have real developers on the ground involved with the development of HTML. It is also really important to have browser makers intimately involved and committed. And also all the other stakeholders….
Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work.
- 9 to 5 = average
- To be great in design takes passion and work.
- Sending XHTML as text/html Considered Harmful to Feelings
- I love this.
- Web Directions North
- Our Australian friends set up camp in Vancouver, for what looks like a great two-day conference on standards-based design and development (Vancouver Canada, February 6-8 2007). Speakers include Kelly Goto (Gotomobile), Andy Clarke (malarkey), Adrian Holovaty (Chicago Crime, Washington Post), Douglas Bowman (Google Visual Design Lead), Dan Cederholm (SimpleBits), Joe Clark (joeclark.org), Dave Shea (CSS Zen Garden), Cameron Moll (Authentic Boredom), Molly Holzschlag (Molly.com), Veerle Pieters (Veerle’s Blog, Duoh!), Kaitlin Sherwood (Google Maps US Census mashup), Tantek Çelik (Technorati).
- Web Accessibility: Web Standards and Regulatory Compliance
- By Andrew Kirkpatrick, Richard Rutter, Christian Heilmann, Jim Thatcher, Cynthia Waddell, et al. Don’t let the unsexy title fool you. Vast and practically all-encompassing, this newly updated classic belongs on every web designer’s shelf. (Better still, open it and read.)
- I Cannot Possibly Buy Girl Scout Cookies From Your Daughter at This Time
- By Charlie Nadler in McSweeney’s.
- Gemini Girl
- New women’s blog elegantly designed by Ray McKenzie.
- eMusic: 33 Folkways LPs
- Thirty-three important Folkways Recordings for download. Louis Bonfa, Mighty Sparrow, Woodie Guthrie, Henry Cowell and more.
- On having layout – the concept of hasLayout in IE/Win
- Technical but reasonably easy to follow discussion of why Internet Explorer’s rendering of your design may
suckdiffer from your expectations - “Apple’s Backup App is Shit”
- God bless SuperDuper.
[tags]W3C, webdirections, accessibility, haslayout, browsers, mcsweeney’s, folkways[/tags]
Partly because the beta was carefully rolled out over many months, the release of Microsoft’s Internet Explorer 7 has largely been a non-event, for developers as well as journalists. While not at the level of Mozilla Firefox, IE7 is far more standards-compliant than IE6, which was way more compliant than IE5.5, which beat the pants off IE5. To make IE6 render standards-compliant pages correctly, web designers came up with a Wikipedia’s worth of hacks. In IE7, those hacks aren’t necessary; some actually cause problems.
(Here’s a tip from Dan Cederholm, who created the CSS for Happy Cog‘s redesign of Advertising Age: “inline-block is the new-and-improved method for auto-clearing floats.” Use it to replace display: inline-table;.)
IE7 is also the first Microsoft browser to permit user scaling. It does this the same way the Opera browser does it (which is the same way Microsoft Office does it): if text is too small, the user scales the entire page. By contrast, Safari and Firefox use Text Zoom, originally developed by Tantek Çelik for IE5/Mac. In those browsers, if text is too small, the user scales the text size—and nothing but the text size. Images, column widths, and so on, typically do not scale (unless the web designer is doing something really tricky).
There’s a huge difference between Text Zoom and Page Zoom, and it will affect the way designers spec type sizes for the web. It didn’t matter much when only Opera scaled the page. It was a neat feature of Opera; but Opera’s neat feature didn’t affect the way standards- and accessibility-oriented designers approached text size. But market share matters. Once IE7 gains critical mass, a lot of our current thinking about ems and pixels and such will go out the window. I’ll write about that soon, probably on A List Apart.
Meantime, developers are focused on the persnickety stuff: Ajax and JavaScript compatibility problems, CSS bugs that didn’t quite get fixed, and CSS hacks that no longer work.
Like me, you may have heard from a client whose site you designed before IE7 existed. What problems have you encountered? What hacks have you jettisoned, and with what have you replaced them? (Please include URLs.)
[tags]css, IE7, bugs, hacks, workarounds, design, webdesign, tantek, dancederholm[/tags]
Reader Adam Engelsgjerd writes:
I develop and maintain websites for the University of Arizona Library. We make use of the “Holly Hack” to avoid the IE6 peek-a-boo bug for our intranet site (God bless Holly). In the course of testing our sites against IE7 I noticed that the bug was rearing its head again‚ despite claims that this latest version has fixed it.
Further investigation revealed that while IE7 really does seem to have fixed this peek-a-boo bug the Holly Hack has, with decidedly sardonic irony, reintroduced the very problem it was created to circumvent.
This morning I tested and just implemented a fix that seems to work for us: the removal of the universal selector, “*‚” before the “html” selector. So the traditional Holly Hack is:
/* Hides from IE5-mac \*/
* html #contentWrapper {height: 1%;}
/* End hide from IE5-mac */
Our new code is now:
/* Hides from IE5-mac \*/
html #contentWrapper {height: 1%;}
/* End hide from IE5-mac */
I’ve tested this against the following browsers on Windows XP SP2:
IE7
IE6 (SP1 standalone install from evolt.org and SP2 full install)
IE5.5 (standalone install from evolt.org)
Netscape 7.2 and 8.1
Opera 7.11 and 8.54 and 9.00
Firefox 2.0
And on Windows 2000 SP4:
IE6
Hopefully this can be of some use should others be running into this same problem.
[tags]css, browsers, IE7, bugs, hacks, workarounds, holly hack[/tags]