I <3 IE8

No, not really. 

On our recently completed Vogue Archive project, IE8 support was a requirement, due to a large number of potential users being stuck at the office on Windows XP with no freedom to install a better browser.  (We had a similar requirement for Firefox 3.6 support, but nowhere near the same kind of trouble with that browser though it was definitely the second worst browser in our field).

Background

The Vogue archive is an HTML5^* + Silverlight application: we have two viewers, one built in HTML5 (for tablets and desktop browsers that support it), one built in Silverlight (for all desktop browsers). Both viewers are housed within the same HTML5 "chrome" - see yellow sections in the image below:

IE8, of course, was released years before HTML5 started its meandering way through the standardization process, so it should hardly be expected that IE8 should support HTML5.

Mmm, Cookies!

It should be expected, however, that IE8 could support HTTP cookies properly.

Not so much.

We got an error report from the field that when IE8 users logged out from the archive, and then logged back again, the logon process went through, and then promptly redirected them back to the unsecured welcome page at the start of the logon process. Hm.  Sure enough it did.  The excellent error report also stated that for some reason they were seeing two authentication cookies, one of which was empty.  Could that have something to do with it?  Huh? 

[Quite some time later]

The problem was indeed related to the double-cookies, but it appears it was actually caused by how IE8 interprets cookie expiration dates:

