I deal with stylesheets every day and frequently have to find ways around the oddities and quirks between both Firefox and Internet Explorer. One quirk that’s been bothering me for quite some time now has surfaced again, and I figured out a “fix” for the issue.

The problem: When I have a <DIV> tag initiating a content section and it is immediately followed by an <H1> tag, it does something funky. The <DIV> tag pushes itself down in the layout about 18 pixels or so depending upon the size of your H1 font.

Allow me to illustrate:

What you see here is Firefox 2.003 (left) and Internet Explorer 6.02 (right) with the arrows indicating where both browsers are interpreting where my div tag “begins.” As far as code structure is concerned, I’ve got a small nested div setup under the header (the blue bar)… like so:

CONTENT
–left column (floats)
–center column (static)
–right column (floats)
/CONTENT

That shadow is a background element of each of the nested div tags and is supposed to line up. However, throwing that H1 tag into the center column div throws everything off. The H1 tag (along with all other heading tags) have a margin-top value—I’m not sure what it is, and I don’t really care—all I know, though, is that it is forcing the center column div tag to start LOWER than it really ought to.

So I tried something out—I added a line-break tag after the start of the center column div tag, but that produced not-so-desirable results:

The arrows show that both IE and Firefox cannot seem to agree on just how much space to give a line break. While this did solve the problem of moving my div tag down, it posed another problem; therefore there’s got to be another solution out there.

So I gave this a try—instead of putting the “fix” in the HTML, I tried adding a padding-top value in my center column of 1 pixel. Which produced the near-desired result:

Both browsers are relatively matched up, but there is a three pixel difference between Firefox and IE. While that may be sweating the small stuff, that kind of variance is what can make creating more complicated layouts more difficult than they need to be.

Anyway, I hope that this little discovery is helpful to others that are experiencing div placement quirks with Internet Explorer and Firefox.

Filed under: CSS, HTML, XML / XHTML
No Comments

So I’m sending an .html attachment through Outlook at work (yeah…I know…it’s Outlook). Well, I dragged the file over and must have accidentally dragged it to the body area. Next thing I know, MICROSOFT WORD opens up to edit the HTML for me.

Enter my euphemism for the day:

Editing HTML with Microsoft Word is like fixing a car with a popsicle stick. It ain’t ever gonna happen.

Filed under: Development, HTML
No Comments

So I’ve had a little spare time today while waiting for responses from various parties and thought, that I’d experiment with some stylesheet stuff, using the Crash Effect layout as my guinea pig. I consider it work-related enough to keep my skills fresh and try new things.

Well, included in this experiment was the use of a png-24 image. When I saw how Firefox responded with its usage and how beautifully it overlayed the transparency with other elements, I couldn’t resist using it — even if the image was 79 kb. Who cares? It’s just so cool. [In the photo link referenced above, notice how the rays overlap the leaves under the menu and the cool glowing effect it places on the menu background...that's what I'm talking about.]

Aside from some stylesheet related issues with the menu positioning, things were going beautifully and I felt like I had reached a whole new level of web coolness with the usage of png-24’s. They’re higher in file size, but the coolness factor far outweighs the file size.

Leave it to Internet Exploder to dash my dreams of having a kick ass, non-flash-dependent website. Here’s how IE decided to treat my png-24 image.

Can I get a DOH!?

Back to the drawing board.

Filed under: CSS, Development, HTML, Websites
1 Comment

I’ve thought up the perfect analogy for Internet Explorer, particularly as it pertains to us web designers and developers.

Internet Explorer is like the nice neighbor dog that lives next door and comes by and shits on your lawn, which leaves us (the web designer/developer) to clean up after their mess.

I suppose you could carry the analogy further, in that Microsoft is the bad neighbor who doesn’t make a whole lot of effort to clean up after said dog.

Mozilla makes a much better neighbor. They clean up after their dog, it’s relatively bug free, stable and doesn’t leave little surprises on your lawn when you go to cut the grass.

Good dog, Firefox. Good dog.

Filed under: Development, General, HTML
No Comments

So a buddy and I were talking web design over a beer following our band practice.  I brought up an issue that I’d been struggling with yesterday concerning Internet Exploder [Explorer] and how the image alignment wasn’t truly snapping all the way to the right or left.  A small gap was showing up (and showing a portion of the background I had intended to not be visible).  See this example snapshot of a corner image that I’m attempting to align to the left:

Firefox works fine: 

IE pukes up a three-pixel gap:

Jamison mentioned that it’s called the three-pixel bug in IE.  Of course you can just put a style attribute in there like so: 

style="margin-left: -3px;"

…but you also need to put browser case statements into your HTML to test for IE, and in principle you shouldn’t have to do that.  ANNOYING.  Somehow I doubt that we’ll ever see the day when you don’t need to run browser case statements in your source code.  Call me a cynic, but I’ve been doing web development since Microsoft decided to try their hand at web browsing with Internet Explorer version 1 and they’ve been deviating from web standards and norms from day one.  It’s been a persistant issue since the mid-90’s—finding the common denominators between the major players in browsers and coming up with a hack to just make things work.

