Topic: IE7

Keeping up with Firefox 3: The agony and the ecstasy of full page-zoom

Brian Dillard, Wednesday, February 27, 2008 @ 5:50 pm

I've been playing with the page-zoom feature in Firefox 3 Beta 3. Thanks to the hard work of the Mozilla folks, Firefox is now the third major browser (behind Opera and IE7) to support this feature. (Safari, of course, supports page zoom on the iPhone but not yet on the desktop.) I don't know whether to be elated or annoyed.

A little background: For years, browsers have allowed users to scale the font-size of any web page using built-in browser controls. The text would get bigger, but other page elements wouldn't. Increasing your font size wouldn't affect the layout of the page at all. If sites weren't careful about how they built their CSS, absolute positioning and fixed-width elements would conflict with the zoomed-up font sizes. The result wold be pages where the main content was readable, but navigational and chrome elements looked grotesquely distorted or in some cases disappeared into the seams of the CSS (see photo below).

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Ajax, Browsers, Running Out of Time

Dietrich Kappe, Thursday, November 15, 2007 @ 5:12 am

History repeats itself, first as tragedy, second as farce. -- Karl Marx

I can remember the day, back in 1994, when I abandoned the Mac for Windows. It was a gloomy, overcast day when I made that bittersweet decision -- I was a Mac and Unix nerd all through college -- but after my twelfth or thirteenth crash of the day, I had had enough. Photoshop, Netscape, Secure Shell and Word were just not meant to run more than one at a time on Mac OS 7. Had I stayed with Apple through that rough patch I'm sure I would have been slimmer, sexier and happier, but NT 3.51 only crashed twice a day, so my hand was forced. I  ran out and bought a PC that very day.

Now I fear history may be repeating itself. Yesterday, I had Firefox 2 for linux crash 5 times, and IE7 for XP crash 7 times. The cause? Too many fat Ajax applications. Zimbra, the whole Google bestiary of applications, Yahoo Mail, etc.. These are all long running applications that I keep open for most of the day. Then all of a sudden the Browser is gone and I have to relaunch and login all over again.

I'm not alone in this. Colleagues and friends report similar problems with Safari/Mac, IE7/Vista, Firefox/Mac. I've even checked with a friend that runs the helpdesk for a large firm: reported problems with browsers are up. The only one who seems blissfully unaffected is the lone Opera nerd in my office. He just keeps chugging along with what seem like 200 open tabs.

The cause should be evident to everyone. We've taken what was first called LiveScript -- a crufty embedding just good enough to validate a form or two -- and we've abused it into being the foundation for a whole new kind of application platform. The browsers have just not kept up and the situation will only get worse with the accelerated proliferation of Web 2.0 apps.

Help is on the way, in the form of bytecode interpreters and vm's for Safari and Mozilla, though the future of IE is still cloudy (still, there is a plan to bring Tamarin to IE). But if the new Browser version don't arrive quickly enough, or if they don't fully solve the problem of browsers crashing once an hour, then a mass migration to Opera may be the best we can hope for. At worst, content and application producers will opt for more stable non-Ajax alternatives such as Flash or Silverlight.

Ajax and the browsers it depends on are running out of time. If the notion spreads that it isn't reliable, it will be as dead as the Java Applet, never to be heard from again.

• Digg
• Reddit
• del.icio.us

Comments (9)

Software Development

DOMContentLoaded and the quick rise of de facto standards

Brian Dillard, Tuesday, November 13, 2007 @ 10:28 am

There's never been a better time to be a JavaScript developer. JS hit the big time with the advent of Ajax, and overnight client-side programmers went from being the redheaded step-children of the web-development world to front-and-center participants in the RIA revolution. Even if you're working on a team of one, there's a thriving global community of JavaScript gurus constanly pushing the language forward, working out browser kinks, demonstrating how to import concepts from other languages and computing paradigms, and otherwise inspire you. It's a big change from 10 years ago, when you had Webmonkey and the David Flanagan book and a few cookbook-style compendiums of tips and tricks. This is seriously the golden age.

Working for the last couple of months on Really Simple History, though, I've become interested in the way specific techniques become the flavor of the month and quickly redefine how we conceptualize "good" JavaScript coding practices. Take, for instance, DOMContentLoaded. After the first version came onto the scene, within a matter of months we had many competing implementations of the basic concept that your scripts shouldn't have to wait for window.onload to fire before getting down to business. Now, DOMContentLoaded is the de facto start point for many, many JavaScript applications. Heck, it's even the basis of the entire jQuery event model. There's nothing wrong with that, but widespread use of Ajax toolkits can conceal the fact that DOMContentLoaded is just a collection of hacks. It works, as long as our toolkits keep iterating one step ahead of the browser vendors. But do we really need it?

