Preparing to write a post that blasts CSS.

[dterrors@hotmail.com]

I figure before I go and write my summary of why you should go back to
tables and only use CSS for fonts and colors and stuff, I ought to make
sure I've got my facts right. So, please tell me how I can get this:

<div style="border:1 px solid #000;width:100% ">
<table style="backgrou nd:#CABE9E;
margin:10px 10px 10px 10px;
border-bottom:4px solid #000;
border-left:4px solid #000;
border-right:4px solid #000;
border-top:4px solid #000;
width:100%;">
<tr><td>some table stuff...</td><td>spills over in firefox, and
causes everpresent vertical scroll in IE</td></tr></table>
</div>

to look like this:

<table cellspacing="0" cellpadding="1" bgcolor="000000 "
width="100%"><t r><td>
<table bgcolor="ffffff " cellpadding="8" cellspacing="0"
width="100%"><t r><td>
<table bgcolor="000000 " cellpadding="4" cellspacing="0"
width="100%"><t r><td>
<table bgcolor="CABE9E " cellpadding="4" width="100%"><t r><td>some
table stuff...</td><td>spills over in firefox, and causes everpresent
vertical scroll in IE</td></tr></table></td></tr></table>
</td></tr></table>
</td></tr></table>

Try them in both IE and Firefox.

Apparently the spec for CSS says that the border and margins shouldn't
be counted when calcing the size of the div/table. Take a look at this
(these) bug reports:

https://bugzilla.mozilla.org/show_bug.cgi?id=258523

But IE does something bad too- notice that you get a horizontal scroll
bar at the bottom, no matter how wide your screen goes (with the CSS
version).

But the table version looks fine in both browsers.

Anyway, if I'm missing something that would fix this, tell me.

[logic_earth]

Re: Preparing to write a post that blasts CSS.



dterrors@hotmai l.com wrote:[color=blue]
> I figure before I go and write my summary of why you should go back to
> tables and only use CSS for fonts and colors and stuff, I ought to make
> sure I've got my facts right.[/color]

Just because you can't use CSS to make a layout doesn't mean everyone
else can't.
[color=blue]
> Apparently the spec for CSS says that the border and margins shouldn't
> be counted when calcing the size of the div/table.[/color]

Infact they do margin/border/padding add to the width/height.

http://www.w3.org/TR/REC-CSS2/box.html

P.S. The table version makes me sick it takes four table to do
something so simple.

[logic_earth]

Re: Preparing to write a post that blasts CSS.

Quote From: W3C | http://www.w3.org/TR/REC-CSS2/box.html

"The box width is given by the sum of the left and right margins,
border, and padding, and the content width. The height is given by the
sum of the top and bottom margins, border, and padding, and the content
height."

[Lauri Raittila]

Re: Preparing to write a post that blasts CSS.

in comp.infosystem s.www.authoring.stylesheets, dterrors@hotmai l.com
wrote:[color=blue]
>
> I figure before I go and write my summary of why you should go back to
> tables and only use CSS for fonts and colors and stuff, I ought to make
> sure I've got my facts right. So, please tell me how I can get this:[/color]

You didn't. It is quite arrogant to complain about CSS, when you don't
know even the very basics. And even for advanced stuff, it is never fault
of CSS, but browers support.

Tables are not fully supported by browsers, I think that CSS is at least
as well supported.

[failure]
[color=blue]
> to look like this:
>[/color]

[overcomplicated tables, you could have cut at least 2. Of course, then
you would have to know how to use tables.]

