simpler example of the padding bug

[phil-news-nospam@ipal.net]

Here is a simpler (no drop shadows) example of the padding bug I see:

http://phil.ipal.org/usenet/ciwas/2006-05-08/buttons-1.html

So far I find nothing in the CSS2 document that says I should get this
kind of inconsistent result.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

[ironcorona]

Re: simpler example of the padding bug

phil-news-nospam@ipal.net wrote:[color=blue]
> Here is a simpler (no drop shadows) example of the padding bug I see:
>
> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
>
> So far I find nothing in the CSS2 document that says I should get this
> kind of inconsistent result.[/color]

It's only a bug if you've done it correctly and it *still* doesn't work.

From the above mentioned web page:

"Each table cell is wrapped in a 1px solid red border. Each table cell
also has 2px of its own padding just to get the red border a little
distant from the button so it is easier to see. Notice how the table
cell padding is NOT symmetrical (another bug?)."

Removing height:100%; and width:100%; from .menu_button solves this
problem. It's not a bug.


Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
you might wish to alter *to* the following code:

..pad_top {
margin-top: 20px;
padding-top: 20px;
}
..pad_right {
margin-right: 20px;
padding-right:20px;
}
..pad_bottom {
margin-bottom: 20px;
padding-bottom: 20px;
}
..pad_left {
margin-left: 20px;
padding-left: 20px;
}

If I've missed any of the questions posed on the page I'd be happy to
address them if you mention what they are.


--
Brian O'Connor (ironcorona)

[ironcorona]

Re: simpler example of the padding bug

ironcorona wrote:[color=blue]
> phil-news-nospam@ipal.net wrote:[color=green]
>> Here is a simpler (no drop shadows) example of the padding bug I see:
>>
>> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
>>
>> So far I find nothing in the CSS2 document that says I should get this
>> kind of inconsistent result.[/color]
>
> It's only a bug if you've done it correctly and it *still* doesn't work.
>
> From the above mentioned web page:
>
> "Each table cell is wrapped in a 1px solid red border. Each table cell
> also has 2px of its own padding just to get the red border a little
> distant from the button so it is easier to see. Notice how the table
> cell padding is NOT symmetrical (another bug?)."
>
> Removing height:100%; and width:100%; from .menu_button solves this
> problem. It's not a bug.
>
>
> Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
> you might wish to alter *to* the following code:
>
> .pad_top {
> margin-top: 20px;
> padding-top: 20px;
> }
> .pad_right {
> margin-right: 20px;
> padding-right:20px;
> }
> .pad_bottom {
> margin-bottom: 20px;
> padding-bottom: 20px;
> }
> .pad_left {
> margin-left: 20px;
> padding-left: 20px;
> }
>
> If I've missed any of the questions posed on the page I'd be happy to
> address them if you mention what they are.[/color]

ps. You might want to view the page in IE, where the display:table; and
all the associated properties are not supported.


--
Brian O'Connor (ironcorona)

[phil-news-nospam@ipal.net]

Re: simpler example of the padding bug

On Tue, 09 May 2006 02:28:26 +0800 ironcorona <iron.corona@gm ail.com> wrote:
| ironcorona wrote:
|> phil-news-nospam@ipal.net wrote:
|>> Here is a simpler (no drop shadows) example of the padding bug I see:
|>>
|>> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
|>>
|>> So far I find nothing in the CSS2 document that says I should get this
|>> kind of inconsistent result.
|>
|> It's only a bug if you've done it correctly and it *still* doesn't work.
|>
|> From the above mentioned web page:
|>
|> "Each table cell is wrapped in a 1px solid red border. Each table cell
|> also has 2px of its own padding just to get the red border a little
|> distant from the button so it is easier to see. Notice how the table
|> cell padding is NOT symmetrical (another bug?)."
|>
|> Removing height:100%; and width:100%; from .menu_button solves this
|> problem. It's not a bug.

Then what do you suggest to get the box inside the table cell to expand
to fully fill the table cell? The use of height:100% and width:100% was
what was recommended in an another example elsewhere.

Still, it makes no sense that padding added to the left side should grow
the right side, and especially to do so _beyond_ the bounds of the containing
element (the table cell). This is not what the CSS2 document describes.
Could you describe the definitions and/or mechanisms of why this kind of
padding effect should happen and only should with width/height at 100%?
I'm trying to make sense of this (it doesn't make any on its own).

It does seem to be a general problem with HTML layout to get stuff to
expand and fill out the container it is in. And sometimes, even the
reverse is true. Try getting a standalone box to just enclose a piece
of text without expanding to the whole display width. That has been
dealt with in the paste with HTML tables, transparent GIFs, and other
things some people don't like. To get away from those hacks, there does
need to be a right way to do all the things people want to do.


|> Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
|> you might wish to alter *to* the following code:
|>
|> .pad_top {
|> margin-top: 20px;
|> padding-top: 20px;
|> }
|> .pad_right {
|> margin-right: 20px;
|> padding-right:20px;
|> }
|> .pad_bottom {
|> margin-bottom: 20px;
|> padding-bottom: 20px;
|> }
|> .pad_left {
|> margin-left: 20px;
|> padding-left: 20px;
|> }
|>
|> If I've missed any of the questions posed on the page I'd be happy to
|> address them if you mention what they are.
|
| ps. You might want to view the page in IE, where the display:table; and
| all the associated properties are not supported.

No IE running here. Sorry. They don't make a portable version of it.
Since Firefox is portable to Windows, I can at least recommend it to
Windows users.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

[phil-news-nospam@ipal.net]

Re: simpler example of the padding bug

On Tue, 09 May 2006 02:27:03 +0800 ironcorona <iron.corona@gm ail.com> wrote:

| Removing height:100%; and width:100%; from .menu_button solves this
| problem. It's not a bug.

Actually it seems height:100%; is not a factor in this at all. Given that
the effect happens horizontally ... but NOT vertically ... it is quite
believable that height:100%; would not affect it, but width:100%; would.

But this still isn't very consistent because vertical and horizontal
are behaving differently (vertical does not have the "bug").

It is not the way the box model is described in the CSS2 document, and
it also exceeds the containing element.

| Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
| you might wish to alter *to* the following code:
|
| .pad_top {
| margin-top: 20px;
| padding-top: 20px;
| }
| .pad_right {
| margin-right: 20px;
| padding-right:20px;
| }
| .pad_bottom {
| margin-bottom: 20px;
| padding-bottom: 20px;
| }
| .pad_left {
| margin-left: 20px;
| padding-left: 20px;
| }

What's the purpose of that? I tried it and it only made things worse.

My objective is to have a container box inside of a table cell that fills
the table cell regardless of the size of what is inside of that box. If
the contents of the box need a larger box, then it should expand the table
cell to accomodate, along with expanding everything else in the appropriate
direction of the table so all cells/boxes in the same row have the same
height and all cells/boxes in the same column have the same width.

If there's a way to also make all table columns the same width, and all
table rows the same height, that would be a plus for certain projects.
Note, absolute sizing isn't what I'm asking for. I want it to all be the
minimum size needed for the largest object to fit, whatever that might
happen to be.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

[ironcorona]

Re: simpler example of the padding bug

phil-news-nospam@ipal.net wrote:
[color=blue]
> | Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
> | you might wish to alter *to* the following code:
> |
> | .pad_top {
> | margin-top: 20px;
> | padding-top: 20px;
> | }
> | .pad_right {
> | margin-right: 20px;
> | padding-right:20px;
> | }
> | .pad_bottom {
> | margin-bottom: 20px;
> | padding-bottom: 20px;
> | }
> | .pad_left {
> | margin-left: 20px;
> | padding-left: 20px;
> | }
>
> What's the purpose of that? I tried it and it only made things worse.[/color]

Just take out the width:100% and the height:100% AND change the .pad
parts in the way I've shown. Then have a look at it.

[color=blue]
> If there's a way to also make all table columns the same width, and all
> table rows the same height, that would be a plus for certain projects.
> Note, absolute sizing isn't what I'm asking for. I want it to all be the
> minimum size needed for the largest object to fit, whatever that might
> happen to be.[/color]

If you do what I've said then it will expand to fit whatever content.
Actually, to make things easier here's the whole code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Title? We don't need no steekin title!</title>

<style type="text/css">
body {
background-color: #ffffff;
color: #000000;
}
..hmenu {
display: table;
border-collapse: separate;
border-spacing: 14px;
border: 1px solid #0000ff;
}
..hmenu_row {
display: table-row;
border: 1px solid #00ff00;
}
..hmenu_cell {
display: table-cell;
border: 1px solid #ff0000;
padding: 2px 2px 2px 2px;
}
..shift {
position: relative;
top: 9px;
}
..menu_button {

margin: 0px 0px 0px 0px;
padding: 0px 0px 0px 0px;
border: 1px solid #88aacc;
background-color: #eff7ff;
color: #001122;
}
..pad_top {
margin-top: 20px;
padding-top: 20px;
}
..pad_right {
margin-right: 20px;
padding-right:20px;
}
..pad_bottom {
margin-bottom: 20px;
padding-bottom: 20px;
}
..pad_left {
margin-left: 20px;
padding-left: 20px;
}
..menu_button:h over {
border: 1px solid #ccaa88;
background-color: #fff7ef;
color: #221100;
}
..menu_button:a ctive {
border: 1px solid #88cc88;
background-color: #efffef;
color: #004400;
}
..menu_button a {
margin: 0px 0px 0px 0px;
padding: 0px 0px 0px 0px;
color: #001122;
text-decoration: none;
}
..menu_button a:link {
color: #001122;
}
..menu_button a:visited {
color: #aabbcc;
}
..menu_button a:hover {
color: #221100;
}
..menu_button a:active {
color: #004400;
}

</style>

</head>

<body>

<p>
These buttons are made with hyperlinked text inside a box, which is
inside a table cell of a one row table.
The table uses HTML DIV elements and CSS table-* property values.
The whole table is wrapped in a 1px solid blue border, with 14px of
border spacing.
Each table row is wrapped in a 1px solid green border (which does
<em>NOT</em> show up).
Each table cell is wrapped in a 1px solid red border.
Each table cell also has 2px of its own padding just to get the red
border a little distant from the button so it is easier to see.
Notice how the table cell padding is <em>NOT</em> symmetrical (another
bug?).
Each button box is background colored light blue with a 1px solid blue
border.
The button box color will change with hover to light orange with a 1px
solid orange border.
The button box color will change with click to light green with a 1px
solid green border.
The "Sit" button is intentionally shifted down by 9px to show how the
padding overlap is taking place.
The shift is done by adding a class to the HTML DIV element for the
button box.
The various padding tests are applied by adding a class to the HTML DIV
element for the button box that adds 20px of padding for the specified side.

</p>

<p>
The stylesheet is embedded in the HTML, so it can be viewed when the
HTML source ie viewed.
</p>

<p>
<b>No padding</b> - except for that 2px inside the table cell which does
not expand the blue button box.
<div class="hmenu">< div class="hmenu_ro w">
<div class="hmenu_ce ll"><div class="menu_but ton"><a
href="#lorem">L orem</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton"><a
href="#ipsum">I psum</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton"><a
href="#dolor">D olor</a></div></div>

<div class="hmenu_ce ll"><div class="menu_but ton shift"><a
href="#sit">Sit </a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton"><a
href="#amet">Am et</a></div></div>
</div></div>
</p>

<p>
<b>Padding on top and bottom</b> - this works as expected. If I specify
Npx of padding, I expect to get Npx of padding.
<div class="hmenu">< div class="hmenu_ro w">
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_bottom"><a
href="#lorem">L orem</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_bottom"><a
href="#ipsum">I psum</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_bottom"><a
href="#dolor">D olor</a></div></div>

<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_bottom
shift"><a href="#sit">Sit </a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_bottom"><a
href="#amet">Am et</a></div></div>
</div></div>
</p>

<p>
<b>Padding on left only</b> - notice how the padding is additionally
added to the right, but that the containing table cell does not expand
for it.
<div class="hmenu">< div class="hmenu_ro w">
<div class="hmenu_ce ll"><div class="menu_but ton pad_left"><a
href="#lorem">L orem</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_left"><a
href="#ipsum">I psum</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_left"><a
href="#dolor">D olor</a></div></div>

