IE8 Oddity

Check out this example web page in IE8.

Notice the white box doesn’t carry the full height of the screen. But then click on compatibility mode and it does.

So why doesn’t the white box carry all the way, as it should? It looks like it’s trying to reserve space for a horizontal scrollbar that isn’t there. If I go and set overflow:scroll to the BODY then the gap is filled in by a scrollbar. put the two side-by-side or in separate tabs and quickly switch between the two. Looks like that gap IS there for that horizontal scrollbar; it’s exactly the same height as a scrollbar.

I wonder what kind of bug this example hints at and how will it crop up in other web pages.

—

UPDATE

I found Microsoft’s IE feedback site which, among other things, lets you view bug reports in the system; this is a lot like bugzilla for Firefox.

Anyways, here’s a bug that describes a problem where the horizontal scrollbar is always visible. The bug was closed out with the release of IE8 beta 2, but included in the document in a workaround for this bug.

I applied the fix, which is to set overflow:hidden on the HTML element and EXPLICITLY set overflow:auto on the BODY element and lo the gap goes away.

So the bug is still there.

And why the hell do I have to explicitly set overflow:auto to the BODY element?! Microsoft, what the hell? The spec itself says the BODY element should have a default value of overflow:auto. Jeeze.

At this point I’d report the bug to Microsoft through their feedback tool. But I can’t, because their system is ass.

First off, DO NOT SIGN UP, DO NOT LOG IN to Microsoft feedback. As soon as you do YOU CANNOT VIEW THE IE FEEDBACK PAGE until you apply to join that feedback. When you do join it, you’re asked a bunch of personal information, and after you jump through those hurdles all you see is THE EXACT SAME THING YOU SEE IF YOU DO NOT LOG IN.

The only NEW functionality is I can comment on existing bugs.

I can NOT, however, submit a new bug report.

Microsoft, c’mon, you’re suppose to be better than this.

1) Why can people who don’t log in view the feedback sites, but once you’re logged in you’re blocked? That’s absolutely stupid!

2) Why does your web site tell me that if I want to submit a new bug report I need to apply for permission AND NOT PROVIDE ANY MEANS TO DO THIS?

I wonder how many bugs there are in IE8 that have gone unreported because this system is so poorly designed.

IE 8

I’m giving the IE8 Beta a spin and so far it looks like a lot of the old layout rendering bugs have been fixed. After over 10 years of pages riddled with horrible hasLayout bugs we may finally be on the verge of an IE that doesn’t need CSS hacks!

Of course the first thing I did was put it through my IE sucks! demonstration site. And to my happy surprise the pages were rendering correctly. So if you view that page in IE8 the only way to follow along with my frustration is to switch IE8 into compatibility mode by clicking the button that is to the right of the address bar.

However it’s not quite pefect.

IE8 seems to finally have a fix for the rounding bug that’s plagued IE since it’s inception. This demonstration page on the rounding bug works great in IE8. Even if you enable compatibility mode the rounding error is gone. Hooray!

But go back to my IE Sucks site, specifically this page. Start changing the window width and watch the left edge of the text start to jump around. Shades of the rounding error reemerge in IE8.

Still, my first impressions of IE8 are good. I’ll run it through some of the more obscure bugs I’ve found and let you know if I find anything, but right now it looks pretty good.

min-height

Some Technical Background

If you set an element’s height with a percentage value you have to ask yourself, “A percentage of WHAT?” If an element’s height is 50% what is this 50% value based on? The answer is simple: height percent values are based on the height of the element’s containing block. For example, if I set the height of a UL element to 500 pixels and set the height of a child LI element to 10%, that LI will have a height of 50 pixels. The UL is the containing block of the LI.

But if the containing block has no explicit height set, what happens then? Long story short, that percentage value is treated as auto. You can read all about this in the CSS spec.

Some Design Background

There’s a visual element web designers have been using for years now using different techniques. That is making the layout appear as tall as the viewport even if the content of the page is not tall enough in and of itself to force the layout to that height. Something like this.

My Attempts

The BODY element has a gray background and a DIV with a min-height value set to 100%. This is the trick I use. If I didn’t use min-height, but just regular height then the white box would only be as tall as the viewport and the text would overflow below the white box like this.

So what if I try to nest DIVs with min-height set to 100%? Well then this happens.

The gray box doesn’t go the full height of the screen. Why?

To The Spec!

Take a look at what the CSS spec has to say on min/max-height, specifically this bit about percentage values:

“Specifies a percentage for determining the used value. The percentage is calculated with respect to the height of the generated box’s containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the percentage value is treated as ‘0’ (for ‘min-height’) or ‘none’ (for ‘max-height’). “

