Archive for November, 2009

Go-Live: Indian Valley Dental

By Paul Bagosy - November 25th, 2009

I’ve decided to start cataloging the sites that I’ve done recently, big or small. So, here we go:

Indian Valley Dental

Indian Valley Dental

Indian Valley Dental

What the client wanted:
This was a redesign of an existing CMS site that had a lot of Flash-based elements, including the navigation.

What I delivered:
The design kept the header flash from the old site, and I brought over the little Flash page title flourish.

I reworked the existing CMS to provide data is much more search-engine friendly and a lot more streamlined. The header navigation uses a CSS hover effect with a jQuery dropdown. The bottom navigation uses a quick server-side element to generate a style that underlines the page that you’re currently on, and the Contact Us page uses jQuery form validation and an AJAX spam-catcher.

The site is identical in IE 6, 7 and 8, Firefox 3, Chrome 3, Safari 4PB and Opera 10 (aside from a few form elements that resist styling).

Simple from the ground up, but that’s the way I like them.

Viewing hidden files in Dreamweaver

By Paul Bagosy - November 17th, 2009

Thanks to this brief tutorial, I can now see pesky hidden files like .htaccess files in Dreamweaver – server side and local. Because, for whatever reason, Windows just looooves to hide .htaccess files once you’re done editing them.

Further clarification on the button that turtorial is talking about:

dw11 Viewing hidden files in Dreamweaver

Click that funky little button, then select View and Show Hidden Files.  Viola!

-pb

IE6 – is there nothing it can’t make complicated?

By Paul Bagosy - November 11th, 2009

Here’s some info on PNGs in IE6 that will hopefully save you from throwing yourself out a window sometime between now and 2014:

We all know that PNGs are not natively supported in the browser that time (but not all of humanity) forgot, but PNGs are so wonderfully useful as to make them indispensable. What to do?

Well, some brave soul made a fix for this very problem that works very well once you have it set up correctly. There are two very very important things to note (I’m sure there are more, but these are the two I’ve encountered):

1) background-position:bottom absolutely positively does not work with this. If you’re trying to do a neat drop shadow effect over a textured background using an alpha-layered PNG, throw yourself out that window now (or just deal with the fact that IE6 isn’t going to support it). Don’t waste hours agonizing over why it appears to load and then disappears, just know that you’re not going to fix it and move on to different ways to make your effect work. I suggest getting as close a match possible with a GIF or scrapping it altogether in IE6. Don’t agonize over making it perfect in IE6 if this is what you’re trying to accomplish, because people should be punished for using IE6 anyway.

2) Google Maps uses its own PNG fixing that is completely derailed by iepngfix.htc. You’ll notice that your Google Map appears for a second and then disappears once the page has finished loading. So once you’ve got your style set up like so:

img, div, a, input  { behavior:url(/iepngfix.htc); }

it’s going to completely hose your Google Map. How does one fix this, you ask?

#map img, #map div, #map a, #map input  { behavior:none !important; }

Of course! But could it be that simple?

We’re talking IE6 here, so I think that answers itself. You see, if you’re using the neat browser checking information I wrote about a while ago to put all that into a CSS file behind an IE include tag, you’re in for a nasty shock. Apparently, this doesn’t work (at least it didn’t for me). So, we need to revert to server-side checking:

<?
	$useragent = $_SERVER["HTTP_USER_AGENT"];
	if(preg_match("|MSIE ([0-9].[0-9]{1,2})|", $useragent, $matched)){
		if($matched[1] <= 6){;
?>
  <link rel="stylesheet" type="text/css" media="screen" href="/css/ie6.css" />
<?
		}
	}
?>

Of course, you could always use an iframe, but you’re better off just throwing yourself out a window at that point. I must also point out that if you’re using jQuery, you’re going to want to include this css file after your jQuery include. Why? IE6 – did you need a better answer?

It’s also worth noting that IE6 has a strange relationship with the !important tag. It will normally accept it, say if you’ve got a structure like so:

.tag  { width:500px; height:500px; color:#FFF; }
#tag2 .tag { color:#000 !important; }

That’s useful for a ton of applications. However, if you happen to put two declarations on one line:

.tag  { width:500px; height:500px;  color:#000 !important; color:#FFF; }

IE6 will ignore the !important tag in favor of the last declaration it finds. So, in this case, it will revert to color:#FFF; whereas every other browser will assume you meant color:#000; (because, you know, you said !important).

This is a useful bug, though, and it can be used to your advantage. Say you’re trying to add a min-height to a div. We all know that min-height is new and IE6 screams at it and its friend max-height to get off its lawn, because height was good enough in IE6’s day and it doesn’t need newfangled tags. So, we just use the !important tag to confuse it:

.tag { min-height: 250px; height: auto !important; height: 250px; }

This tells most browsers that your div needs to be at least 250 pixels tall, or however tall it needs to be beyond that. It also tells IE6 to make the div 250 pixels tall – but IE6 is kind of sloppy, so if the content in that div takes up more than 250 pixels, IE6 will expand to compensate – but won’t go below 250 pixels. This is coding Aikido – use your enemy against itself!

And I don’t think it’s unfair to call a nine-year-old browser that still enjoys a ridiculous market share despite its overwhelming flaws the enemy.

-pb