Which brings up the issue concerning finding balance between a purely style sheet-driven layout and the use of tables.  The purists say “don’t use tables”, but let’s face it—it’s not always practical to take that approach.  The browsers can’t even agree on what is standard for a particular way of measuring height and width.  Example:  IE treats the height and width value as that of the entire window while Firefox treats it as the width and height of the object that the attribute belongs to. 

For an illustration, look at these screen captures, which compare how IE and Firefox in height definition.  The context here for this example is if I decided to give the value height: 100% to the header shown above.  [Firefox] [Internet Explorer]

Of course there are advantages to both perspectives of what the height attribute does in both browsers, but you’re back to performing case statements on browser type.  That’s just not cool.

Instead, I think the folks at the W3C ought to consider refining the standards to include values like this:

object-height: value context
object-width: value context

In this example, value would be the height in pixels, percentage, etc. Context would be specific to either parent-object, window or some other value that might give it a better context. So if you wanted to specify your object to be 100% of the window height, you might put in: object-height: 100% window Or if you only wanted it to extend to 50% of the object to which it is subject to (a parent object), you might put something like object-height: 50% parent-object

Just some thoughts on what I think they need to implement into browser standards.

Filed under: CSS, Development, HTML
No Comments

Found a very useful tool today through Google called Google Sitemaps

It basically allows you to do some Google-related diagnostic work on your website to maintain good standing with Google, improve your ranking and get some basic stats.  Of course, if you’re looking for more advanced stats, you may wish to try Google Analytics.  Their stats app is pretty sweet —  but you need to apply (and hope) for access.

Filed under: Awareness, Development, HTML, Websites
No Comments

“The Breakdown of Modern Web Design” (PNG Image, 550×410 pixels)

Filed under: CSS, Development, HTML, Websites
No Comments

Being a web developer and designer, I’m always looking for things to help make my job a little bit more efficient — sometimes tools to just make ugly websites not be so ugly (like those lyric websites with the extremely annoying ads and such).

Well, I’ve found a great Firefox extension that not only is useful for disecting and figuring out page layouts, it can also “erase” certain sections with the pressing of a button.  You’ve gotta check out the Aardvark Firefox Extension.

You’ll love it.

Filed under: Applications, Development, HTML
No Comments

A coworker was trying to figure out how to use JavaScript to get a RADIO value from a form. Because a radio form element makes up an array of possible selections, you have to cycle through that array to find the selected value. It is then that you can retrieve the actual selected value.

Check out the code below that I’m using to get the value of the selected radio element. From this you should be able to customize it for your needs. Simply insert your code or run your function in the level where I’m running the alert() command.

<script language="javascript">
function rockmyworld() {
 i=0;
 do {
  if (form.myRadio[i].checked == true) {
   alert(form.myRadio[i].value);
  }
  i++;
 } while (i < form.myRadio.length);
}
</script>
<form name=”form”>
<input type=”radio” name=”myRadio” value=”1″/> 1 <br/>
<input type=”radio” name=”myRadio” value=”2″/> 2 <br/>
<input type=”radio” name=”myRadio” value=”3″/> 3 <br/>
<input type=”button” value=”get value” onClick=”rockmyworld()”/>
</form>

Hope that helps any folk out there that were burnin’ brain cells trying to figure this out.

Filed under: HTML, JavaScript
1 Comment

So I’ve been working on one of our intranet sites and it looks just fine when I view it independently. Unfortunately though, we have everything in a frames environment…so when I view the site in the frames, the copy gets all tripped out, stacking upon itself when I scroll and/or navigate to other pages within that site.

I know it’s a stylesheet issue, for when I remove the stylesheet the problem goes away. But the thing I can’t figure out is why it’s doing it, when all the styles are W3C compliant and aren’t doing much other than setting padding values, font sizes, a few background elements. Pretty basic stuff.

Check it out for yourself: Before & After

I’m pretty much losing my mind trying to figure this out, since there’s another site that uses the SAME CODE (just located on a different server) and works just fine. Go figure.

Any thoughts anyone out there in the web development community?

UPDATE

For starters…this DOES work properly in Firefox. That wasn’t a suprise. But if you look at the example images, I’ve got a white then gray stripe down the left side. The image basically stops at the end of the gray stripe and I have it repeating vertically (Y axis) and have the following code in the body { } style:
background-image: url("../images/side_graystripe.gif");
background-repeat:repeat-y;
So I tried removing that snippet and everything worked fine. My solution? Take that background .gif image and extended it to 1600 px wide (the max width it’d be viewable at) and left the code in the stylesheet.

IE is apparently freezing the content when you scroll or nav to other pages with that same background code. Can we say “BUG?”

It’s an unusual scenario, I know, but at least I figured it out. Hope this helps anyone out there running into the same issue.

Filed under: CSS, HTML, JavaScript
No Comments