Archive for msie6

fixing IE7 layout problems

As I noted earlier, while IE6 displayed this site (in Nearly-Sprung) correctly, IE7 did not.

The reason is this: the bug in IE6 and previous that allowed the following CSS hack to work

* html .anelement { layout fixes }

has been fixed in IE7. However, many of the layout issues that were fixed in the escaped code have NOT been fixed. In my case the particular culprits were these:

/* Essential Layout (IE Fix) */
* html #leftsidebar {
        left: 150px;              /* RC fullwidth */
}
 
/* Hides from IE5-mac \*/
* html li {height: 1%;}
/* End hide from IE5-mac */
 
/* Hides from IE5-mac \*/
* html #postnavigation {width: 145px; height: 2px;}
/* End hide from IE5-mac */
 

IE7, like IE6, needs the left: setting, but as it no longer works with the * html escape (for an explanation of why this is, see the excellent article here) it is not getting these settings as it should. The result on my site was the left sidebar’s utter disappearance.

The workaround is to isolate the IE hacks into a separate .css file and call it with an escape that all IE derivatives still honor. (Wonder how long this escape will last…) While tedious, this is overall a better solution than embedding hacks within a css file. Such hacks can be relegated to a separate file which can later be removed when IE is finally fixed (these glasses seem awfully pink, don’t they?).

So, in general this is the way to fix such problems. I checked my css files for any instances of

* html

Some of these might be in a “holly hack,” which should be moved along with the rest of the markup.

I created a new css file, iehacks.css is fine, and dumped all the hacks into this file. Now, I removed all instances of * html (this is the crucial part, otherwise no improvement is seen for IE7). In my case, this new file wound up containing the following:

#leftsidebar {
        left: 150px;              /* RC fullwidth */
}
 
/* holly hacks to fix peekabo bugs in IE */
 
/* Hides from IE5-mac \*/
li {
        height: 1%;
}
/* End hide from IE5-mac */
 
/* Hides from IE5-mac \*/
#postnavigation {
        width: 145px; height: 2px;
}
/* End hide from IE5-mac */

(Note the holly hacks in the last two rules.) Now, I needed to modify my <head> element to include this css file, which was easily done via adding

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="iehacks.css" />
<![endif]-->

In WordPress, this meant modifying my header.php file (of course I made a backup copy of it first) as follows:

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="<?php bloginfo('stylesheet_directory'); ?>/iehacks.css" />
<![endif]-->

I added this just before the call to wp_head. This would make a VERY simple plugin; I could create one if people wish. But this is pretty straightforward as is.

Update
Probably the best way to do this, allowing for testing in IE7 before proceeding completely, is to copy the suspect elements over to the new css file. Since IE7 doesn’t work with the current css file anyway, it doesn’t hurt to leave the elements in place while getting the iehacks file to work. Add the [if IE] call to the headers and check in IE6, IE7. Once everything looks okay, then remove the suspect elements from the original css file, one by one.

del.icio.us:fixing IE7 layout problems  digg:fixing IE7 layout problems

Comments (5)

the new & improved Internet Explorer

Roger Johansson (of 456 Berea Street) and Lorelle VanFossen both remind us that the new Internet Explorer has been released into the wild and what does that mean for all our web pages?

I want to point out that Internet Explorer really has three main versions right now. (I have to support multiple platforms, so this sort of thing is a large concern for me). IE7 is intended only for XP and Vista. Anyone who has not migrated to either of these platforms will use IE6. Since Win2K is pretty decent, and there’s a lot of people out there who haven’t bothered to shell out for the bigger badder etc computer, I expect that the web pages I work on will continue to have a substantial proportion of IE6 users. So the IE6 bugs remain a real and ongoing concertn.

In testing with IE7, we have noticed that there can be different behavior between IE7 on XP and IE7 on Vista! Now, some of this may be due to the different beta versions of Vista — I believe we’ve gone through at least two updates on Vista beta. However the possibility remains very high that IE7XP and IE7Vista will behave differently from each other as well.

So now that means three platforms to support in place of one!

In any case I’m aware that IE7 does not handle this website gracefully even though IE6 does, as you can see in this screen shot.

del.icio.us:the new & improved Internet Explorer  digg:the new & improved Internet Explorer

Comments

Part III: wandering through unicode, legacy fonts, and browsers

Unicode — Supplementary Planes

Back to Unicode. Even Unicode needs room to expand. The Basic Multilingual Plane (BMP, also known as Plane 0) has codepoints 0 through FFFF hex (0 through 65,535) and contains, ignoring various special mathematical characters, historical quirks, and just plain oddities, most of the current alphabets and symbols in use today, even including the vast array of Chinese kanji. But of course there’s more room needed once historical alphabets and other special character sets are also considered. Supplementary planes such as Plane 1 are simply sets of 65,535 code points following Plane 0 (some of us refer to these as astral planes :-) ). Using hexadecimal notation, it’s easy to spot Plane 1: all Plane 0 codepoints use four hexadecimal digits; all Plane 1 use five, etc.

