padding only works properly in IE 2

[dd4005]

Hi,

I have a DIV layer and in the style properties I set this:

"position:absolute;width:600px;height:400px;padding:100px 0px 0px 200px;"

That means everything inside the DIV should be 100pixels down from the top and 200pixels in from the left.

In IE the width/height of the DIV is 600/400 as expected, and object within (Flash) is offset by 200,100. I even animate the properties to move the Flash file around within the DIV by accessing obj.style.paddingLeft and obj.style.paddingTop. All works fine in IE.

In Firefox 1.0.6/Netscape 8.0.2 and Netscape 7.0 things are wrong. The DIV is larger than 600x400. Instead it's 800x500. The padding appears to have made the DIV larger. If I output the width/height in an alert it reports 600x400 but it's clearly not. When I run the padding animation the size of the DIV is changing accordingly. It's easy to see this because I put a background color on the DIV.

I'm not tied to using padding, anything else that achieves positioning of an object within a DIV on a pixel basis would do the trick. It MUST be via a DIV style property though. I can think of several other ways of achieving this (put the Flash in a table, put in another DIV and position relative to the parent, use some object/embed align properties etc etc). I can't use any of these though because of the limitations of a content-generation system. The only thing I can do to achieve this is to use some new additional DIV style properties.

I tried using margin also but that moved the whole DIV (even in IE) by the offset amount instead of altering anything inside the DIV.

I have overflow:hidden and clip:auto set on the DIV too but that's not helping.

Any ideas? I've browsed the DIV properties in Visual Studio .NET in quickwatch and don't see anything better than padding that I might use. It has to not only be a property I can set in the DIV definition, but should also be scriptable.

Thanks

~dd

 

[Vragabond]

The title of your post should be 'padding only works properly in Geckos'. Because the way Geckos are treating the width and padding is the correct way as described by the standards and IE is wrong. Box model is described here:

http://www.w3.org/TR/CSS21/box.html

IE6 with the correct doctype will adopt the proper box model while IE pre 6 will remain treating it wrongly. I suggest you add a doctype if you can, to shift IE6 into behaving properly. IE5 and IE5.5 are dying out and soon there won't be a browser anymore supporting the old box model.

As for your problem, easiest would be to play with margin settings on the object that displays flash info. If that is not an option, you will need to adjust both padding and width of the container div. When you make padding larger, reduce width/height and vice versa.

 

[dd4005]

Thanks Vragabond. Interesting. It's kind of odd though that the width/height is reported still as 600x400 on gecko browsers although it clearly isn't.

As for IE5/5.5/6 I need to be compatible with all of them.

Adding a doctype isn't an option, I'm adding these DIV's into other peoples pages, and accessing the flash object properties isn't appropriate either. Unfortunately my only options in this content-generation system lie within the properties of the DIV. It's all I'm getting access to at the moment.

Your suggestion of adjusting the padding and compensating for that adjustment in the width/height had crossed my mind, until I then threw in an alert that output the width/height of the DIV and it hadn't increased. That led me to believe something is wrong there.

I'll give that a try, I know it will work, no reason it shouldn't. I'm still confused though why gecko browsers behave like this. Whether it's the W3/CSS spec or not, it seems odd. You ask something that's clearly 800x500 how big it is and it reports 600x400. I'm going to read that link now, thanks again

~dd

 

[dd4005]

Do you know if it's possible via javascript to determine whether IE is using this "correct" doctype? I'll need to do something roughly like this:

if(IE&&not-correct-doctype)
manipulate padding
else if(gecko || (IE&&correct-doctype))
manipulate padding and compensate in width&height

 

[Vragabond]

dd4005, you clearly are still not following all this. Width/height is by standards described as width/height of the content part of the box. It has nothing to do with the padding, border and margins which are later added to the box. So, Geckos are correct in telling you that the width x height is 600 x 400, since that is the size of the content part in your box. It is IE that is showing rogue behaviour by adding borders, padding and width together to form the width.

AFAIK there is no way of knowing through JS what doctype document is using, as it is not part of the website.

 

[dd4005]

OK thanks.

btw, I found a property that IE uses to signal it's alternate behavior:

document.compatMode 'CSS1Compat' or 'BackCompat'

I won't be using this though as I now see that using padding or margin is not an acceptable way of positioning objects within the content portion of the box. If there's no horizontal and vertical align properties of the content box then I'll need to simply wait for the next version of our content-creation tool where I can build in the ability to wrap the Flash in a table or another DIV.

 