<div class="hmenu_ce ll"><div class="menu_but ton pad_left shift"><a
href="#sit">Sit </a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_left"><a
href="#amet">Am et</a></div></div>
</div></div>
</p>

<p>
<b>Padding on right only</b> - notice how the padding is twice as much
as specified, and the containing table cell is expanded only for a
single amount.
<div class="hmenu">< div class="hmenu_ro w">
<div class="hmenu_ce ll"><div class="menu_but ton pad_right"><a
href="#lorem">L orem</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_right"><a
href="#ipsum">I psum</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_right"><a
href="#dolor">D olor</a></div></div>

<div class="hmenu_ce ll"><div class="menu_but ton pad_right shift"><a
href="#sit">Sit </a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_right"><a
href="#amet">Am et</a></div></div>
</div></div>
</p>

<p>
<b>Padding on left and right</b> - notice how there is a total of twice
as much padding as actually specified but the containing table cell is
expanded for a single amount.
<div class="hmenu">< div class="hmenu_ro w">
<div class="hmenu_ce ll"><div class="menu_but ton pad_right pad_left"><a
href="#lorem">L orem</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_right pad_left"><a
href="#ipsum">I psum</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_right pad_left"><a
href="#dolor">D olor</a></div></div>

<div class="hmenu_ce ll"><div class="menu_but ton pad_right pad_left
shift"><a href="#sit">Sit </a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_right pad_left"><a
href="#amet">Am et</a></div></div>
</div></div>
</p>

<p>
<b>Padding on all four sides</b> - all I wanted was a symmetrical
upsizing of the text button box.
<div class="hmenu">< div class="hmenu_ro w">
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_right
pad_bottom pad_left"><a href="#lorem">L orem</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_right
pad_bottom pad_left"><a href="#ipsum">I psum</a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_right
pad_bottom pad_left"><a href="#dolor">D olor</a></div></div>

<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_right
pad_bottom pad_left shift"><a href="#sit">Sit </a></div></div>
<div class="hmenu_ce ll"><div class="menu_but ton pad_top pad_right
pad_bottom pad_left"><a href="#amet">Am et</a></div></div>
</div></div>
</p>

</body>

</html>


--
Brian O'Connor (ironcorona)

[ironcorona]

Re: simpler example of the padding bug

phil-news-nospam@ipal.net wrote:[color=blue]
> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <iron.corona@gm ail.com> wrote:
> | ironcorona wrote:
> |> phil-news-nospam@ipal.net wrote:
> |>> Here is a simpler (no drop shadows) example of the padding bug I see:
> |>>
> |>> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
> |>>
> |>> So far I find nothing in the CSS2 document that says I should get this
> |>> kind of inconsistent result.
> |>
> |> It's only a bug if you've done it correctly and it *still* doesn't work.
> |>
> |> From the above mentioned web page:
> |>
> |> "Each table cell is wrapped in a 1px solid red border. Each table cell
> |> also has 2px of its own padding just to get the red border a little
> |> distant from the button so it is easier to see. Notice how the table
> |> cell padding is NOT symmetrical (another bug?)."
> |>
> |> Removing height:100%; and width:100%; from .menu_button solves this
> |> problem. It's not a bug.
>
> Then what do you suggest to get the box inside the table cell to expand
> to fully fill the table cell? The use of height:100% and width:100% was
> what was recommended in an another example elsewhere.
>
> Still, it makes no sense that padding added to the left side should grow
> the right side,[/color]

It's because of your code. You had the buttons as 100% of it's parent
element. Then you added 20px padding to the parent element. Now the
button on the inside is 100% (of the content area) of the parent + 20px.
So 100% + 20px = bigger than the parent element. The browser then
*has* to push the content outside.
[color=blue]
> and especially to do so _beyond_ the bounds of the containing
> element (the table cell). This is not what the CSS2 document describes.
> Could you describe the definitions and/or mechanisms of why this kind of
> padding effect should happen and only should with width/height at 100%?
> I'm trying to make sense of this (it doesn't make any on its own).[/color]

Read up on how the box model functions.
[color=blue]
> It does seem to be a general problem with HTML layout to get stuff to
> expand and fill out the container it is in. And sometimes, even the
> reverse is true. Try getting a standalone box to just enclose a piece
> of text without expanding to the whole display width. That has been
> dealt with in the paste with HTML tables, transparent GIFs, and other
> things some people don't like. To get away from those hacks, there does
> need to be a right way to do all the things people want to do.
>
>
> |> Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
> |> you might wish to alter *to* the following code:
> |>
> |> .pad_top {
> |> margin-top: 20px;
> |> padding-top: 20px;
> |> }
> |> .pad_right {
> |> margin-right: 20px;
> |> padding-right:20px;
> |> }
> |> .pad_bottom {
> |> margin-bottom: 20px;
> |> padding-bottom: 20px;
> |> }
> |> .pad_left {
> |> margin-left: 20px;
> |> padding-left: 20px;
> |> }
> |>
> |> If I've missed any of the questions posed on the page I'd be happy to
> |> address them if you mention what they are.
> |
> | ps. You might want to view the page in IE, where the display:table; and
> | all the associated properties are not supported.
>
> No IE running here. Sorry. They don't make a portable version of it.
> Since Firefox is portable to Windows, I can at least recommend it to
> Windows users.[/color]

Yes but only about 10% of them. Maybe even less.


--
Brian O'Connor (ironcorona)

[phil-news-nospam@ipal.net]

Re: simpler example of the padding bug

On Tue, 09 May 2006 04:12:58 +0800 ironcorona <iron.corona@gm ail.com> wrote:
| phil-news-nospam@ipal.net wrote:
|> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <iron.corona@gm ail.com> wrote:
|> | ironcorona wrote:
|> |> phil-news-nospam@ipal.net wrote:
|> |>> Here is a simpler (no drop shadows) example of the padding bug I see:
|> |>>
|> |>> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
|> |>>
|> |>> So far I find nothing in the CSS2 document that says I should get this
|> |>> kind of inconsistent result.
|> |>
|> |> It's only a bug if you've done it correctly and it *still* doesn't work.
|> |>
|> |> From the above mentioned web page:
|> |>
|> |> "Each table cell is wrapped in a 1px solid red border. Each table cell
|> |> also has 2px of its own padding just to get the red border a little
|> |> distant from the button so it is easier to see. Notice how the table
|> |> cell padding is NOT symmetrical (another bug?)."
|> |>
|> |> Removing height:100%; and width:100%; from .menu_button solves this
|> |> problem. It's not a bug.
|>
|> Then what do you suggest to get the box inside the table cell to expand
|> to fully fill the table cell? The use of height:100% and width:100% was
|> what was recommended in an another example elsewhere.
|>
|> Still, it makes no sense that padding added to the left side should grow
|> the right side,
|
| It's because of your code. You had the buttons as 100% of it's parent
| element. Then you added 20px padding to the parent element. Now the
| button on the inside is 100% (of the content area) of the parent + 20px.
| So 100% + 20px = bigger than the parent element. The browser then
| *has* to push the content outside.