Here is an example of a Plane 1 character: &#x1D50A; which renders as 𝔊 (marks a septaugint reference). In case anyone viewing this is having trouble, here’s an image:

To set things up to view this can be an interesting process. First of all it’s necessary to find a unicode font that supports plane 1 characters. Not all such will actually show the above, for example Code2001, an otherwise excellent unicode font, does not include historical Greek musical notation however Cardo works nicely. Just because a font is unicode based does not mean it will be “complete” (such a font would be staggeringly large). In particular, when choosing among unicode fonts, pay attention to which version of unicode is being supported, and what the target languages are. Plane 1 characters start to appear in Unicode versions 3.2 and up.

Second, the operating system might need slight adjusting to see Plane 1. I’m talking, of course, about Windows, XP and earlier versions. This page discusses how to do the registry edits necessary both for the operating system and for IE6 8-|.

Linux/*nix, Mac, and Vista are all presently able to handle Plane 1 without modifications. My understanding is that for Windows Me and anything prior to NT, it’s hopeless.

Third, applications in general and browsers in particular may need slight tweaking to see Plane 1 characters. As usual, IE6 is the worst offender in this regard requiring not just setup but also a registry edit. In general, once the browser is set up with a Plane 1 aware font, it’s good to go. Firefox, Safari, Opera, and Konqueror all fall under this category.

A few notes: IE6 needs to be set to user-defined encoding plus the extended font needs to be listed under User Defined (rather than any of the specific regions listed, which refer back to non-unicode encodings as discussed in part 1). Opera actually reverses from the general MO of other browsers: under Tools->Preferences->Advanced->International Fonts, it’s possible to set a particular unicode font to a particular language (going by Unicode’s code blocks). This is the direction other browsers should no doubt take in the future.

del.icio.us:Part III: wandering through unicode, legacy fonts, and browsers  digg:Part III: wandering through unicode, legacy fonts, and browsers

Comments

fun with browsers and javascript

Since javascript is a client side implementation (meaning that it is the browser and not the host site (such as is the case with php/perl/other cgi scripting) that actually runs the script) this means I can have endless fun finding out the many ways in which javascript gets completely hosed up.

I mean, take a pretty simple bit of javascripting:
document.getElementById('cleanslate').innerHTML = s;
where s is a nice little list of selectable (checkbox) items in a list to be output.

And then of course, in the html we have:
<span id = "cleanslate"></span>

How much simpler does it get?

Well. It worked beautifully in Firefox.
Didn’t do a single thing in IE6.

And it’s hard to figure out where to even start. In no amount of googling have I found a book, or a faq, or any kind of documentation that extensively details the ways in which Javascript differs from browser to browser. I would think this would be a huge niche. I certainly found many many questions on this stuff. Even if the differences are under constant change, I would still expect at least some online resources to be out there. (Anyone know of any?)

I did find another site that demonstrated a very similar problem: Chameleon but which offered no solution, only the illustration.

After much experimenting, I finally figured out that the issue was really this:

<p>
<span id = "cleanslate"></span>

There is something about the unclosed <p> that IE6 does not like. This actually kind of makes sense — since it’s not closed (yes, I know, slap my hands already), the question is what is the actual DOM? Firefox obviously defaults to something reasonable to handle it, IE6 takes the novel approach of displaying nothing at all. Well the “Sun Java Console” (now there’s a misnomer if there ever was) does come up with the every helpful:
"Unknown run time error on line..."

As an aside: I just gotta love this “Sun Java Console” for its utter uselessness. It’s not even possible to copy and paste the message somewhere for future reference. I can’t make use of IE6 until I close the window. It offers no means of running anything, debugging, tracing, etc. There’s an extension available at Microsoft but even after I jumped through the WGA hoops to download it, when I ran it to install it, it said “No Installation Data available.” It’s particularly annoying after using so many lovely Firefox extensions that enable extensive Javascript debugging.

But here’s the odd part. Removing the <p> altogether fixed IE6. Finishing it off before the opening <span> worked, as well. But enclosing the span within the paragraph did not work. Throughout all these variations, Firefox worked throughout.

Opera, unfortunately, is an entirely different story…! It looks fine, on the first pass. But it’s clearly not actually getting the checkboxed items into its form when the form button on that page is pressed. Ugh.

del.icio.us:fun with browsers and javascript  digg:fun with browsers and javascript

Comments (1)

Part II: wandering through unicode, legacy fonts, and browsers

Precomposed versus Combining

In the course of putting together the encodings (called code points) in Unicode, a number of decisions had to be made regarding the current existing encodings, particularly well known and/or well established ones. In some cases, even though the Unicode Consortium has a particular policy regarding some encode vs render issues, there are inconsistent inclusions due to this grandfathering of prior established encodings and (to be quite honest) outright mistakes on the part of the Consortium. The question of precomposed characters versus combining characters is a classic one.

Read the rest of this entry »

del.icio.us:Part II: wandering through unicode, legacy fonts, and browsers  digg:Part II: wandering through unicode, legacy fonts, and browsers

Comments

« Previous entries

Bad Behavior has blocked 953 access attempts in the last 7 days.