Browser snooping – again

The recent ALA article documenting IE8’s version targeting system has created a storm. And while I’m certain that a lot of the opposition stems from dislike or distrust towards Microsoft there is a lot of validity to the opposition.

Jeffrey Zeldman a supports the IE teams decision on pragmatic grounds, which I can understand. But not accept.

Jeremy Keith has a slightly better view of the whole matter. As a web developer, I’d agree with Jeremy. As such the option isn’t bad, but the default behavior is wrong. Microsoft and the whole web standards movement could benefit immensely if the launch of IE8 would be marketed as an step towards the future with and optional way to stay backwards compatible.

I suspect most clients with mission critical web systems would quickly ask their developers if anything needs to be done to ensure the systems will work fine. With IE7 Microsoft didn’t really market the improvements in its rendering to the general public which meant that clients and developers outside the loop of standards awareness were caught by surprise. I’m quite certain that it wouldn’t be too large of a challenge to the marketers at Microsoft to come up with a campaign to educate the general public on the benefits of either turning on the IE7 rendering mode or developing their sites further to really work.

That is, if I’d support the whole idea of leaving a legacy rendering engine in place.

As a software engineer I shudder with the whole idea that the IE team is presenting. How many times have you heard that the problems with Windows (or any other software product) comes from the necessity of supporting legacy systems? How many times have those issues caused serious bugs, security problems or development headaches and slipping timetables?

By far, my worst fear with this approach is the headaches that will be caused when we’re at IEx (where x > 8) and the OS APIs etc need to change. Is the change possible, or will we face a situation in which Windows development (or IE development) suffers because backwards compatibility must be maintained? The more time passes, the less reliable the basic IE7 codebase will be.

While many may argue that it’s just a browser, not an OS etc. I don’t believe that the relative smallness will save IE from the problems that maintaining exact backwards compatibility will cause. I’ve seen more than a fair share of small, medium, and large projects struggle with backwards compatibility issues. Throwing more resources at a larger and more complex project isn’t a magic bullet.

However, it seems as if this aspect won’t be a consideration. So I’ll join Jeremy in voting that IE=edge rendering be the default. I’m also quite certain, that the PR value of this kind of change would be better for MS. At least better than not advertising the technical advances that the browser has made.

P.S. I wrote this while debugging a heap of J2EE code for an obscure but caused by backwards compatibility, so I may also be biased.

Update: At least Robert O’Callahan also shares my doubts on the maintenance issues.

Background images and tables

In developing a new version of our website (our personal site), I encountered an odd bug that seems to affect IE6, IE7, Safari 3 (beta, windows) and Konqueror 3.5.6. Opera 9 and Firefox 2 at least are unaffected by the issue.

The issue comes from having a semantically marked up table in which a tbody is given a background image (with CSS naturally). The idea is to create a table that looks like the image below (screenshot from Firefox).

A picture of the styled table in firefox

To achieve this, the following styles are applied:

.pedigree {
	empty-cells: show;
}

.pedigree td {
	border-bottom: 2px solid #4a4a4a;
    border-left: 2px solid #4a4a4a;
    padding: 3px;
    font-weight: bold;
}

.pedigree td span {
	font-weight: normal;
}

tbody.sire {
	background: #cbcbcb url('images/pedigree-topright.png') no-repeat right top;
}

.pedigree .fmRight {
	padding-right: 10px;
}

.pedigree .fmS {
	border-left: none;
	background: url('images/pedigree-topleft.png') no-repeat left top;
	padding-left: 10px;
}

.pedigree .fmS, .pedigree .fmSS {
	padding-top: 10px;
}

.pedigree .fmSSS {
	padding-top: 20px;
	padding-right: 20px;
}
/* Similar styling continues for the lower half as well */

When I began testing the layout with IE is was surprised when the end result was:

A picture of the styled table in IE

What really threw me off was that the same was visible in Safari 3 (Windows, beta) and Konqueror. Because the bug wasn’t limited to IE, I went and rechecked the CSS spec to see what it says about background and inheritance.

When it comes to inheritance, backgrounds are never inherited and the default values are none for the background image and transparent for the color. So, based on how I read the spec, Firefox and Opera get this right and the others are wrong.

To fix this, IE6/7 were easy as I simply used a conditional stylesheet to turn off all background images (and add some borders). Finding a workaround for Safari or Konqueror has left me stumped however.

No combination selectors to specifically set the background image of individual cells as none worked.

I’ve tried searching for this problem, but either I can’t come up with the correct combination of terms or I’m the first one to notice it.

I’ll put up a link to live versions of this table once our site is finalized and live, until then you’ll just have to imagine the table markup (or ask me for it).

WordPress and custom URLs

While customizing WP to suit the needs of our public site at work, I noticed some interesting issues with how WP (at least version 2.0.x) handles customized paths. If I start the permalink URL with /current/%category%/… and set the category URL as /current, the category archives will open, but the permalinks don’t work.

This strikes me as odd behavior, if not a bug. And no, I haven’t searched to see if someone else has reported this issue or entered it as a bug. I don’t have the time now.

P.S. randomfire’s been neglected for a long time. Hopefully soon I’ll have the time to work on a new layout and such.

Liquid layouts, background-position, and percentages

In a recent web design project I’ve been fiddling around with liquid layouts (i.e. layouts which change size depending on font sizes defined by the browser or the browser’s windows size). The faux columns technique described by Dan Cederholm has already been an often used tool in my development projects, so creating equal height columns wasn’t a new prospect.

Because of the design, I wanted to use percentages as the widths of the two columns. In this case, I wanted the main content to span the first 70% and the sidebar should take up the rest. Positioning the background became a challenge for me that I needed to find a way to overcome.

Bloglines woes

A reader of the Life of Jalo contacted us with problems with the feeds updating in Bloglines. This problem appears to be directly related to the problems Bloglines has in understanding Atom 1.0 feeds.

What’s interesting about the problem is that the feed view in Bloglines isn’t incorrect, it just doesn’t update. At least regularly and in sync with changes to the feed. The same problem seems to apply to several other feeds as well. Using the Bloglines discorey options for a feed on a site this blog got to different feed options. Of which the Atom once was last updated sometime last year according to the feed. Their system doesn’t even recognize any of the feeds on the Life of Jalo front-page even though all of the feeds validate.

While I don’t use Bloglines myself, I find the system quite handy and can see the uses for many people (especially if they use multiple computers to follow feeds). However, the current problems in the implementation and the impossibility of causing Bloglines to update its view of a feed render it practically unusable. At least its reliability is highly suspect.

And the solution to our readers problems? Try subscribing (directly) to either the RSS 1.0 or RSS 2.0 feed which appear to work. At least for now. And here I was thinking of scrapping both of the RSS variants.