The CSS document describes the width of a block as being the sum of the
width of the contained content, plus the padding, plus the border, plus
the margin.

No, the browser does NOT have to push the content outside. It could,
instead, make the containing element larger. In fact, it did just that.
It did it vertically with no other effects. For horizontal, it also
did it (you can check and see that the enclosing cell actually did get
larger by 20px). But for that 20px of padding given on the left in one
case, or on the right in another case, it expanded the element NOT by
20px, but by 40px. So what you just described is NOT what actually did
happen. Explain why adding 20px of padding on the left causes the box
to get wider by 40px. And explain why what you described did not happen
at all vertically.


|> and especially to do so _beyond_ the bounds of the containing
|> element (the table cell). This is not what the CSS2 document describes.
|> Could you describe the definitions and/or mechanisms of why this kind of
|> padding effect should happen and only should with width/height at 100%?
|> I'm trying to make sense of this (it doesn't make any on its own).
|
| Read up on how the box model functions.

I did before I even posted. I did before I even tried all this, and
also again afterwards just before posting. I didn't see anything that
supports the effect I get. I also didn't see anything that supports
what you described (which is different than the effect I get).

Suppose some browser (or maybe even Firefox) were do to what *I* expect
of it with that code I used. What argument would you use to explain why
the result is not compliant with the standard for CSS? And would you
use this argument only for the horizontal aspect, or would you also use
it for the vertical aspect (that does what I expected, and not what you
described, even now).


|> |> If I've missed any of the questions posed on the page I'd be happy to
|> |> address them if you mention what they are.
|> |
|> | ps. You might want to view the page in IE, where the display:table; and
|> | all the associated properties are not supported.
|>
|> No IE running here. Sorry. They don't make a portable version of it.
|> Since Firefox is portable to Windows, I can at least recommend it to
|> Windows users.
|
| Yes but only about 10% of them. Maybe even less.

10% of what? I can recommend FF to 100% of users. Maybe 10% of them
might actually try it. But I won't lose sleep over what someone else
decides to do on their computer. If they complain that the page does
not display properly, I'll explain that they have 2 choices: use FF,
or ask MSFT for a fully CSS2 complaint browser. I won't really care
which they choose.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

[phil-news-nospam@ipal.net]

Re: simpler example of the padding bug

On Tue, 09 May 2006 04:03:04 +0800 ironcorona <iron.corona@gm ail.com> wrote:
| phil-news-nospam@ipal.net wrote:
|
|> | Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
|> | you might wish to alter *to* the following code:
|> |
|> | .pad_top {
|> | margin-top: 20px;
|> | padding-top: 20px;
|> | }
|> | .pad_right {
|> | margin-right: 20px;
|> | padding-right:20px;
|> | }
|> | .pad_bottom {
|> | margin-bottom: 20px;
|> | padding-bottom: 20px;
|> | }
|> | .pad_left {
|> | margin-left: 20px;
|> | padding-left: 20px;
|> | }
|>
|> What's the purpose of that? I tried it and it only made things worse.
|
| Just take out the width:100% and the height:100% AND change the .pad
| parts in the way I've shown. Then have a look at it.

I did. So. I can see it changes the effect on the width expansion.

The margin settings did nothing. I'm not sure if they should, or should
not, but I have found that margin settings don't affect things inside of
table cells, either HTML tables or CSS tables. This is inside of table
cells, and the lack of effect is at least consistent with what I have
seen elsewhere.

But I still want to know why it is something gets 40px wider when I put
only 20px of padding on the left (or on the right). Why would it have
to be doubled?


|> If there's a way to also make all table columns the same width, and all
|> table rows the same height, that would be a plus for certain projects.
|> Note, absolute sizing isn't what I'm asking for. I want it to all be the
|> minimum size needed for the largest object to fit, whatever that might
|> happen to be.
|
| If you do what I've said then it will expand to fit whatever content.
| Actually, to make things easier here's the whole code:

The margin settings had no effect. Maybe that's a bug. But it's not one
that has caused me any troubles.

Since the margins are _outside_ of the border, if they did have an effect,
I would expect that effect to expand at most the margin edge to the inner
size of the container, and leave the border (20px in this case) smaller
than the container, which isn't the effect I want. I want the _border_
of the box to have its outer edge at the inner edge of the table cell (or
whatever is containing it in other cases).

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

[ironcorona]

Re: simpler example of the padding bug

phil-news-nospam@ipal.net wrote:[color=blue]
> On Tue, 09 May 2006 04:03:04 +0800 ironcorona <iron.corona@gm ail.com> wrote:
> | phil-news-nospam@ipal.net wrote:
> |
> |> | Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
> |> | you might wish to alter *to* the following code:
> |> |
> |> | .pad_top {
> |> | margin-top: 20px;
> |> | padding-top: 20px;
> |> | }
> |> | .pad_right {
> |> | margin-right: 20px;
> |> | padding-right:20px;
> |> | }
> |> | .pad_bottom {
> |> | margin-bottom: 20px;
> |> | padding-bottom: 20px;
> |> | }
> |> | .pad_left {
> |> | margin-left: 20px;
> |> | padding-left: 20px;
> |> | }
> |>
> |> What's the purpose of that? I tried it and it only made things worse.
> |
> | Just take out the width:100% and the height:100% AND change the .pad
> | parts in the way I've shown. Then have a look at it.
>
> I did. So. I can see it changes the effect on the width expansion.
>
> The margin settings did nothing. I'm not sure if they should, or should
> not, but I have found that margin settings don't affect things inside of
> table cells, either HTML tables or CSS tables. This is inside of table
> cells, and the lack of effect is at least consistent with what I have
> seen elsewhere.[/color]

