Netscape and Fixed Width Div's

Netscape and How It Hates Me

[duckbob]

Dual question, both about sizing in netscape.

Can the size of div tags in netscape be set to not take into account width+padding? I know it can be set in IE but there are some static elements in the page which is already made using IE width's and changing them would be more difficult then turning the width calculation off in NS.

Also,

I have a menu using a div

.Container {
margin: 0px;
padding: 0px;
width: 604px;
top: 39px;
left: 16px;
position: absolute;
z-index: 5;
height: 24px;
background-position: left top;
}

to place the menu, inside that is a series of div's

.SelectedMenu {
height: 24px;
background-image: url(system_images%5Csel.gif);
background-repeat: no-repeat;
text-align: center;
background-position: left bottom;
white-space: nowrap;
padding: 4px;
overflow: hidden;
position: relative;
display: inline;
}

for each tab. The tab div's are staggered with dropdown menus of absolute posistioning <dropdown> <tab> <dropdown> <tab> <dropdown> <tab> The problem is that I need to have each div tag fixed to a width coming out of a database

<div class=\"FUnSelectedMenu\" style=\"{width: $myrow[Item3]}\">"Tab Title"</div>

IE keeps the tabs the right width but NS collapses them. I was told that modifying the inline display I might be able to set it however this causes the horrible horrible misalignment of the tab's due to the dropdowns...

Any suggestions? I really need to fix this and finish this project...my head is hurting trying to compensate.

[MonkeeSage]

Try:
-moz-box-sizing: border-box;

And for Opera:
box-sizing: border-box;

Like...

* {
-moz-box-sizing: border-box;
box-sizing: border-box;
}

That causes them to act like IE and include the padding / borders in the calculation of width, instead of adding them to width.

Cf. [xs4all.nl...]

Jordan

[TGecho]

I've been meaning to ask for thoughts about this method for a while. While I see a place for the "official" box model, I think the MS version is more practical for most applications (imagine that). That's why I would like a way to choose on an element by element basis.

I also don't like that using this method would not allow me to use a strict doctype, since IE would have to be left in quirks mode. I guess it's not a huge deal, since I write fairly decent code (IMHO), but it's the principle of the thing ;)

[duckbob]

Heh, I write shisty code so I have a problem.

I'll try the
-moz-box-sizing: border-box;
box-sizing: border-box;
css.

I managed to fix the fixed width problem by removed the container div and forcing the tab divs to block, it made them constant width. Now why can't MS and NS just decide weather inline is fixed or dynamic....someone can just flip a coin, i mean really....

[drbrain]

Typically, IE is wrong, and Gecko/Safari/Opera are right. Write your code for these browsers, then tweak for IE, not the other way around. Your life will be simpler, bird song will sound sweeter, and you won't go bald as fast.

[MrMcTerse]

Hopefully no one will mind me riding in on the coat tails of this thread. My question has to do with fixed width, but on a much simpler scale.

If Gecko/Safari/NS are so smart, then why is it the IE can create perfectly a <.div> that matches the width of an image above it, or beside it, and the others always create larger 'boxes' that overflow the width/height of the image.

Can the box-sizing mentioned above help me with this issue?

I'm trying to create one sheet to fit all with slight compromises. Most often when I get things to look right in Mozilla/NS, they look screwy in IE, which for me is a problem when one considers that 95+% of our visitors are using IE.

The properties applied to IE are always exactly predictible, while for the others (I know nothing about Safari or the Mac, sorry) are completely out of whack. What am I missing here?

[MonkeeSage]

MrMcTerse:

There are two factors that could lead to the discrepancy: 1. the DOCTYPE that is used (which will determine if the browser renders in Standards Compliance Mode or Quirks Mode); 2. the box sizing model the different browsers use.

If it is just an issue of the differences in box models, then yes this should fix it, because it will make it so Mozilla (Netscape) / Opera render the same way IE does; padding and border included in overall width instead of added to it.

Jordan

[MrMcTerse]

I did research this question last evening, and have found that the 'box-sizing' can be made the same for both IE and the others. It was a simple tweak in the stylesheet, that much is certain.

however, I'm not sure I fully understand the reference to the DTD and the two modes. Below, find an example of a typical DTD on our site. One of,

<.?xml version="1.0" encoding="UTF-8"?>
<.!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<.html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<.head>
<.link rel="shortcut icon" href="images/favicon.ico" />
<.link rel="stylesheet" href="CSSheets/instyles.css" type="text/css" />
<.title>Welcome to the Wainwright Main Street Project<./title>
<.meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<.meta http-equiv="Content-Language" content="en-us" />