div {border:1px solid black;backgroun d:#fff;padding: 8px;}
table {border:4px solid #000;padding:4p x;background:#C ABE9E;width:100 %;}

<div>
<table><tr><td> some
table stuff...</td><td>spills over in firefox, and causes everpresent
vertical scroll in IE</td></tr></table>
</div>
[color=blue]
> Try them in both IE and Firefox.[/color]

Didn't as you didn't give any URL. But it was clear what your problem
was. Simple cure is KISS.
[color=blue]
> Anyway, if I'm missing something[/color]

You didn't miss my killfile.


--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Kohtuuhintainen yksiö/huone haussa Oulusta syyskuusta eteenpäin.
Searching places to sleep on axis Bonn - Tsech - Poland - baltic sea in
july

[Beauregard T. Shagnasty]

Re: Preparing to write a post that blasts CSS.

dterrors@hotmai l.com wrote:[color=blue]
> I figure before I go and write my summary of why you should go back
> to tables and only use CSS for fonts and colors and stuff, I ought
> to make sure I've got my facts right.[/color]

I cannot make a nice wooden cabinet. I blame my chisel.

Next time, make sample pages and post them so we can see what else
might be wrong with your code, missing DOCTYPE for example. Thanks for
your indulgence.

--
-bts
-This space intentionally left blank.

[logic_earth]

Re: Preparing to write a post that blasts CSS.



Beauregard T. Shagnasty wrote:[color=blue]
> Next time, make sample pages and post them so we can see what else
> might be wrong with your code, missing DOCTYPE for example. Thanks for
> your indulgence.[/color]

If you add a strict DOCTYPE the table fails to work (well not on IE of
course).
However that is because he failed to put '#' (bgcolor="00000 0").

[Beauregard T. Shagnasty]

Re: Preparing to write a post that blasts CSS.

logic_earth wrote:[color=blue]
>
> Beauregard T. Shagnasty wrote:
>[color=green]
>> Next time, make sample pages and post them so we can see what
>> else might be wrong with your code, missing DOCTYPE for example.
>> Thanks for your indulgence.[/color]
>
> If you add a strict DOCTYPE the table fails to work (well not on IE
> of course). However that is because he failed to put '#'
> (bgcolor="00000 0").[/color]

One must repair errors as well. <g>

--
-bts
-This space intentionally left blank.

[dterrors@hotmail.com]

Re: Preparing to write a post that blasts CSS.

Your html still has the infinite horizontal scroll bar problem in IE.
It may be simpler but it solves nothing.

[dterrors@hotmail.com]

Re: Preparing to write a post that blasts CSS.

All this says is that the "box width" is calculated by including the
margins and border. It doesn't say that when an outer div is deciding
how wide to be, it should include the inner div/table's border's and
margins. In other words, the outer div is supposed to ignore the
inner div's border and margin even though it's part of the "box width".


Seriously, look at the firefox bug url I gave you.

[Lauri Raittila]

Re: Preparing to write a post that blasts CSS.

in comp.infosystem s.www.authoring.stylesheets, dterrors@hotmai l.com
wrote:[color=blue]
> Your html still has the infinite horizontal scroll bar problem in IE.
> It may be simpler but it solves nothing.[/color]

I was too soon to say yoy didn't miss my killfile (forgot to put you
there apparently), but

http://www.student.oulu.fi/~laurirai/www/test/iehoverimage.html

Google for quirks mode.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Kohtuuhintainen yksiö/huone haussa Oulusta syyskuusta eteenpäin.
Searching places to sleep on axis Bonn - Tsech - Poland - baltic sea in
july

[Michael Winter]

Re: Preparing to write a post that blasts CSS.

On 28/06/2005 06:32, dterrors@hotmai l.com wrote:
[color=blue]
> All this says is that the "box width" is calculated by including the
> margins and border. It doesn't say that when an outer div is deciding
> how wide to be, it should include the inner div/table's border's and
> margins.[/color]

The algorithm clearly states that an unconstrained block level element
will take all the space it can. So, with:

#outer {
width: auto;

/* These are normally the default: */
margin: 0;
padding: 0;
border-style: none;
}

<body>
<div id="outer">
...
</div>
</body>

the content area of #outer will span the complete content width of the
BODY element. If you then add inner block level elements with explicit
100% content widths, they will have the same width as #outer. If those
inner elements have margins, padding, or borders, then their content
width will be the same, but the dimensions of those added features will
then cause the box to overflow.

In the case you presented, the outer DIV element had a border and an
explicit 100% width. So, it's content width will be the same as the
viewport minus the margin/padding/border of the BODY element. The border
of that outer element will then add two pixels to that, extending it two
pixels beyond the right-hand edge of the BODY element.

Next, you had a TABLE element (though it could have been any block level
element) with a wide margin (10px), border (4px), and an explicit 100%
content width. As the values are over-constrained, the right margin is
ignored, but again the content width will be the same as the above, and
again we must add the extra box surroundings: a total of eighteen
pixels. Add that to the left border of the DIV element, and the TABLE
element will extend nineteen pixels beyond the right-hand edge of the
BODY element. As the right margin/padding of the BODY element will only
be ten pixels (in most cases), the TABLE will extend ten pixels off the
right-hand edge of the viewport.

[snip]
[color=blue]
> Seriously, look at the firefox bug url I gave you.[/color]

You did notice that it was marked as 'resolved invalid', didn't you?
That means the 'bug' is nonsense and Firefox is acting correctly.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.