The margin setting doesn't change anything inside the box. It's not
suppose to.

http://www.w3.org/TR/REC-CSS2/images/boxdim.gif

[color=blue]
>
> But I still want to know why it is something gets 40px wider when I put
> only 20px of padding on the left (or on the right). Why would it have
> to be doubled?[/color]

It doesn't, or at least I'm not seeing it. What browser are you using?
[color=blue]
> |> If there's a way to also make all table columns the same width, and all
> |> table rows the same height, that would be a plus for certain projects.
> |> Note, absolute sizing isn't what I'm asking for. I want it to all be the
> |> minimum size needed for the largest object to fit, whatever that might
> |> happen to be.
> |
> | If you do what I've said then it will expand to fit whatever content.
> | Actually, to make things easier here's the whole code:
>
> The margin settings had no effect. Maybe that's a bug. But it's not one
> that has caused me any troubles.[/color]

Stop thinking it's a bug. It operated the same on several browsers so
it's to do with the way you've handled the CSS.
[color=blue]
> Since the margins are _outside_ of the border, if they did have an effect,
> I would expect that effect to expand at most the margin edge to the inner
> size of the container, and leave the border (20px in this case) smaller
> than the container, which isn't the effect I want. I want the _border_
> of the box to have its outer edge at the inner edge of the table cell (or
> whatever is containing it in other cases).[/color]

In that case why did you have the outer box padded?

Can you draw a picture of *exactly* what it is you want. I think we
might be arguing different points here.


--
Brian O'Connor (ironcorona)

[ironcorona]

Re: simpler example of the padding bug

phil-news-nospam@ipal.net wrote:[color=blue]
> On Tue, 09 May 2006 04:12:58 +0800 ironcorona <iron.corona@gm ail.com> wrote:
> | phil-news-nospam@ipal.net wrote:
> |> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <iron.corona@gm ail.com> wrote:
> |> | ironcorona wrote:
> |> |> phil-news-nospam@ipal.net wrote:
> |> |>> Here is a simpler (no drop shadows) example of the padding bug I see:
> |> |>>
> |> |>> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
> |> |>>
> |> |>> So far I find nothing in the CSS2 document that says I should get this
> |> |>> kind of inconsistent result.
> |> |>
> |> |> It's only a bug if you've done it correctly and it *still* doesn't work.
> |> |>
> |> |> From the above mentioned web page:
> |> |>
> |> |> "Each table cell is wrapped in a 1px solid red border. Each table cell
> |> |> also has 2px of its own padding just to get the red border a little
> |> |> distant from the button so it is easier to see. Notice how the table
> |> |> cell padding is NOT symmetrical (another bug?)."
> |> |>
> |> |> Removing height:100%; and width:100%; from .menu_button solves this
> |> |> problem. It's not a bug.
> |>
> |> Then what do you suggest to get the box inside the table cell to expand
> |> to fully fill the table cell? The use of height:100% and width:100% was
> |> what was recommended in an another example elsewhere.
> |>
> |> Still, it makes no sense that padding added to the left side should grow
> |> the right side,
> |
> | It's because of your code. You had the buttons as 100% of it's parent
> | element. Then you added 20px padding to the parent element. Now the
> | button on the inside is 100% (of the content area) of the parent + 20px.
> | So 100% + 20px = bigger than the parent element. The browser then
> | *has* to push the content outside.
>
> The CSS document describes the width of a block as being the sum of the
> width of the contained content, plus the padding, plus the border, plus
> the margin.[/color]

No. that's the way that IE renders a block. When you set a width you
set the width of the content area. The margin, border and padding
values are then added on to this. EVEN if you set it to 100%.
[color=blue]
> No, the browser does NOT have to push the content outside. It could,
> instead, make the containing element larger.[/color]

It does on my fix.

[...]
[color=blue]
> Suppose some browser (or maybe even Firefox) were do to what *I* expect
> of it with that code I used. What argument would you use to explain why
> the result is not compliant with the standard for CSS? And would you
> use this argument only for the horizontal aspect, or would you also use
> it for the vertical aspect (that does what I expected, and not what you
> described, even now).[/color]

Get over the horizontal and vertical dimensions. They work slightly
different in practice. You have to assume that because the blue (link)
boxes got pushed outside the red boxes is because you've done something
wrong.

[...]
[color=blue]
> | Yes but only about 10% of them. Maybe even less.
>
> 10% of what? I can recommend FF to 100% of users. Maybe 10% of them
> might actually try it. But I won't lose sleep over what someone else
> decides to do on their computer. If they complain that the page does
> not display properly, I'll explain that they have 2 choices: use FF,
> or ask MSFT for a fully CSS2 complaint browser. I won't really care
> which they choose.[/color]

That's a stupid way to make a web site. You can't make it browser
specific and then expect people to download/install a new browser just
to look at your web page. The fact that IE renders things wrong doesn't
mean you have to ignore IE users you just have to figure out a work
around so that it works in IE.


--
Brian O'Connor (ironcorona)

[phil-news-nospam@ipal.net]

Re: simpler example of the padding bug