[ChrisHunt]

I now see that using padding or margin is not an acceptable way of positioning objects within the content portion of the box

It's perfectly acceptable, it's just made a little tricky by IE's faulty box model. Fortunately you can capitalise on another of IE's bugs to work around the problem: IE will wrongly interpret a CSS property of [tt]_height[/tt] as if it was [tt]height[/tt]. So you can give the right values out first, followed by some wrong ones for IE:

<div style="padding:100px 0 0 200px; width:400px; height:300px; _width:600px; _height: 400px;">

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[dd4005]

Interesting idea, I like your thinking

I wonder about the doctype effect. Whether IE would still conform to it's buggy behavior or whether it would realize it has to not tolerate that _height because it's in strict compliance mode. Some tests are in order

~dd

 

[BabyJeffy]

IE will wrongly interpret a CSS property of _height as if it was height

Building on that... you can prepend _ to any CSS style and only IE will handle it. This is certainly true of IE 5, 5.5 and 6 for Windows (and most likely true of all flavours of IE out there).

Word of caution though... it may not be handled in IE7. On a side-note, would someone with an IE7 beta like to test this and let us know if it remains in that build?

Cheers,
Jeff

[tt]Jeff's Page [/tt][tt]@[/tt][tt] Code Couch

http://www.codecouch.com/jeff/

[/tt]

 

[dd4005]

I've got IE7 on XP and on Vista, I'll give it a try later today.

~dd

 

[dd4005]

Results of my test on IE7/XP and IE7/Vista:

In quirks mode IE7 accepts the _width and _height as before. That's a good thing.

The bad thing is that when IE 5/6/7 is in strict CSS compliance mode it STILL accepts the _ values. So you can't just write them assuming that they'll only have an effect on IE/Quirks mode. No, they also affect IE/Strict-mode. So writing them isn't actually a help for me. They can only be written when building up the DIV in JS and sniffing for quirks mode. If you're doing that, then you might as well just use that sniffing logic to decide whether to write the compensated or real width/height values

So here's the solution I've just finished testing:

I create my DIV in JS and when setting the width and height values I sniff for IE/Quirks mode and determine whether I want to compensate for the padding or not (IE/QM==not).

That creates the visible effect I want (an object inside the layer justified to the right bottom corner of the DIV content area). The layer always "appears" to be the same size across browsers.

When I want to animate the position of the object within the DIV content area, I do this:

//update padding
mylayer.style.paddingLeft=x;
mylayer.style.paddingTop=y;

//if it's not IE in quirks mode then update width/height also
if(!(document.compatMode && document.compatMode=="BackCompat"))
{
 mylayer.style.width=mydefaultwidth-x;
 mylayer.style.height=mydefaultheight-y;
}

Thanks guys, this works just fine

~dd

 

[dd4005]

Oops, posted too soon. That test is wrong. It needs to test specifically for IE as Firefox can also go into quirksmode. Here's the updated line:

if(IE && document.compatMode=="BackCompat")

~dd

 

[ChrisHunt]

I wonder about the doctype effect.

What doctype effect? You said earlier

Adding a doctype isn't an option

If, since then, you've gained the ability to change other parts of the page, add a proper DOCTYPE and scratch those IE hacks. If you're really bothered about IE5.x, try using an external stylesheet (a good idea in any case) and applying Tantek's Box Model Hack. There's also a handy guide to shutting out particuar browsers in CSS at

http://www.dithered.com/css_filters/

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[dd4005]

I meant that I have no control over whether the page I'm deploying into will have a doctype or not, so I have to sniff for that to find out if I'm in a doctype'd page. My stuff is simply included into pages via a javascript include tag, I have to work in the environment I'm told. Even if it were possible to FORCE a particular CSS mode I wouldn't be allowed to. The page author wants it the way they've designed it.

By the way, with the inability to edit posts here I wasn't able to update the code to how it finally looked, so here it is:

function funky(divnam,divwidth,divheight,padleft,padtop)
{
	var mylayer=document.getElementById(divnam);
	if(mylayer)
	{
		mylayer.style.paddingLeft=padleft+"px";
		mylayer.style.paddingTop=padtop+"px";
		if(IE && document.compatMode=="BackCompat")
		{
			padleft=0;
			padtop=0;
		}
		mylayer.style.width=(divwidth-padleft)+"px";
		mylayer.style.height=(divheight-padtop)+"px";
	}
}

I use something similar when building up the initial DIV tag.

~dd