Everything old is new again » internet explorer http://www.svendtofte.com rantings & scraps on code and web development Thu, 27 Aug 2009 22:38:34 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 The utterly retarded IE PNG implementation (and pngstrip) http://www.svendtofte.com/web/the-utterly-retarded-ie-png-implementation-and-pngstrip/ http://www.svendtofte.com/web/the-utterly-retarded-ie-png-implementation-and-pngstrip/#comments Tue, 12 Aug 2008 19:40:07 +0000 Svend http://www.svendtofte.com/?p=117 pngstrip (32bit, Windows Executable at 59 kb) is a small program I’ve written to strip out the various kinds of gamma and chromacity information from PNG files. It’s written in standard ANSI C, so should compile on anything reasonable, though it has only been tested on Windows XP. The source code is also freely available. It’s console program, just type out pngstrip filename.png, and filename.png will be stripped.

We spent years agonizing over the lack of 8-bit alpha channel in PNG in IE, and when we filly get it natively/nicely supported in IE they go and botch is so horribly.

Most of us have heard about gamma. But unless you do something in the graphics/print field, it mostly remains a button on our screen, where we tweak the luminocity of the screen. But of course, when an artist makes a snazzy PNG picture, making sure that it appears at the same display intensity as it did on his screen is understandably an laudarble goal. So PNG embeds gamma information, saying that this and that color, should be show at this and that intensity. The problem occurs when the BOG STANDARD (for 15 years and counting) HTML and CSS colors are NOT processed through the same system and thus don’t get the same gamma correction applied. The problem is easy to spot (need to be viewed in IE). The PNG files, once stripped, appears correctly.

I won’t really bother explaining this problem more, since it goes beyond stupid, I’ll just link further reading materials if you don’t know why you may wish to strip your PNG files for gamma information. Henri Sivonen has the best treatment on the topic.

]]> http://www.svendtofte.com/web/the-utterly-retarded-ie-png-implementation-and-pngstrip/feed/ 2 IE formatting oddity http://www.svendtofte.com/stylesheets/ie-formatting-oddity/ http://www.svendtofte.com/stylesheets/ie-formatting-oddity/#comments Sun, 06 Jul 2008 18:19:09 +0000 Svend http://www.svendtofte.com/?p=9 It’s good to know that within 1 day of returning to any amount of CSS work, Internet Explorer can still baffle me. Maybe I’m missing something here, but seems that if a small tag (yes, let the damnations begin, but it was mostly due to the WordPress default template using it, that I came across it) does not include some trailing whitespace, it receives a little extra padding.

Small element rendering comparison
Rendering oddity with small tags with no trailing whitespace.

The HTML code used validates, should you wish to inspect it yourself. The “CSS1Compat” mode is merely to ensure we’re in “standards mode”. 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">
<head><title>wth ie</title>
<style type="text/css">
h2{
background-color:red;
margin-bottom:0;}

.wth {
background-color:green;
margin-top:0;}
</style>
</head>
<body>

<h2>foo</h2>    <small class="wth"> b ar </small>

<h2>foo</h2>    <small class="wth"> b az</small>

<hr/>
<script type="text/javascript">
document.write(document.compatMode);
</script>

</body>
</html>

You’ll notice I remove all margin on the elements. And indeed, the first header h2 and small does render correctly. But the second gets a 2 pixel margin added for … who knows what reason.

]]> http://www.svendtofte.com/stylesheets/ie-formatting-oddity/feed/ 2 Reflections on max-width http://www.svendtofte.com/stylesheets/reflections-on-max-width/ http://www.svendtofte.com/stylesheets/reflections-on-max-width/#comments Sat, 05 Jul 2008 01:52:45 +0000 Svend http://www.svendtofte.com/?p=4 A couple of years ago, I added a page to my old site on an “easy” fix for emulating max-width behavior in Internet Explorer, by utilizing a powerful IE5 feature called dynamix properties/expressions.

Briefly, these expressions allow a web author to hook script expressions into the dynamic nature of HTML elements. The natural events of the page (onresize, onclick, onmouseover and so on) causing these expressions to be re-evaluated whenever content could possibly reflow. The effect is naturally very powerful.

<html>
<head>
<style>
#container {
width:expression(this.parentElement.clientWidth-100);
background-color:red;}
</style>
</head>
<body style="background-color:blue;">
<div id="container">foo</div>
</body>
</html>

The effect is unique, and should be obvious to anyone that this allows for very powerful behavior.

A problem of foresight

I’ll try to explain the motive for posting my old article, max-width in Internet Explorer. First off, at the time I was studying alot of HCI. So while making a HTML site for a school related project, I saw a good excuse for sounding clever about line-widths. Even with most of that stuff holding true, I simply didn’t think through the ramifications of posting this “hack”. And for a large part, I simply wanted to sell the expression technique, as I feel it’s extremely powerful, and many developers are unfamiliar with it. So I cooked up what seemed at the time as a “elegant” solution to this max-width problem.

I’ve received more email about this article then anything else ever on my site (quick hit in my inbox says hundreds of mails containing max-width). I still receive mail about it, with IE7 supporting max-width and the related properties. So, for a very long time, I’ve wanted to “set things straight”, and I shall attempt to do this here.

Not for the faint-hearted

As I noted, expressions are very powerful. To fully utilize and appreciate raw expressions you need a solid understanding of scripting, stylesheets and how they interact in Internet Explorer, and especially you need to understand how IE works, with “standards mode“, and the old-time box-model.