The standard way to delete a cookie is to create a new cookie with the same name, in the same domain (and path), with an expiration date set to a date in the past.  A pretty standard date to use is the 'epoch' start date (JavaScript's beginning of time) - midnight of 1/1/1970, GMT, represented as "Thu, 01-Jan-70 00:00:01 GMT;"

For whatever reason, IE8 sees this date, and attempts to convert it to local time - in our case (EDT) 4hrs earlier: 12-31-69 08:00:01 PM.  Slight problem - since '69 was before the start of the epoch, this is then further interpreted as meaning 2069 (never mind the second bug that a winter time should be converted using EST - aka GMT-5hrs).  So rather than creating a new cookie that immediately expired and thus was deleted, we ended up with a new very long-lived cookie.

To complicate things further, as a brute force way for us to make sure we delete both local and domain cookies (we don't know the preference of the client), in our delete-cookie script we actually create two expired cookies, one for each domain (i.e. vogue.com and archive.vogue.com).  It appears the login/logout process got confused and sometimes read one cookie (empty, expiring in 2069) and sometimes the other (valid session cookie).

Solution

While the analysis was complex, the solution was simple - we now use an expiration date of 1/1/2000 rather than 1/1/1970 - now IE can convert times all it wants, and it still stays a date in the past, and the cookie is expired.

Tell Them Again

I <3 IE8.

idea: bookmarklet to persist personal form data in localStorage

As a developer, I frequently have to clear my browsers cache, and also cookies, in order to test a site.  This is a PITA as now I'm logged out from Google, PivotalTracker, etc, etc.

It also showcases how very few sites store login information in localStorage by default (note to devs, if you're to offer a "Remember Me" button, use localStorage, not a cookie). 

So my idea is this: a set of two bookmarklets: the first would retrieve any form data entered in a form (prior to you submitting it) and store that data in localStorage, then the second would fill out a form using the data stored in localStorage for that site.

What about security you might ask?  Well, clearly this should only be used on a personal computer - and maybe password fields should be excluded in any case.  But this is stored locally, it is not transmitted anywhere, and the data is not accessible to any other site, so the data should stay between you and your computer.  One exception would be any potentially malicious script hosted on the site, but that seems like a risk in itself - the same script could much more effectively simply grab the form data on entry.

So - good idea or bad?

A non-trendy way to wrap text to the width of an image

Say you have an image, whose width is unknown.  You want to display a caption below the image, and the length of the caption text is also unknown.  How do you display the caption so that the text wraps to the width of the image?

As far as I know, there is no way to do this with divs and Css.  It *may* be possible to do it with figures and figcaptions, but now you’re in Html5 land, and to support older browsers you’ll need to do gymnastics.

You could use an img load event handler and resize the caption after the image comes in, but now you have to add javascript for something that should be handled by your html.

So you use tables.  Yes tables, those horrible, horrible remnants of Web 1.0.

And you do it like this (though your styles would obviously be in a css stylesheet somewhere):

<table>
<caption style="caption-side: bottom; margin: 0 5px;">Oh caption, my caption! our fearful task is done!<br>
The layout has weathered every wrack, the prize we sought is won</caption>
<tr><td><img alt="some unknown sized image" src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Ocaptain.jpg/394px-Ocaptain.jpg">
&/lt;tr></table>

which renders thusly (Live writer may corrupt this - sorry view-sourcers):

Oh caption, my caption! our fearful task is done!
The layout has weathered every wrack, the prize we sought is won

---

Also see http://jsfiddle.net/austegard/fGwve/

archive.rollingstone.com – another feather in our cap

With the successful launch of the new iPad-enabled Rolling Stone Archive, I figured I’d take the time out to congratulate our client, Bondi Digital, and my team at Applied Information Sciences (AIS): Jim Jackson, Robin Kaye, Ian Gilman and Siva Mallena  (with additional help from Leslee Sheu and Kevin Hanes).

Built on the same technology that we used to launch i.Playboy.com, the Rolling Stone archive combines our Silverlight viewer and the Html5, touch-optimized iPad viewer in a single site, sharing peripheral components such as menus and search features.  Per client requirements for Rolling Stone all desktop users will get the Silverlight-based viewer, with its keyboard and mouse integration, and deep zoom of images, while iPad users are automatically switched to the Html5 viewer.

Building and optimizing a highly graphics intensive app like this for the excellent, but admittedly limited, iPad browser has been a thoroughly enjoyable challenge. Showcasing our work to the public through another premier publication like Rolling Stone makes it all the more satisfying.

Our team is already onto the next publishing project – stay tuned…

"Microsoft has completely lost the web development community."

Last year Mark Pilgrim released a free e-book/site called “Dive Into Html5” (http://diveintohtml5.org/).  The site/book has served as a valuable resource on a recent Html5 project we’re working on here at AIS, and I have frequently gone back for details on topics such as local storage and canvas.  It is an excellent book for any bleeding edge web developer.  It is so choice. If you have the means, I highly recommend picking one up.

This week, Mark posted his observations on how publishing a free e-book (which is also purchasable in print format) works well for him, and that it gives great insight into what parts of the book are being read, and by whom. He then makes the following observation:

6% of visitors used some version of Internet Explorer. That is not a typo. The site works fine in Internet Explorer — the site practices what it preaches, and the live examples use a variety of fallbacks for legacy browsers — so this is entirely due to the subject matter. Microsoft has completely lost the web development community. (emphasis mine)

I forwarded this internally within AIS, and a nice debate ensued.  One common complaint was the hyperbole of the statement, and I agree; a more accurate line would likely be "Microsoft as a browser vendor has lost significant mindshare in the bleeding edge web development community."

Personally one of the things I love about Html5 (using the term the way the hypers would – to mean modern web development with client-driven UI interactions using JavaScript, CSS(3) and some HTML5 semantics) is that it has in some ways unified the web development community:  The debate a few years ago was about JSP vs .NET vs PHP vs Python vs Rails vs someotherservertechnology.  Folks from different camps seldom interacted and learned from each other.  With Html5, the backend processes are completely irrelevant, as long as they don’t muck with the Html (ASP.NET webforms is still a major sinner here, unfortunately) and developers using all sorts of backend software and operating systems are now adding to the collective knowledge, mostly working towards the common goal of getting as much functionality as possible, pushed to end users through mostly standards compliant browsers. 

For instance, our Html5 app is backed by ASP.NET MVC 2 and SQL server.  We do all our development on Windows, in Visual Studio – we’re looking to deploy to Azure.  Clearly we’re MS developers.  But we could just as well have done the app in Php against MySql running on linux and apache, and we’re taking cues from folks using python, java, Rails, Node.js, php and God knows what on the backend.

At the same time I haven’t used IE by choice for about 5 years, maybe more…

I was asked what I thought MS could do to gain back some developer mindshare – so here goes:

• My thoughts are that if Html5 and the set of bleeding edge technologists that go with it are any kind of priority for MS,  they need to do some or all of the following:
• Find a way to upgrade the legions of IE 6, 7  and 8 users to IE9.  This will obviously not be easy,  but they could do something similar to what Google did with Chrome frame (i.e. make IE9 a plugin for the older browsers),  or they could do something like the makers of the “IE Tab” Chrome and Firefox extensions do,  allow IE to be hosted inside Chrome,  and only activate it for certain sites.  Or let users install IE9 side by side with the older versions.   All of these would have as goal to encourage end users to use the latest possible browser for the task they need it for,  and to make them install IE9 instead of Chrome or Firefox.
• Make IE9 the paragon of standards compliance.   (They are actually getting close to this...)
• Bring IE9 to WP7 and whatever tablet software they're coming out with.
• Reduce the focus of Silverlight as a browser plugin,  and make it more about web-deployed desktop apps.
• Drastically improve the support for css and javascript in Visual Studio, including debugging and unit testing.   And give this toolset away in the form of VS Express.
• Evolve the Dev tools in IE9 to become better than Chrome's inspector and the Firebug plugin.
• Separate the IE development from Windows to allow quicker iterations
• Do more things like the jQuery deal. The world of CSS is a mess (we desperately need mixins and code forks like those provided by media queries), MS could take the lead here…

The point is, whether Mark’s browser percentages are statistically valid as an indication of web developer’s preferences, or to what degree Microsoft is lagging/losing developer mindshare; these are not the pertinent questions.  The fact is that Microsoft is now not a leader in emerging web development areas – maybe they never were – but should they want to be, they need to take action. IE9 is shaping up to be a great browser, and they need to push it aggressively.

CSS3 Fun

Today I learned about two new CSS3 rules that both work in newish webkit (Chrome/Safari) browsers.  We can FINALLY vertically align elements in a div, without resorting to use/simulating of tables, by using box-sizing.  About freaking time.  And you can now also resize elements in the client.  I clearly need to read up more on what’s coming in CSS3…

Example (you'll need a newish webkit (Chrome/Safari) browser):
You can resize the div below – see how the image always stays centered?

Source:

<div style="display: -webkit-box; -webkit-box-align: center; -webkit-box-pack: center; resize: both; overflow: hidden; width: 200px; height: 200px; background-color: black;">
<img src="http://www.appliedis.com/images/tagline_01.gif" style="max-width:100%; max-height: 100%">

IE 9 HTML5 Testing: “Works on My Machine”

One of my esteemed colleagues on an internal forum posted about how great IE 9’s HTML5 support was, based on the result of Microsoft’s test pages.  MS’s tests are sadly self-selective however: meaning they only seem to test for elements that IE9 supports: http://samples.msdn.microsoft.com/ietestcenter/

“Cross-browser Test Results Summary:

W3C Web Standards	Number of Submitted Tests	Internet Explorer 9 Platform Preview	Mozilla Firefox 3.6.3	Opera 10.52	Apple Safari 4.05	Google Chrome 4.1
HTML5	40	78%	63%	48%	43%	43%
...”

Compare that to my own results running html5test.com on the 6(!) browsers I have installed:

Html5 is the first time in a decade that the browser vendors have had a new major standard to fight over; I’m just grateful that this time around we’ll have an army of frameworks such as jQuery that can level the development playing field for us.

Enabling Support for HTML 5 Schema Validation in Visual Studio 2010

Out of the box, HTML 5 schema validation is not supported in Visual Studio 2008 and 2010.  The folks on the Visual Web Developer Team rectified this for VS 2008 and Visual Web Developer, but they did not provide any update for VS 2010 (that I know of).  No matter, you can use the 2008 version – here’s how.

1. Download the schema update for VS 2008/VWD

2. Open the downloaded zip file and follow the instructions in the ReadMe.txt file except:

2.a) Where it says to add the schema to C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Packages\schemas\html, replace the 9.0 with 10.0 – the path for VS 2010 (in 64 bit Windows) is:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Packages\schemas\html

2.b) Edit the VS registry file matching your Windows environment, and again change the 9.0 to 10.0 – e.g. for my Windows 7 64 bit machine the correct registry file is:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Packages\{1B437D20-F8FE-11D2-A6AE-00104BCC7269}\Schemas\Schema 23]
"File"="html\\html_5.xsd"
"Friendly Name"="HTML 5"
"URI"="http://schemas.microsoft.com/intellisense/html-5"

3. Back up your registry

4. Run the registry file (as always, take caution)