OR

<.!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<.html lang="en-us">
<.head>
<.link rel="shortcut icon" href="/images/favicon.ico">
<.link rel="stylesheet" href="/CSSheets/sstlyes.css" type="text/css">
<.title>Site Map for www&#046;{url-hidden)&#046;org<./title>
<.meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<.meta http-equiv="Content-Language" content="en-us">

(The dots are added to prevent parsing)

Perhaps you wouldn't mind shedding some more light on this?

[MonkeeSage]

Here are a couple pages that give a fair amount of information on doctypes and rendering modes.

[ericmeyeroncss.com...]
[blooberry.com...]

Jordan

[MrMcTerse]

Thanks for those links, duckbob; they made for some interesting reading, especially the one on IE6 at M$DN which is referred to from both of the above. I'm still not sure I fully get the gist of this hodge-podge of ideas...

So....

If I understand this correctly, the latter of the two DTD's (4.01) is in 'quirks' mode, and the former (XHTML) is in 'standards' mode.

Now, according to Microsoft, there is no guarantee that anything in 'S' mode with render correctly in either older or possibly NEWER versions of IE. If I wish to produce a CD based group of web pages, they recommend using 'Q' mode. GRRRRRR! W3C must be swimming in their ire!

Okay... What do we do now? Being a novice, I still want to learn to do things 'correctly' and use the most compliant methods available, as I can learn them. Am I working myself into a corner? Should I have even started to convert the older 4.01/Transitional to XHTML? Was this a 'wrong' (if not uninformed) choice?

Furthermore, if I remove the URI from the XHTML!DOCTYPE will this effectively switch my page to 'Q' mode? It doesn't appear as though there even is a quirks mode for XHTML.

Still further to this, should I have never considered 'tableless' design, at all? The structure and grace is there, but if I can never be certain of the rendering possibilites, what chance is there of my ever gaining any confidence in my work and all the effort that goes into it?

Is there a concensus that we may never be able to create a 'one-size-fits-all' page design with or without CSS?

It's a bit late for me to start learning all the 'tricks,' most of which won't validate anyway. Will there ever be day when we can be certain of our standards compliant designs? {3-}p} (frustration!)

[Reflection]

Still further to this, should I have never considered 'tableless' design, at all? The structure and grace is there, but if I can never be certain of the rendering possibilites, what chance is there of my ever gaining any confidence in my work and all the effort that goes into it?

The hard part is getting away from thinking of a design as a table. The less 'table' like the design is, the less headaches you should have.

[MonkeeSage]

Table #2 in the first document in link gives a chart of which DTDs trigger which modes in which browsers.

When they say the XML declaration (or prologue) they mean the line...

<?xml version="1.0"?>

...right before the DTD. In IE putting anything before the DTD line causes quirks mode rendering.

I made a little favlet / bookmarklet / hotlistlet (I'm just gonna call it a "JavaScript bookmark" heh) to alert the rendering mode so it can be tested live as you develop your page:

javascript:(function(){var mode=document.compatMode,m;if(mode){if(mode=='BackCompat')m='Quirks';else if(mode=='CSS1Compat')m='Standards Compliance';else m='Almost Standards Compliance';alert('The document is being rendered in '+m+' Mode.');}})();

Just save it and then click it from the favorites / bookmarks / hotlist menu (depending on which browser you are using), and it will tell you which mode the current page is being rendered in.

Jordan

[MrMcTerse]

errr, one ought to be more explicit in one's writing...

The structure and grace I was referring to was the tableless design. Tables, IMHO are anything but graceful. Can anyone provide a reason why a person 'should' use tables, except of course the obvious, tabular data presentation?

This takes me back to the days of early BASIC (Integer, Applesoft, GW-Basic, MS Basic), which lacked structure (unless of course the programmer purposefully designed it in). When newer interpreters were developed it opened a whole new world of structured, modular design. My favorite of the early eighties had to be Basic09 in the Unix-like OS, OS-9 running on 68K machines. Even my CoCo could emulate a REAL computer in that OS, and the multitasking put PC's and Apple's to shame (but nobody would ever admit that!)

To reiterate from above, is it a good or not so good idea to be converting to XHTML from 4.01? Is 4.01 going to be put out to pasture in the near future or will it be a staple in the stable of markup?