At Orbitz Worldwide, my previous employer, we implemented a first-rate unobtrusive-JavaScript architecture. (See it in action at Ebookers UK.) Everything was progressively enhanced from dumb markup. That meant our application worked just about everywhere. But it also meant lots of DOM parsing and initialization that couldn't begin until window.onload. As our application grew, this caused enough of a UI flicker - form controls turning into widgets, links morphing into Ajax calls - that we needed to jump the gun on window.onload if we wanted a good experience for the majority of users ... the ones with modern, JS-capable browsers. DOMContentLoaded made sense, and architect Nik Krimm pounced on it.

But for a large subset of websites, there really isn't THAT much difference between window.onload and DOMContentLoaded. If you're merely adding an unobtrusive behavior layer to a traditional, content-driven website, chances are that good old window.onload will perform just fine. There's usually little reason NOT to use DOMContentLoaded. But unless you are developing a desktop-style webapp or implementing progressive enhancement on a foundational level, it's not really necessary. And in certain cases, it just flat-out won't work.

An enthusiastic beta-tester discovered such a case when trying to initialize RSH's dhtmlHistory object from DOMContentLoaded. It broke, and I immediately knew why: RSH relies on the ability of modern browsers to auto-save form data for the life of a session. RSH uses a hidden textarea to cache serialized Ajax application state and render the back button useful again. Internet Explorer doesn't repopulate the cached value of that textarea until an instant after window.onload. If you try to access that cache during DOMContentLoaded, it simply isn't there. This is true of both IE6 and IE7. Therefore, you need to wait for window.onload.

I'm not really sure there's any big conclusion to draw from this example. As I said, it's just interesting to me that in the space of a year or two, DOMContentLoaded has become a de facto standard. As we pile browser hacks on top of one another to push the web forward, sometimes they're going to conflict. Luckily, we can always peek past the curtains and figure out what's  going on behind the scenes.

• Ajax
• JavaScript

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Coming soon: Really Simple History 0.6 beta

Brian Dillard, Tuesday, October 23, 2007 @ 1:24 pm

Late tonight over at Google Code, I'll be posting a beta of Really Simple History 0.6 for testing. The goal is to elicit help from RSH users in chasing down any bugs I've failed to catch, then push out a stable release around Halloween.

I've tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I've didn't quite get there, but I got close.

Features in the new version include:

• Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
• Full support for Safari 2/Mac (though I'm still trying to eliminate the "infinite loading" bug before I push out the beta).
• Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
• Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
• A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.

As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.

So what is Really Simple History, and why am I updating it?

An Ajax bookmarking and history-management framework originally developed by Brad Neuberg, RSH became my responsibility a little over a month ago. I tinkered with it for a few weeks, then finally camped out with it for most of the past week to get a release out.

This is the first time I've ever contributed in this manner to an open-source project. It's been a lot of fun, but it's also been maddening, as anybody who's ever dug into the bowels of cross-browser history management can tell you. Here's a sampling of what I've learned from RSH:

Safari is crazy

Plenty of people who've worked on Ajax bookmarking projects have commented about this, but it only becomes clear once you've actually seen it in action. Getting this thing to work in Safari 2 for the Mac took a wildly disproportionate amount of time considering its market share. I wouldn't have been able to do it without Bertrand Le Roy over at Microsoft, whose blog entry on the development of the .Net history manager pointed the way for both Safari and Opera.

As Le Roy and others have noted, the Safari 3 Windows beta is so buggy that history management is hopeless. You can enable the back button for Ajax apps, but once you use it, the forward button becomes disabled. I noticed yet another wrinkle in this behavior (skip ahead if you're easily bored):

Navigate to a non-RSH site - Google, for instance. Then travel to an RSH site, create some history entries via RSH, and use your back button. The forward button stops working: a known bug. Now keep hitting back until you get back to Google again. Suddenly, your forward button works again. Hit forward and land back in your RSH app. Magically, the forward button continues to work.

If I hadn't spent so much of the last week lost in Safari-land, this interesting behavior might be worth further investigation. For now, I'm just hoping the Safari 3 team fixes this before the final Windows release.

Don't try to retire document.write just yet

A couple of different RSH users suggested getting rid of Brad's original calls to document.write in favor of standard DOM methods for adding elements to your page. That approach worked for some elements, but not for others.

In IE, RSH writes a hidden iframe into the document and uses the location and history of that iframe to help it track application state. Writing the iframe with document.createElement works just great.

But for all browsers, RSH uses a hidden textarea to store the entire history stack behind the scenes. This powers one of RSH's coolest features: its ability to retain history even if you navigate away to another site and then come back to your RSH application. This works because modern browsers retain form-field values throughout an entire browser session. But they do so only for form fields that exist in the DOM natively - that is, exist in the actual HTML markup or get inserted via document.write get inserted into the DOM before it's finished loading. 

If you create a form element after your DOM is already loaded, the browser has no way to persist values in that element after you leave the page. Each time the page loads, even from the cache, you essentially create a virgin new form field. I'm therefore using document.write for the hidden textarea - and for the hidden form field I've added to RSH for Safari support.

UPDATE: As it turns out, it's immaterial whether you use DOM methods or document.write. The important thing is to use either method before onload fires. I ended up using document.write in the 0.6 beta because of SSH concerns and the fact that it's so much more concise. For more on this topic, see this subsequent post. 

Because of the way RSH is structured, these elements actually get written to the head rather than the body of your document. Still, it works, and it should only offend the most anal-retentive of standards geeks. After all, if you're hacking the browser 10 different ways from Sunday just to enable Ajax bookmarking, then inserting a bit of non-validating markup via JavaScript is hardly the worst of your sins.

RSH won't be hitching its wagon to [insert name of your favorite framework here]

A few users suggested rewriting RSH in Prototype so it would be more compact. I appreciate the impulse, but I think that defeats one of RSH's chief virtues: the fact that it's written in Plain Old JavaScript and doesn't lock you into any specific Ajax framework. It plays well with any library you want it to: Prototype, jQuery, YUI, whatever. (If it doesn't, please file a bug so I can find out why.)

A little JSON never hurt anyone

The one library that RSH does require is a JSON parser; it ships with the latest open-source version. RSH 0.4 included an earlier version of the parser in the same file as its native code; I've broken it into a separate file under the logic that many users will already be serving a similar library. RSH's methods don't actually call toJSONString or parseJSON directly; instead, I've provided bridges so that you can hack in your own JSON methods without having to modify the guts of RSH itself.

Future roadmap

I've got quite a punch list for the next release:

• Provide minified versions of RSH and JSON for download
• Make use of Crockford's module pattern for better encapsulation
• Add official support for Linux browsers, Safari 3/Mac and Safari 3/Win

That's the future. For now, I have to get 0.6 packaged up and ready for testing. Check Google Code late this evening or first thing tomorrow.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Really Simple History: Onwards and upwards

Brian Dillard, Wednesday, September 12, 2007 @ 5:25 am

I'm excited to announce that I've heard the call and volunteered to tackle maintenance and stewardship of Really Simple History, Brad Neuberg's intuitive, lightweight Ajax history library. Brad developed RSH a couple of years ago, drawing inspiration from the Dojo Toolkit folks to deliver a standalone library that provides back-button and bookmarking support for Ajax apps in IE6 and various Gecko-based browsers. Since, then, many additional Ajax frameworks have implemented back-button and bookmark support, some of them drawing on Brad's work.

Meanwhile, Brad's been too busy with other projects to upgrade RSH for a variety of new and existing browsers: IE7, Opera, Safari/Mac and Safari/Windows. I asked Brad to let me take care of his baby for several reasons. For one thing, I've been an enthusiastic user of the library. For another, I've been wanting to get involved on a more formal basis with open-source JavaScript projects. But most of all, I believe RSH remains a great tool for folks who want a solution to the Ajax history issue without the overhead of a larger Ajax framework.

I'm currently working with Brad to migrate RSH to Google Code, get acquainted with the bug base, and start tackling the thorny issues surrounding Ajax history support in the 2007 browser landscape. I look forward to shamelessly pilfering the many fine solutions uncovered by a large community of developers since Brad's initial work. (Brad was kind enough to point me to this blog post from Bertrand Le Roy, which lays out many of the aforementioned fine solutions and thorny issues.)

In the meantime, I'd love to hear from RSH users about their hopes for the future of the framework. Comments, please, or ping me directly at bdillard (at) pathf.com. Thanks!

• Digg
• Reddit
• del.icio.us

Comments (12)

Software Development

IE6: The zombie browser

Brian Dillard, Wednesday, September 5, 2007 @ 5:45 am

Paul Graham's much-dissected essay Microsoft is Dead offers some witty and perceptive analysis, but it sidesteps the fact that Microsoft's rotten corpse will take decades to decompose. In the meantime, we still live in a world where most people trawl the Internet with a Microsoft browser. I've already linked to Kevin Hale's perceptive essay On the Tenacity of Internet Explorer 6, and I've already covered Eric Meyer's useful techniques for taking advantage of IE7's power while continuing to support IE6. But I've got a few more links to add to Dietrich's and my back-and-forth about the state of JavaScript tooling. I regularly stop by the IEBlog the same way I keep tabs on the neighbors I don't really like but have to live near. They recently added a more in-depth post about Ajax View, a pretty cool profiler that they'd previously covered along with other IE development tools earlier this summer. In a previous post, I surmised that most front-end developers code for Firefox first, then put off their Safari/Explorer testing till the end. Maybe if IE tooling continues to mature, we'll see less of that.

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

An Event Apart Chicago: Day 2

Brian Dillard, Wednesday, August 29, 2007 @ 9:03 am

Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here's my sequel to yesterday's day-one overview. I'll be back Friday with analysis and afterthoughts.

Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the javascript: URL pseudo-protocol. His most extensive example showed how to code a graphical widget for the assignment of star ratings so that it would degrade gracefully into a standard HTML select box in less capable browsers. After discussing the difficulty of making XHR functionality play nicely with bookmarks and the back button, Keith acknowledged that his parting message - when in doubt, leave XHR out - was a bit of a copout for the author of an Ajax manual.

Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms - from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons - can cut the time it takes to complete them in half. Wroblewski's most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do - buy your product, join your site or begin creating content - you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.

Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices - or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order - the sequence in which nodes appear in your markup - can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page - and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone's examples argued persuasively for the continuing relevance of web standards.

After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn't going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6's CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6's continuing market share, Meyer advocated the use of Dean Edwards's IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.

The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators - and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

IE7 Security Vulnerability Discovered

Dietrich Kappe, Friday, October 20, 2006 @ 8:00 am

I've been on the road and had a little registry crapout (makes me feel all warm and fuzzy about the "all stick and no carrot" release of Vista), so I've been postponing the upgrade to IE7 until I've had a chance to get home and restore from backup. Right now I actually feel pretty fortunate that I've been unable to upgrade.

Is anyone surprised that a security vulnerability has been reported for IE7? This site claims that there is some sort of cross domain vulnerability in IE7. Reading the code a bit, it looks like the back end site can redirect an XHR request to a site of it's choice using a 302 HTTP redir. Why is this a security vulnerability? Imagine that you work for Goldman Sachs and you are accessing a nifty social bookmarking site villa.ino.us. This site makes an XHR request that redirects you to intranet.gs.com, or whatever the super secret internal intranet is. With a little bit of cleverness, you can adapt some of the http vulnerability scanning scripts to make use of this hole.

Scary business. This hole needs to be closed and quick.

Update: Looks like the actual attack vector is Outlook Express, not IE7. Still a problem, just a different source.

Technorati : ie7, security

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

Whither Canvas?

Dietrich Kappe, Monday, September 25, 2006 @ 11:03 am

This world is but canvas to our imaginations. -- Henry David Thoreau

First support for the WhatWG canvas element was announced by Apple in Safari, then it was included in Opera and Firefox. A little while back, Emil did a cool hack with VML to produce a subset of functionality as canvas for IE. There was a rumor that google would release this or some other code as its Canvas for IE solution, and it sort of has, landing with a thud over at sourceforge with a Google Code imprimature.

There have been no apparent developments since then. It doesn't seem to have been widely tested, is much slower than canvas in Firefox, and has enough differences and functional gaps to make integrating it with Javascript libraries that build on the canvas tag somewhat difficult.

There don't appear to be any plans to support canvas in IE7, but things can change quickly over there, apparently. So, do you support canvas in IE with an impressive piece of late night hackery like Emil's work, or is support for canvas just not there yet -- a really nice feature not supported effectively for 90% of the web browsing public?

I'm leaning toward the latter. What do you think?

Technorati : canvas, firefox, ie

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

The Effects of Unbreaking IE

Dietrich Kappe, Wednesday, September 20, 2006 @ 1:00 pm

I was listening to Audible Ajax Episode 18 -- the interview with the IE7 team -- yesterday, and about halfway into the podcast, I heard something that had me fall out of my chair with laughter. One of the guys (sorry, they all look alike on a podcast) mentioned that if you surf the web for a prolonged period of time with IE7, you begin to see little anomalies in presentation, functionality, etc. If you dig a little deeper, you see that people are depending on IE6 quirks and bugs to get their sites to render and perform correctly. Aside from the hillarity of everyone having to unquirk their sites and applications when IE7 comes out in general release, it is an object lesson in how Microsoft can embrace and extend a set of standards even if they don't mean to.

Hopefully the IE releases will be coming faster now, and bugs won't have a chance to be enshrined as standards anymore.

Technorati : ie7, quirks, standards

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development