On Tue, 09 May 2006 12:32:48 +0800 ironcorona <iron.corona@gm ail.com> wrote:
| phil-news-nospam@ipal.net wrote:
|> On Tue, 09 May 2006 04:12:58 +0800 ironcorona <iron.corona@gm ail.com> wrote:
|> | phil-news-nospam@ipal.net wrote:
|> |> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <iron.corona@gm ail.com> wrote:
|> |> | ironcorona wrote:
|> |> |> phil-news-nospam@ipal.net wrote:
|> |> |>> Here is a simpler (no drop shadows) example of the padding bug I see:
|> |> |>>
|> |> |>> http://phil.ipal.org/usenet/ciwas/20...buttons-1.html
|> |> |>>
|> |> |>> So far I find nothing in the CSS2 document that says I should get this
|> |> |>> kind of inconsistent result.
|> |> |>
|> |> |> It's only a bug if you've done it correctly and it *still* doesn't work.
|> |> |>
|> |> |> From the above mentioned web page:
|> |> |>
|> |> |> "Each table cell is wrapped in a 1px solid red border. Each table cell
|> |> |> also has 2px of its own padding just to get the red border a little
|> |> |> distant from the button so it is easier to see. Notice how the table
|> |> |> cell padding is NOT symmetrical (another bug?)."
|> |> |>
|> |> |> Removing height:100%; and width:100%; from .menu_button solves this
|> |> |> problem. It's not a bug.
|> |>
|> |> Then what do you suggest to get the box inside the table cell to expand
|> |> to fully fill the table cell? The use of height:100% and width:100% was
|> |> what was recommended in an another example elsewhere.
|> |>
|> |> Still, it makes no sense that padding added to the left side should grow
|> |> the right side,
|> |
|> | It's because of your code. You had the buttons as 100% of it's parent
|> | element. Then you added 20px padding to the parent element. Now the
|> | button on the inside is 100% (of the content area) of the parent + 20px.
|> | So 100% + 20px = bigger than the parent element. The browser then
|> | *has* to push the content outside.
|>
|> The CSS document describes the width of a block as being the sum of the
|> width of the contained content, plus the padding, plus the border, plus
|> the margin.
|
| No. that's the way that IE renders a block. When you set a width you
| set the width of the content area. The margin, border and padding
| values are then added on to this. EVEN if you set it to 100%.

If that were so, then what I should see is that when I set the width to
100% inside a table cell, the outer edge of the content would be the same
as the inner edge of the table cell. With 0 for margin, border, and
padding, that is what I get. However, when I add to any of those, then
I see the table cell get larger. With your explanation, that should not
be happening. But it does happen.

So here's a test I did. I first have the 1px border in place on the box
and reload in Firefox. The left and right edges of the table cell border
for the 1st "Lorem" button are at pixel 31 and pixel 84. The top is at
415 and the bottom is at 453. The 2nd "Ipsum" button has them at 99 and
150 for left and right, and 415 and 453 for top and bottom. Then I change
the border to 0px and reload. Now the left and right positions for the
table cell on the 1st button are at 31 and 82, and for the 2nd button are
at 97 and 146. The top and bottom for both are now at 415 and 451. This
EXACTLY accounts for the 1px change. Because there are 2 borders, left
and right, in the first button, the right side of the cell moves left by
2px positions. That is what I expect with _my_ interpretation of width,
and that is what I get. The 2nd button's left cell edge moves left by 2px
and its right cell edge moves left by 4px. All as expected.

All of the above is exactly the same whether width:100% and height:100%
is specified or not.

With width:100% and height:100% the right edge of the button box is over
to the right, out of place, by 1px. Without width:100% and height:100%
it is in the correct position. I had not noticed this one issue before
until last night when a discussion about this with someone who found that
this had in fact been reported as a bug in Mozilla several times, in a
variety of different ways ... told me that the miscalulation of width was
affected by BOTH the padding (as I had seen) as well as the border. He
told me to make the border larger by as much as I make the padding larger
and I did in fact see the very same effect.

As it turns out, padding and border are added together rather early in both
layout and graphics sections of the code.


|> No, the browser does NOT have to push the content outside. It could,
|> instead, make the containing element larger.
|
| It does on my fix.

Because with or without width:100% it goes through different parts of
the layout and rendering code. I've already been going through the code
to see where this is happening. One observation I have is that the layout
being done is actually correct. It's the rendering ... the graphics drawing,
that comes out wrong.


|> Suppose some browser (or maybe even Firefox) were do to what *I* expect
|> of it with that code I used. What argument would you use to explain why
|> the result is not compliant with the standard for CSS? And would you
|> use this argument only for the horizontal aspect, or would you also use
|> it for the vertical aspect (that does what I expected, and not what you
|> described, even now).
|
| Get over the horizontal and vertical dimensions. They work slightly
| different in practice. You have to assume that because the blue (link)
| boxes got pushed outside the red boxes is because you've done something
| wrong.

I don't make assumptions like that.

I think it may be a bug in Mozilla's rendering code. But it may even be
in GTK or elsewhere. But I've talked about this with some other people
who deal with Firefox bugs, and they've all agreed it is a bug.

No, I still cannot rule out that I am doing something wrong. But the
analysis at this point strongly suggests that it is highly likely a bug.


|> | Yes but only about 10% of them. Maybe even less.
|>
|> 10% of what? I can recommend FF to 100% of users. Maybe 10% of them
|> might actually try it. But I won't lose sleep over what someone else
|> decides to do on their computer. If they complain that the page does
|> not display properly, I'll explain that they have 2 choices: use FF,
|> or ask MSFT for a fully CSS2 complaint browser. I won't really care
|> which they choose.
|
| That's a stupid way to make a web site. You can't make it browser
| specific and then expect people to download/install a new browser just
| to look at your web page. The fact that IE renders things wrong doesn't
| mean you have to ignore IE users you just have to figure out a work
| around so that it works in IE.

If Microsoft had not adopted CSS at all, would you still be saying this?

I will try, within reason, to make it display reasonably on IE. And if
that fails, I will try, within reason, to make it "degrade gracefully"
(to borrow a common phrase from the "web standards" community). To the
extent that IE fails to then display things properly, I will make my
recommendation to use Firefox. I may host a "Get Firefox" button on my
sites (or at least some of them). I won't host a "Get Explorer" button.

Don't forget, we're talking about a company that intentionally does NOT
want interoperabilit y to work. But it's not our responsibility to make
up for everything they do.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

[phil-news-nospam@ipal.net]

Re: simpler example of the padding bug