So unless the height of the containing block is explicitly set to a value that doesn’t depend on the height of its content min-height takes a value of 0.

The containing block in my example has a min-height value of 100%. The height of this box depends on the height of its content. That’s because if there’s a lot of content the height will be larger than the minimum height of 100%. The height of the containing block is not set in stone. This is why any child element’s min-height value will be treated as 0.

Thus, the gray box does not extend down to the bottom of the page.

But…

So why is it that if I set a height value of 100% on the BODY and HTML elements the gray background color for the BODY doesn’t end like it does to the DIV with the white background color and a height of 100% in this example?

Actually, it does.

BODY Is Special

The BODY element has a fixed height. It inherits this height from the HTML element which inherits it from the viewport of your web browser. If your web page has content that requires more vertical space than is available, the BODY element’s overflow property dictates what happens. In this instance the default vaule for the BODY’s overflow property is auto. This means scrollbars will be generated as needed so that we can scroll through that content inside the BODY element.

This is an important concept here: even though the contents of the BODY element are taller the height of the BODY element itself will only be as tall as the viewport allows. Put it another way, if your browser window is 500 pixels tall then your BODY element is 500 pixels tall. If the content of the BODY element is 1000 pixels tall, the BODY element’s height is still 500 pixels, but scrollbars are generated that let you scroll through the content of the BODY element 500 pixels at a time.

If I set overflow:auto on that white box while it has a height of 100% you’ll see exatly the same thing that’s happening to the BODY in that scrollbars are generated to let you scroll through the content inside the white box.

This is why in this example the white box is only as tall as the window and not as tall as the content. The white box has a height of 100%, but the overflow property of that box takes the default value visible, which means the browser renders all of the content even if it extends beyond the dimensions of the containing block.

Putting It All Together

In my original example both the HTML and BODY elements have a height of 100%. The white box has a min-height of 100%. Using the rule put down by the CSS spec we can see that the containing block of the white box (the BODY element) has an explicit height (the height of the viewport) and that height value does not rely on the content of its children (it relies on the dimensions of the viewport). Thus the white box will have a minimum height the same as the height of the body. The white box will always be as tall as the window even if the content isn’t tall enough to fill in that space.

The gray box in this example also has a min-height of 100%, but it’s containing block (the white box) has a height that IS dependant on the height of its children. Therefore the min-height property of the gray box is treated as having a value of 0, preventing it from taking up the full vertical space of the page (like the white box).

Therefore, a child element whose immediate parent element has a min-height value set cannot itself have a min-height value. In other words: no nesting min-height elements.

Furthermore this min-height:100% will only work on an immediate child of the BODY element. It turns out this little CSS trick has a very limited scope. So if you ever use it be sure you understand what you’re getting into.

CSS Social Engineering

Or why browser history IS VERY BAD.

I’ve put together this quickie demo. Go there. If you haven’t been to PayPal recently you’ll be asked to go there. Click on the link, then come back. You’ll now see a red bar across the screen which tells you your last PayPal transaction is revoked and you should click on the provided link to fix it.

This is a 100% CSS-based social engineering attack. It works in IE7, Firefox and Opera (and I assume Safari as well as any other modern browser). And because you only see this message if PayPal is in your browser history the chance that you’ll take this message seriously is certainly increased.

Now this is just a quick hack. With a bit of CSS hacking you could get it working in older browsers. You could also easily style the message that appears to look like a legitimate alert box dressed in the proper OS widgets or maybe as a toolbar message that’s part of the browser (like the alerts that pop up if you’re using NoScript).

There is a bit of javascript here in that it tries to mask the link you’re clicking on with the old window.status trick. But the meat and potatoes has NO JAVASCRIPT. This means that even with NoScript installed you’re still susceptible to something like this.

Now keep in mind this, in and of itself, is not a complete example of a typical social engineering attack that you might encounter on the web. It’s simply a demonstration of an extra layer that’s available to a malicious web site operator (or someone who’s cracked a vulnerable web site).

This is also a very crude example. A more clever person could have several dozen links being checked for with each producing one or two sentences that, when put together, create a kind of story to give the user to help gain their trust; that the link they’re being asked to click is legit.

On the flip side a kind web site operator might provide a list of links in their navigation element to sites the user has already visited and hide those links they haven’t visited (or vice versa) to better cater to their needs.

There’s lots of GOOD things you could do with this, but it opens a door to these social engineers that we can easily close with little (if any) impact on us by simply disabling browser history.

Aurora

Mozilla Labs is starting to release some information on their concept next-gen web browser called Aurora.

They’re releasing concept videos of how they envision this next-gen browser might work. And after watching the first three videos you too will become sick with the term “next generation” or “next-gen”. Why not just call it Aurora?

