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

Remember when the <blink> tag became a long-forgotten tag, discarded as being irrelevant and only to be resurrected on the occassional intentional abuse for humor’s sake??  Well, some scallywag is actually using blink as an text-decoration attribute in their layout….for their links.

Brace yourself…this is going to get ugly:  10dollarpayroll.com

Filed under: CSS, Websites
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

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

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

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

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

Because I work much faster than the speed of bureaucracy (particularly definition #3) and can’t seem to slow down at that pace, I find myself challenging myself to do new things that I’ve never done before—one, because I have the time to, and two, because I might as well learn something new, right?

So one of my most recent projects I decided that I was going to format the entire page with style sheets without the usage of tables, blank .gifs to act as spacers, etc. Now keep in mind that I’m from the old school of HTML (a raw coder to the core) and know all the tricks of creating complex layouts with nested tables, transparent images, etc—in the very least, moving to a stylesheet-driven layout will have a bit of a learning curve for me. And it has been.

(more…)

Filed under: CSS, HTML, Uncategorized
No Comments

In follow-up to my previous veting about how lame Internet Exploder is, I’ve spent some time in the W3C standards documentation on stylesheets. According to that documentation, here is what the specs are on the height tag as it pertains to stylesheets…

5.5.24 ‘height’

Value: | auto
Initial: auto
Applies to: block-level and replaced elements
Inherited: no
Percentage values: N/A

This property can be applied to text, but it is most useful with replaced elements such as images. The height is to be enforced by scaling the image if necessary. When scaling, the aspect ratio of the image is preserved if the ‘width’ property is ‘auto’.

Example:

IMG.icon { height: 100px }

If the ‘width’ and ‘height’ of a replaced element are both ‘auto’, these properties will be set to the intrinsic dimensions of the element.

If applied to a textual element, the height can be enforced with e.g. a scrollbar.

Negative values are not allowed.

CSS1 core: UAs may ignore the ‘height’ property (i.e., treat it as ‘auto’) if the element is not a replaced element.

So if it’s true that the height percentage value is to be ignored and is only to be read in absoultes, then IE is technically behaving. Sort of. Firefox seems to take a liberty and include the percentage value, perhaps figuring stellar coders like myself actually would have a valid use for a percentage value.

So it seems that perhaps the W3C is being too narrow in the usage of the height tag—considering its usage only for IMG objects. W3C considers it “most useful” in application to images, but I see plenty of validity in application to div tags or tables, in being able to control the relative or absolute height of an item’s attributes.

Filed under: CSS
No Comments

Since I’m contained in a quietly-situated area of cubicals, I can’t just stand up and scream at the top of my lungs

IE SUCKS!!!!!

So, instead I’ll blog about it, eh?

IE does NOT know how to properly behave when a stylesheet is telling it what to do (I guess Bill Gates [*cough* anti-christ *cough*] doesn’t like taking orders). I’m essentially trying to make a formatted div tag span the entire height of the web browser and of course Firefox is behaving like a good little browser should.

I’ve tried using height: 100%; as well as bottom: 0px;, both of which WORK in Firefox/Mozilla but IE just seems to sit there and picking its GUI-nose and assumes that when I say height: 100%; or bottom: 0px;, it’s thinking “oh, you must mean the bottom or height of the area of content that’s actually being filled with content”

MORON BROWSER

I say it again…

MORON BROWSER

Go for three? Nah. Ah, sure, what the hell. MORON BROWSER.

Of course this just scratches the surface of how stupid IE is when it comes to stylesheets. If anyone knows of any good resources out there of how to find good IE-workarounds or equivalents, that’d be much appreciated.

I think I’m going to go now and hurl some more unspoken insults and explicatives at that good-for-nothing-browser people call “Internet Explorer”.

Oh, Choose Firefox.

Filed under: CSS
1 Comment