On Tue, 09 May 2006 12:23:48 +0800 ironcorona <iron.corona@gm ail.com> wrote:
| phil-news-nospam@ipal.net wrote:
|> On Tue, 09 May 2006 04:03:04 +0800 ironcorona <iron.corona@gm ail.com> wrote:
|> | phil-news-nospam@ipal.net wrote:
|> |
|> |> | Where you have .pad_top, .pad_right, .pad_bottom, .pad_left
|> |> | you might wish to alter *to* the following code:
|> |> |
|> |> | .pad_top {
|> |> | margin-top: 20px;
|> |> | padding-top: 20px;
|> |> | }
|> |> | .pad_right {
|> |> | margin-right: 20px;
|> |> | padding-right:20px;
|> |> | }
|> |> | .pad_bottom {
|> |> | margin-bottom: 20px;
|> |> | padding-bottom: 20px;
|> |> | }
|> |> | .pad_left {
|> |> | margin-left: 20px;
|> |> | padding-left: 20px;
|> |> | }
|> |>
|> |> What's the purpose of that? I tried it and it only made things worse.
|> |
|> | Just take out the width:100% and the height:100% AND change the .pad
|> | parts in the way I've shown. Then have a look at it.
|>
|> I did. So. I can see it changes the effect on the width expansion.
|>
|> The margin settings did nothing. I'm not sure if they should, or should
|> not, but I have found that margin settings don't affect things inside of
|> table cells, either HTML tables or CSS tables. This is inside of table
|> cells, and the lack of effect is at least consistent with what I have
|> seen elsewhere.
|
| The margin setting doesn't change anything inside the box. It's not
| suppose to.
| http://www.w3.org/TR/REC-CSS2/images/boxdim.gif

Uh, I never said it should affect things inside the box. You can reread
what I said and see that I was referring to the table cell that is the
parent container of the box, as what may or may not be changed.


|> But I still want to know why it is something gets 40px wider when I put
|> only 20px of padding on the left (or on the right). Why would it have
|> to be doubled?
|
| It doesn't, or at least I'm not seeing it. What browser are you using?

Firefox 1.5.0.3 for Linux x86.

When I add Npx to the padding, or the border, of the box inside the table
cell, the table cell grows by Npx. And that happens whether width:100%
and/or height:100% is specified or not. The calculations of what size the
parent (table cell) should be _are_ being done correctly, and exactly as I
expected them to be by my understanding of CSS2, with respect to the padding
and border specifications on the box.

When I add Npx to the padding, or the border, of the box inside the table
cell, the box itself grows by 2Npx (when width and height are specified).
That is NOT explained by CSS2 at all. Nor has anyone else explained why
this should be the case.

One thing I have noticed is that the effect of the padding overflow is in
proportion to the width percentage used. At 100%, the added width is 2x
what I add to padding. At 75% it is about 1.5x. At 50% it is 1x. At 25%
it is about 0.5x. I would expect it to be proportional. But I would also
expect 100% to be 1x and 50% to be 0.5x ... not the doubled amount. I just
did notice this, and it suggests to me that the width calculation is wrong
in a different place.

This 2x problem DOES NOT happen for vertical.


|> |> If there's a way to also make all table columns the same width, and all
|> |> table rows the same height, that would be a plus for certain projects.
|> |> Note, absolute sizing isn't what I'm asking for. I want it to all be the
|> |> minimum size needed for the largest object to fit, whatever that might
|> |> happen to be.
|> |
|> | If you do what I've said then it will expand to fit whatever content.
|> | Actually, to make things easier here's the whole code:
|>
|> The margin settings had no effect. Maybe that's a bug. But it's not one
|> that has caused me any troubles.
|
| Stop thinking it's a bug. It operated the same on several browsers so
| it's to do with the way you've handled the CSS.

Since you have not explained how an interpretation of CSS2 would justify why
adding Npx to the padding of the box would expand its own border by 2Npx, and
do so only on horizontal and not vertical, I will favor the bug scenario.

What other browsers do you see this 2Npx effect taking place on, that are NOT
based on the Moz/Gecko engine (not even stealing from its code base)?


|> Since the margins are _outside_ of the border, if they did have an effect,
|> I would expect that effect to expand at most the margin edge to the inner
|> size of the container, and leave the border (20px in this case) smaller
|> than the container, which isn't the effect I want. I want the _border_
|> of the box to have its outer edge at the inner edge of the table cell (or
|> whatever is containing it in other cases).
|
| In that case why did you have the outer box padded?
|
| Can you draw a picture of *exactly* what it is you want. I think we
| might be arguing different points here.

What I want is a general category of re-stylable buttons, which may or may
not have borders and/or background colors (though having neither border nor
background color is undersirable).

What I want is that when I add Npx of padding to a box, that border of that
box, for a constant content size, grows outward by exactly Npx, not 2Npx.

The table cells were added to line up the boxes as buttons. They were also
used in the illustration of the problem because it provided a convenient
2nd border to show that the layout calculations were in fact using Npx and
not 2Npx (as they should).

I still don't udnerstand why you are not addressing why the border should
grow by 2Npx for 1Npx of padding added to that box, only in the horizontal.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

[ironcorona]

Re: simpler example of the padding bug

phil-news-nospam@ipal.net wrote:
[color=blue]
> When I add Npx to the padding, or the border, of the box inside the[/color]
table[color=blue]
> cell, the table cell grows by Npx. And that happens whether width:100%
> and/or height:100% is specified or not. The calculations of what size the
> parent (table cell) should be _are_ being done correctly, and exactly as I
> expected them to be by my understanding of CSS2, with respect to the padding
> and border specifications on the box.
>
> When I add Npx to the padding, or the border, of the box inside the table
> cell, the box itself grows by 2Npx (when width and height are specified).
> That is NOT explained by CSS2 at all. Nor has anyone else explained why
> this should be the case.
>
> One thing I have noticed is that the effect of the padding overflow is in
> proportion to the width percentage used. At 100%, the added width is 2x
> what I add to padding. At 75% it is about 1.5x. At 50% it is 1x. At 25%
> it is about 0.5x. I would expect it to be proportional. But I would also
> expect 100% to be 1x and 50% to be 0.5x ... not the doubled amount. I just
> did notice this, and it suggests to me that the width calculation is wrong
> in a different place.
>
> This 2x problem DOES NOT happen for vertical.[/color]
[color=blue]
> Since you have not explained how an interpretation of CSS2 would justify why
> adding Npx to the padding of the box would expand its own border by 2Npx, and
> do so only on horizontal and not vertical, I will favor the bug scenario.[/color]

a bug with what? The CSS spec is, by definition, correct. There can't
be a bug in it. If you're talking about a bug in the browser I don't
think so because it looks the same in Opera (which *fully* implements
the spec)
[color=blue]
> What other browsers do you see this 2Npx effect taking place on, that are NOT
> based on the Moz/Gecko engine (not even stealing from its code base)?[/color]

Just to make sure we're seeing the same thing I've taken some screen shots.