The nice thing to see in the demo is something I’ve been on about for a while now and that’s the use of data within a web page for something OTHER than just reading humans. In the demo they use a tool to take data from a table and generate a graph on-the-fly. Very good stuff.

I still maintain there’s something to creating a feature which can quickly summarize a page for you based on heading hierarchy and strong/emphasis tags, etc. Take the existing information and organize it for the user in a way that highlights the important bits.

Sadly, that’s where my compliments for Aurora end.

The first thing you notice is Aurora is designed to become your desktop. It’s already very stuffed with widgets and icons, where’s the button to get out and access the rest of my computer? Good luck fitting one in there.

Aurora also tries to take a crack at the 3D desktop. It’s something that developers have been trying to come up with for years. There are many 3D desktop alternatives already out there (for all flavors of operating system) and few seem to ever stick around. There appears to be some inherent usability problems with the 3D desktop or at least problems in getting users to think three-dimensionally about their desktop organization.

What bothers me about 3D desktops is the motivation behind creating such a thing. Is it for better organization or is it to create some special effects to make things look more “cool”? Every 3D desktop I’ve seen so far seems to be motivated by the latter; usability is an afterthought. Aurora may be the other way around, we’ll see.

There’s a dangerous concept here in that they take screenshots of pages and store them so that you have a visual representation of the page while sorting through all your bookmarks, history, etc. The problem with that, as you’ll see yourself in the first Aurora concept video, is that were it not for the very large timestamp on the screenshot used for the weather station web page how would you know that the page you were looking at was out of date?

The bookmark/history demo is a mess. The bookmarks are, again, thumbnails of the web site. But once your bookmark library grows to a few hundred web sites the interface becomes problematic. Each web site’s thumbnail is little more than a few pixels of color. It’s like filling your Windows desktop with a couple hundred icons. Some people swear by it because they know where everything is, but to someone who doesn’t know where everything it’s an impossible interface to use.

What saves the users with this bookmark interface is a search mechanism. Thing is Firefox 3 already lets you do this at the address bar. Why bother with a bookmarks interface at all?

Being privacy minded I don’t let my browser keep a history of those web sites I’ve visited. This is something I think people will become more aware of over the next few years and the history function of the browser will become useless.

For example this web site will guess your gender based on your browsing history. It’s a simple hack. While you can’t directly access a browser’s history you can generate, say, 10,000 links and check to see which ones have a visited status. In fact you can do something like this with CSS which I’ll talk about later. Point is, there’s a lot of information a web site can take from your browsing history. They can profile your gender, your tastes, your interests, and maybe generate targeted advertising or attempt some kind of con to get you to click on a malicious link or install some bad software.

Keeping your browsing history disabled is the only way to browse.

The mobile interface is interesting, although I wonder how readable it will be on a small PDA. Some of the buttons are certainly smaller than some of our fingertips. I do like the idea of using the whole screen for the web page, but gesturing left or right should only have one action, not two. If you gesture only so far to the left you bring up the address bar as well as the back, forward, and bookmark buttons. Gesture farther left still and you zoom out. How often are people going to go to open the address bar and zoom out? And how annoying will that get after a few minutes use?

One other thing I want to touch on is the general-purpose nature that browsers are heading towards. In the demo there’s some text-messaging and voice chat going on. This appears to be happening in-browser (perhaps via a plug-in for AIM or Skype or whatever). You need to be careful with doing things like this. If we start building everything into the web browser then the web browser becomes our OS. But we’ve already GOT an OS. So maybe we see the browser become deeply integrated with the desktop. But Microsoft started doing that years ago and all that did was create lots of new vectors for attackers to take control of computers.

You want separation of applications. If one application fails or is vulnerable you can remove it without destroying the other applications.

Imagine you’re in the middle of some important work (say, writing for your blog) and someone starts spamming the hell out of your IM account (say someone posted your screenname on some popular teenage message board and say “HEY, EVERYONE, IM MY FRIEND”.) Well now you’re properly screwed. You can’t close the IM client because it’s built into the browser. You have to close the whole thing, which loses you the work you’ve put into your unfinished blog post.

Or, imagine there’s a big virus blasting its way through Skype’s network. If you don’t shut down your skype client you risk getting infected yourself. And this is a nasty virus that immediately wipes your drive and destroys your data. But you can’t close Skype, you’ve got to close the entire web browser. No web access until a patch is fixed. But you can’t get the patch because you have to open up your web browser to get it.

See what’s happening?

Separation is GOOD.

Browser. IM. Voice. Image browser. Word processor. KEEP THEM SEPARATE!