“Houston, we have a problem”

So, let’s explorer some of the problems we can run into. First off, this technique may look like a style in the presentation given above, but it’s behavior is anything but. First off, the expression construct used above is simply “short hand” for the setExpression function. This means that once IE encounters the expression construct it binds the code directly to the object. If you use any fancy DOM work to disable either the entire stylesheet (stylesheet switching) or just to kill a single element, it won’t work as the expression is already bound to the actual elements. It should be easy to see in this example where you can easily kill the stylesheet, but observe how the background-color style sticks regardless.

Far side of the moon

Let’s examine the actual code I posted in that old article. You can see the example of a simulated max-width here, but remember this only works in IE.

<html>
<style>
body {
width:100%;
margin:0;
padding:0;}

p {
border:1px solid red;
max-width:800px;
width:expression(document.body.clientWidth > 800? "800px": "auto" );
}
</style>
<body>
<p>
[alot of text]
</p>
</body>
</html>

If you try it out in IE, it’s perfect. The red line is never past the view port of the browser, never does any scroll bar appear, and so on. It looks like a spot on emulation (and for this little example, it is). The code is deceptively simple, if body.clientWidth is more then 800 pixels wide, then we enforce a width of 800 pixels. Super simple and straight forward right?

Now, what assumptions are at work here? Well, a huge assumption is that the body element (or rather, the containing box of the content we wish to apply a maximum width to has no padding and/or margin. Another (more dangerous assumption) is that the box model applied is the old non-standards compliant box model. Another problem is that we’re working in pixels. The entire point of the article was to discuss line-lenghts. Falling back on the pixel defeats that idea. The basic problem is that it’s just so hard to retrieve information about an elements size using relative units, so I just “wing” it a bit in the article, which helps no one.

Crashing hard

Now, let’s see what happens when we change some of those assumptions. First off, including a proper DOCTYPE in the document causes IE to change the box model used. This will cause borders, padding, etc to not be counted towards the width of the element. This in itself isn’t so bad, it merely causes the “effect” to appear more jittery.

It’s far worse, if you try to apply the max-width to an element whose own width is dependent on the elements contained within. Reflowing content causes the onresize event to fire, which in turn may cause an infinite loop. Look at the following code same code from before. WARNING: this code is designed to hang your browser if you use any older version of Internet Explorer.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style>
body {
width:100%;
margin:0;
padding:0;}

div {
background-color:green;}

p {
border:10px solid red;
padding:10px;
margin:10px;
width:expression(foo());
}
</style>
</head>
<body>
<div id="ctb">
<p>
<script>
document.write(document.compatMode);

function foo() {
	return (ctb.offsetWidth > 800 ? "auto" : "800px");
}
</script>
[alot of text]
</p>

</div>
</body>
</html>

Things to note is that a DOCTYPE has been added, a containing box for the paragraph has been added, and some margins and padding added as well. If you attempt to run this code in IE6 (seems this has been fixed for IE7), the browser simply locks up hard, and here’s why. The paragraph will tell itself to be 800 pixels wide when the ctb element shrinks to any less (min-width). Now due to the padding and margins I’ve added, the paragraphs width will add up to 820 pixels. This will cause the ctb element to widen to contain it, and suddenly it’s wider then 800 pixels, and poof, the script expression thinks the width should be auto. The paragraph, with it’s new setting of width: auto; snaps down in width, to fit within the browser window, and in turn, meaning that ctb can size down as well, and then the whole affair just starts over. And infinite loop, and it locks the browser up.

And I think locking the browser up in this manner is about as crappily as you can treat any visitor to your site.

As aside, I can note that there has been some fixes to IE, to prevent the browser from hanging. First off, the above code actually works in IE 7. It hangs IE 6. But in order to cause it to hang, I had to swap the code out into it’s own function. If I inline the code, IE 6 just ignores the code completely, presumably using some heuristics to sniff out that this isn’t really code it wants to execute.

Solutions

I think the time for solutions is well past. Back in the day, Dead Edwards had a fancy HTC you could add to pages, to make IE implement all sorts of CSS properties, including max-width (seems he continues to do this). I would probably have recommended that, as that was probably a more solid drag-and-drop solution.

At any rate, I’ve always had a sour taste in my mouth with my old page, and I’ve tried a sort of carthasis with this post, trying to wash some of it out. I’ve never been a fan of the popular “hacks” that started to develop once Cascading Stylesheets started to catch on like wildfire. It seems to me, that relying on broken behavior in very specific versions of browsers is just stupid. It’s basicly against everything most web developers wish for when they look at a page rendering in Firefox and IE, and wish they looked the same. Refusing to accept a “blemish” on your page, and instead resorting to hacks (of which mine was admittedly the worst) to make sure your vision is presented faithfully to the visitor just smacks of arrogance to me.

I’ve long since stopped working at the yoke of the visual designers with photoshop files being sent my way by, and as such, I’m not entirely sure how the industry works in practise. But I sincerely hope that it has matured enough to accept imperfections, and see them for what they really are; an expression of the open nature of the web.

Littering our pages with browser specific hacks is no better then client sniffing code. Each time we introduce a browser specific feature on our sites, the web gets to be a little bit messier. The IE team at Microsoft has a pertinent article on what writing these browsers are like.

]]> http://www.svendtofte.com/stylesheets/reflections-on-max-width/feed/ 14