Here's your original in FF 1.5.0.3 on Win XP

http://iron.corona.googlepages.com/original_ff.jpg

Here's your original in Opera 9.0 beta

http://iron.corona.googlepages.com/original_opera.jpg

Here's your original in IE6 [and this is the important one because IE
doesn't have any support for display:table-cell OR table-row]

http://iron.corona.googlepages.com/original_ie.jpg

Here's the version with my fix in FF

http://iron.corona.googlepages.com/myfix_ff.jpg

As you can see your original page looks the same in opera and in ff. It
doesn't work at all in IE, which is why you shouldn't make the page this
way because the 90% of potential viewers out there who use IE can't see
the page properly.

Please tell me if you're seeing the same thing and if my fix version is
what you want to be seeing.

[color=blue]
> What I want is a general category of re-stylable buttons, which may or may
> not have borders and/or background colors (though having neither border nor
> background color is undersirable).
>
> What I want is that when I add Npx of padding to a box, that border of that
> box, for a constant content size, grows outward by exactly Npx, not 2Npx.[/color]

As I've mentioned before I didn't see the 2Npx effect in any of my browsers.
[color=blue]
> The table cells were added to line up the boxes as buttons. They were also
> used in the illustration of the problem because it provided a convenient
> 2nd border to show that the layout calculations were in fact using Npx and
> not 2Npx (as they should).
>
> I still don't udnerstand why you are not addressing why the border should
> grow by 2Npx for 1Npx of padding added to that box, only in the horizontal.[/color]

If you're talking about why it's not happening in your original, it's
because the CSS isn't entirely correct. If you're asking about why it
happens after my fix; it doesn't.


Just answer my questions above and then we can address the padding
problem. I just need to make sure we're both singing from the same hymn
sheet on this.

--
Brian O'Connor (ironcorona)

[ironcorona]

Re: simpler example of the padding bug

phil-news-nospam@ipal.net wrote:
[color=blue]
> If that were so, then what I should see is that when I set the width to
> 100% inside a table cell, the outer edge of the content would be the same
> as the inner edge of the table cell. With 0 for margin, border, and
> padding, that is what I get. However, when I add to any of those, then
> I see the table cell get larger. With your explanation, that should not
> be happening. But it does happen.[/color]

I'm having problems visualising this. Can you explain the context in a:
the red box should line up with the border of the blue box (or whatever)
way.
[color=blue]
> So here's a test I did. I first have the 1px border in place on the box
> and reload in Firefox. The left and right edges of the table cell border
> for the 1st "Lorem" button are at pixel 31 and pixel 84. The top is at
> 415 and the bottom is at 453. The 2nd "Ipsum" button has them at 99 and
> 150 for left and right, and 415 and 453 for top and bottom. Then I change
> the border to 0px and reload. Now the left and right positions for the
> table cell on the 1st button are at 31 and 82, and for the 2nd button are
> at 97 and 146. The top and bottom for both are now at 415 and 451. This
> EXACTLY accounts for the 1px change. Because there are 2 borders, left
> and right, in the first button, the right side of the cell moves left by
> 2px positions. That is what I expect with _my_ interpretation of width,
> and that is what I get. The 2nd button's left cell edge moves left by 2px
> and its right cell edge moves left by 4px. All as expected.
>
> All of the above is exactly the same whether width:100% and height:100%
> is specified or not.[/color]

Agreed!

[...]
[color=blue]
> |> Suppose some browser (or maybe even Firefox) were do to what *I* expect
> |> of it with that code I used. What argument would you use to explain why
> |> the result is not compliant with the standard for CSS? And would you
> |> use this argument only for the horizontal aspect, or would you also use
> |> it for the vertical aspect (that does what I expected, and not what you
> |> described, even now).
> |
> | Get over the horizontal and vertical dimensions. They work slightly
> | different in practice. You have to assume that because the blue (link)
> | boxes got pushed outside the red boxes is because you've done something
> | wrong.
>
> I don't make assumptions like that.
>
> I think it may be a bug in Mozilla's rendering code. But it may even be
> in GTK or elsewhere. But I've talked about this with some other people
> who deal with Firefox bugs, and they've all agreed it is a bug.
>
> No, I still cannot rule out that I am doing something wrong. But the
> analysis at this point strongly suggests that it is highly likely a bug.[/color]

The fact that it looks the same both in FF and Opera suggests this isn't
a bug. You're using linux? Try it out in konqueror which uses the KHTML
rendering engine and see if this comes out the same.
[color=blue]
> |> | Yes but only about 10% of them. Maybe even less.
> |>
> |> 10% of what? I can recommend FF to 100% of users. Maybe 10% of them
> |> might actually try it. But I won't lose sleep over what someone else
> |> decides to do on their computer. If they complain that the page does
> |> not display properly, I'll explain that they have 2 choices: use FF,
> |> or ask MSFT for a fully CSS2 complaint browser. I won't really care
> |> which they choose.
> |
> | That's a stupid way to make a web site. You can't make it browser
> | specific and then expect people to download/install a new browser just
> | to look at your web page. The fact that IE renders things wrong doesn't
> | mean you have to ignore IE users you just have to figure out a work
> | around so that it works in IE.
>
> If Microsoft had not adopted CSS at all, would you still be saying this?
>
> I will try, within reason, to make it display reasonably on IE. And if
> that fails, I will try, within reason, to make it "degrade gracefully"
> (to borrow a common phrase from the "web standards" community). To the
> extent that IE fails to then display things properly, I will make my
> recommendation to use Firefox. I may host a "Get Firefox" button on my
> sites (or at least some of them). I won't host a "Get Explorer" button.
>
> Don't forget, we're talking about a company that intentionally does NOT
> want interoperabilit y to work. But it's not our responsibility to make
> up for everything they do.[/color]

Whether it's interoperable or not you still have to be aware that 90% of
web users use IE. If it doesn't work in IE then only 1 in 10 of your
potential audience can't see it properly. Now, the chances are that if
the content is sufficiently techie you can get away with it because
techie people tend not to use IE. But I still don't think this is any
way to make a webpage. You should perhaps read the on going "Philosophy
of website design" <jDs7g.2089$fV1 .559@edtnps82> thread over at alt.html


--
Brian O'Connor (ironcorona)