36  2913  ph**************@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.
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 wrote: ph**************@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.
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.
--
Brian O'Connor (ironcorona)
On Tue, 09 May 2006 02:28:26 +0800 ironcorona <ir*********@gmail.com> wrote:
| ironcorona wrote:
|> ph**************@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/ |
-----------------------------------------------------------------------------
On Tue, 09 May 2006 02:27:03 +0800 ironcorona <ir*********@gmail.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/ |
----------------------------------------------------------------------------- ph**************@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.
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:
<!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:hover {
border: 1px solid #ccaa88;
background-color: #fff7ef;
color: #221100;
}
..menu_button:active {
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_row">
<div class="hmenu_cell"><div class="menu_button"><a
href="#lorem">Lorem</a></div></div>
<div class="hmenu_cell"><div class="menu_button"><a
href="#ipsum">Ipsum</a></div></div>
<div class="hmenu_cell"><div class="menu_button"><a
href="#dolor">Dolor</a></div></div>
<div class="hmenu_cell"><div class="menu_button shift"><a
href="#sit">Sit</a></div></div>
<div class="hmenu_cell"><div class="menu_button"><a
href="#amet">Amet</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_row">
<div class="hmenu_cell"><div class="menu_button pad_top pad_bottom"><a
href="#lorem">Lorem</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_bottom"><a
href="#ipsum">Ipsum</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_bottom"><a
href="#dolor">Dolor</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_bottom
shift"><a href="#sit">Sit</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_bottom"><a
href="#amet">Amet</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_row">
<div class="hmenu_cell"><div class="menu_button pad_left"><a
href="#lorem">Lorem</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_left"><a
href="#ipsum">Ipsum</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_left"><a
href="#dolor">Dolor</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_left shift"><a
href="#sit">Sit</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_left"><a
href="#amet">Amet</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_row">
<div class="hmenu_cell"><div class="menu_button pad_right"><a
href="#lorem">Lorem</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right"><a
href="#ipsum">Ipsum</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right"><a
href="#dolor">Dolor</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right shift"><a
href="#sit">Sit</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right"><a
href="#amet">Amet</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_row">
<div class="hmenu_cell"><div class="menu_button pad_right pad_left"><a
href="#lorem">Lorem</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right pad_left"><a
href="#ipsum">Ipsum</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right pad_left"><a
href="#dolor">Dolor</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right pad_left
shift"><a href="#sit">Sit</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_right pad_left"><a
href="#amet">Amet</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_row">
<div class="hmenu_cell"><div class="menu_button pad_top pad_right
pad_bottom pad_left"><a href="#lorem">Lorem</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_right
pad_bottom pad_left"><a href="#ipsum">Ipsum</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_right
pad_bottom pad_left"><a href="#dolor">Dolor</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_right
pad_bottom pad_left shift"><a href="#sit">Sit</a></div></div>
<div class="hmenu_cell"><div class="menu_button pad_top pad_right
pad_bottom pad_left"><a href="#amet">Amet</a></div></div>
</div></div>
</p>
</body>
</html>
--
Brian O'Connor (ironcorona) ph**************@ipal.net wrote: On Tue, 09 May 2006 02:28:26 +0800 ironcorona <ir*********@gmail.com> wrote:
| ironcorona wrote:
|> ph**************@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.
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.
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.
Yes but only about 10% of them. Maybe even less.
--
Brian O'Connor (ironcorona)
On Tue, 09 May 2006 04:12:58 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <ir*********@gmail.com> wrote:
|> | ironcorona wrote:
|> |> ph**************@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/ |
-----------------------------------------------------------------------------
On Tue, 09 May 2006 04:03:04 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@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/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: On Tue, 09 May 2006 04:03:04 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@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
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?
|> 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 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.
--
Brian O'Connor (ironcorona) ph**************@ipal.net wrote: On Tue, 09 May 2006 04:12:58 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <ir*********@gmail.com> wrote:
|> | ironcorona wrote:
|> |> ph**************@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%.
No, the browser does NOT have to push the content outside. It could,
instead, make the containing element larger.
It does on my fix.
[...]
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.
[...]
| 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.
--
Brian O'Connor (ironcorona)
On Tue, 09 May 2006 12:32:48 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Tue, 09 May 2006 04:12:58 +0800 ironcorona <ir*********@gmail.com> wrote:
|> | ph**************@ipal.net wrote:
|> |> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <ir*********@gmail.com> wrote:
|> |> | ironcorona wrote:
|> |> |> ph**************@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 interoperability 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/ |
-----------------------------------------------------------------------------
On Tue, 09 May 2006 12:23:48 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Tue, 09 May 2006 04:03:04 +0800 ironcorona <ir*********@gmail.com> wrote:
|> | ph**************@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/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: 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.
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.
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)
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)?
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.
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.
As I've mentioned before I didn't see the 2Npx effect in any of my browsers.
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.
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) ph**************@ipal.net wrote: 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.
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.
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.
Agreed!
[...]
|> 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.
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.
|> | 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 interoperability to work. But it's not our responsibility to make
up for everything they do.
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)
On Wed, 10 May 2006 01:46:28 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|
|> 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.
|
| 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.
The red box is the border of the table cell. The table cell is specified
with a padding of 2 pixels, so the inner edge of the red box should be 2
pixels outward from the contents of the table cell.
The button box is inside the table cell and is specified with a margin of
0 pixels (which may not matter, anyway). So both the margin and border of
the button box should have an outer edge the same as the table cell contents.
That means there should be 2 pixels between the red box and the light blue
button box. These 2 pixels should be white because the background color of
the table cell is white.
If your browser supports it, hovering over the button box changes its color
to orange, and activating the button box changes its color to green. This
is done in CSS with :hover and :active on the selectors.
The button box contents is text. I've also tested this with an image and
the effect is the same. This text (but NOT the button box itself) is in
the A element to make a hyperlink of it (goes to same page).
While the button box contents remains unchanged, if I add 1 pixel of padding
to the TOP of the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border is also enlarged by the same amount.
While the button box contents remains unchanged, if I add 1 pixel of padding
to the BOTTOM of the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border is also enlarged by the same amount.
While the button box contents remains unchanged, if I add 1 pixel of padding
to the LEFT of the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border, however, is enlarged by TWO pixels.
Because the button box border grows more than the table cell grows, there is
now some excess, and that excess flows to the RIGHT, most likely because the
starting position (top left) of the button box is calculated correctly. This
is with width:100% specified on the button box.
While the button box contents remains unchanged, if I add 1 pixel of padding
to the RIGHTof the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border, however, is enlarged by TWO pixels.
Because the button box border grows more than the table cell grows, there is
now some excess, and that excess flows to the RIGHT, most likely because the
starting position (top left) of the button box is calculated correctly. This
is with width:100% specified on the button box.
When the width setting of the button box is decreased, it does NOT alter the
layout of the table cell. However, it does alter the width of the button
box border (and presumably the contents). At 50%, that width is half of
the amount as at 100%. These percentages appear to be proportions of the
button box content width plus TWICE the button box padding width.
|> 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.
|
| Agreed!
|
| [...]
|
|> |> 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.
|
| 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.
I had not tried running a KDE environment in my latest Slackware install
(not on 10.2) until now, and it doesn't come up at all. I'll have to find
out why that is. I can't find konqueror to try to run it in my non-KDE
environment. Maybe it didn't get all of KDE installed. So I cannot test
that at this time.
|> |> | 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 interoperability to work. But it's not our responsibility to make
|> up for everything they do.
|
| 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
At one extreme, many designs will fall apart completely in IE. At the
other extreme, I have to pay Microsoft for Windows so that I can relieve
them of the pressure to conform to standards. What is needed is to find
a happy middle. Things need to basically work ("degraded gracefully") in
the browsers people might choose (or default to) use, even if the intended
design only works in browsers more fully compliant. Just where to put
that "happy point" depends on the audience. For a geek/tech site, yes,
the audience can readily use Firefox or a few others and get a good page.
For a site where anyone online is a potential audience member, that point
has to move closer to the IE side. But I can assure you that is NOT a
justification for going all the way. Microsoft needs to at least meet us
half way, though I would prefer they go all the way and comply with the
web standards.
Ironically, your arguments have at least some effect of suggesting that I
continue to use my old HTML hacks and avoid CSS, as I have done for many
years up until now. http://linuxhomepage.com/ still has these old hacks
on it, and it works in IE. I'm switching it to CSS soon. The sooner I
get some of these issues worked out (this button issue is not holding up
linuxhomepage.com specifically, but it is taking up much time), the
sooner the sites get updated.
For linuxhomepage.com I'm trying to work out a design that can function
correctly with a variety of styles users may supply, or select from my
provided styles. But it is NOT as simple as merely marking the contents
by meaning/semantics, since many styles require _multiple_ DIV (or other)
containers to get the intended stylistic effects, such as the shadows.
I'll probably end up putting in several DIV elements for each section.
I'm exploring a number of possible styles to see just how many elements
I might need.
FWIW, I have managed to get _all_ of my family, and several non-techie
friends, to switch to Firefox. All that have switched like it and will
be staying with it. Of the friends that did not switch, half of them
already were using Firefox.
If you want to see Microsoft Internet Explorer continue to be used (such
as because you hold stock in MSFT) then you should urge Microsoft to make
their software work with standards better, including W3C web standards and
OpenDocument standards (at least for import and export). Trying to urge
people to design for IE is not the right way. Urging them to find some
reasonable middle ground appropriate for their particular audience is fine.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Wed, 10 May 2006 01:32:39 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|
| > 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.
|
|> 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.
|
| 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)
You are telling me that Opera is 100% bug free?
What you have not told me is HOW the CSS2 spec dictates that when some amount
of padding is added to a box, that while that amount is added to the parent
container layout exact in the same amount, the added amount to the box itself
shall be TWICE as much, multiplied by the percentage of the width.
I can't explain why Opera does the same thing in the context of my belief
that this is a browser bug. Maybe if I saw the Opera source code I might be
able to get some idea. Maybe there is borrowed source (FYI, not all source
code out there has GPL requirements).
|> 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)?
|
| 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
So when I switch back to TABLE/TR/TD HTML elements to do page layouts,
will you be following up to defend my position when others say I should
be doing tables in CSS instead because my data is not really tabular?
| 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.
Your fix is not what I am wanting. But maybe you are adding padding to BOTH
the table cell and the button box at the same time.
|> 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.
|
| As I've mentioned before I didn't see the 2Npx effect in any of my browsers.
If you are seeing the light blue button extend out on the right, then you
ARE seeing it. *I* see it in these: http://iron.corona.googlepages.com/original_ff.jpg http://iron.corona.googlepages.com/original_opera.jpg
Compare the RED box (that's the table cell border) size between the first
row (no padding) and 3rd row (left padding only). The RED box grows in
proportion to the padding. NOW look at the light blue box (button). It
has also grown, but by twice as much. Magnify and count pixels if you must.
|> 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.
|
| 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.
Of course I do not see the 2Npx effect in your fix because your fix involves
using diffierent calculations in the code implementation (I've also seen the
logic flow). But I need the width to be specified for other reasons that
are not given in this example, which involve much more complex layouts and
style selections. People don't like that complexity for illustrating a
specific problem.
But when the width is specified, the effect it has on the parent table cell
is the box content width plus 2x the padding width, times the specified width
percentage. For the height, it is the conetnt height plus ONLY 1x the padding
height, times the specified height percentage.
Show me where in CSS2 that the padding contribution to width has to be
multiplied by 2.
| 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.
The only question you asked in this post was "a bug with what?".
My answer to that is: probably in the browser, but maybe in the graphical
toolkit or in the way its API is used, and remotely possibly in X itself.
I can't give you a more accurate answer until I find the actual cause.
If that actual cause is improper CSS coding, I've not yet seen it. The
fact that an alternative coding can give some semblance of the intended
design is not an explanation of why this coding is at fault. If I were
to see something in the CSS2 standards spec that said this is what I
should get when coded this way, then I would have to agree that some
other way is needed to get the intended effect. And I might also say
the standard is poorly thought out (e.g. buggy). But at this point I
see nothing particularly bad about the standard aside from a number of
features they have omitted that I think should be there (and might be
in CSS3).
I've avoided using CSS for a number of years, not because anything was
wrong with CSS, its concepts, or the standards, but rather, because the
choices of browsers that implement it properly, and meet other reasonable
needs, was a null set. So for that time I chose browsers that met some
reasonable needs, and avoided CSS because their CSS implementation was
somewhere between none and worthless. Now, at least one browser meets
a reasonable set of needs and has a reasonable implementation of CSS.
This bug I see here isn't serious enough to impact this. The reasonable
needs included:
1. Fast rendering relative to current CPU speeds.
2. Small size relative to current memory capability.
3. Implementations on the major desktop platforms.
It isn't necessary that all of this be in the _same_ browser. It just
happens to be the case with Firefox. Had Firefox NOT been implemented
for Windows _AND_ had IE been fully CSS2 compliant, that would have been
fine for the requirements for me to jump into using CSS. It probably
would have been better as I would not have to encourage people to switch
browsers. But the current situation is enough for me to move on in to
using CSS for web site designs.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: On Wed, 10 May 2006 01:46:28 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|
|> 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.
|
| 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.
The red box is the border of the table cell. The table cell is specified
with a padding of 2 pixels, so the inner edge of the red box should be 2
pixels outward from the contents of the table cell.
The button box is inside the table cell and is specified with a margin of
0 pixels (which may not matter, anyway). So both the margin and border of
the button box should have an outer edge the same as the table cell contents.
That means there should be 2 pixels between the red box and the light blue
button box. These 2 pixels should be white because the background color of
the table cell is white.
If your browser supports it, hovering over the button box changes its color
to orange, and activating the button box changes its color to green. This
is done in CSS with :hover and :active on the selectors.
The button box contents is text. I've also tested this with an image and
the effect is the same. This text (but NOT the button box itself) is in
the A element to make a hyperlink of it (goes to same page).
While the button box contents remains unchanged, if I add 1 pixel of padding
to the TOP of the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border is also enlarged by the same amount.
While the button box contents remains unchanged, if I add 1 pixel of padding
to the BOTTOM of the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border is also enlarged by the same amount.
While the button box contents remains unchanged, if I add 1 pixel of padding
to the LEFT of the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border, however, is enlarged by TWO pixels.
Because the button box border grows more than the table cell grows, there is
now some excess, and that excess flows to the RIGHT, most likely because the
starting position (top left) of the button box is calculated correctly. This
is with width:100% specified on the button box.
While the button box contents remains unchanged, if I add 1 pixel of padding
to the RIGHTof the button box, the contents of the table cell is enlarged by
1 pixel in layout. The button box border, however, is enlarged by TWO pixels.
Because the button box border grows more than the table cell grows, there is
now some excess, and that excess flows to the RIGHT, most likely because the
starting position (top left) of the button box is calculated correctly. This
is with width:100% specified on the button box.
When the width setting of the button box is decreased, it does NOT alter the
layout of the table cell. However, it does alter the width of the button
box border (and presumably the contents). At 50%, that width is half of
the amount as at 100%. These percentages appear to be proportions of the
button box content width plus TWICE the button box padding width.
I want to redress this point but unfortunately I have other things to do
today. I hope to get stuck into this over the weekend.
[...]
Ironically, your arguments have at least some effect of suggesting that I
continue to use my old HTML hacks and avoid CSS, as I have done for many
years up until now. http://linuxhomepage.com/ still has these old hacks
on it, and it works in IE. I'm switching it to CSS soon. The sooner I
get some of these issues worked out (this button issue is not holding up
linuxhomepage.com specifically, but it is taking up much time), the
sooner the sites get updated.
Personally I think; if it works it works. I'm not trying to convert
anyone over to anything here and I tend to stay out of the debate. I
prefer not to use tables for layout simply because I find them confusing
after a certain level of complexity. My brother, on the other hand, who
is a professional programmer (but not web designer) uses tables to
layout all his pages. It doesn't really bother me. I think the point
is you have to make the page viewable to the most people under many,
varying conditions.
For instance, it's a good idea to see if things look good in a
text-browser (lynx on linux). Probably no one will be viewing it on one
but screen readers use similar technology to parse the pages. The point
there is; do you think people with certain disabilities should be
facilitated? I'm not pushing a point here, they're just questions I
think you have to ask yourself as a web designer.
I personally like to use CSS because I think the pages look more elegant
and clean. That's just me.
[snip]
FWIW, I have managed to get _all_ of my family, and several non-techie
friends, to switch to Firefox. All that have switched like it and will
be staying with it. Of the friends that did not switch, half of them
already were using Firefox.
As regards my family, me too. As regards my friends. Not so much.
They're too used to clicking the big blue E on the desktop. AND the
fact that many of them are still mainly using the Internet in University
or their office where they can't download and install anything. Many
people simply can't convert over. In fact, my dad uses FF for all his
browsing at home but still has to switch over to IE for his
online-banking because the bank will only support IE. I've actually
heard this from many people. Banks, in particular, tend to have old,
stable systems, and can't really afford to change over.
If you want to see Microsoft Internet Explorer continue to be used (such
as because you hold stock in MSFT) then you should urge Microsoft to make
their software work with standards better, including W3C web standards and
OpenDocument standards (at least for import and export). Trying to urge
people to design for IE is not the right way. Urging them to find some
reasonable middle ground appropriate for their particular audience is fine.
Don't get me wrong. I think that IE is an awful product that should
never have been released. I'm even having a look at the beta version of
the new IE7, which *still* doesn't conform. Reading the MSIE blog;
they've said that when it ships that it still won't be ready to conform.
I wonder why the hell they're bothering to release the product if it's
still broken.
The simple fact is that too many people use IE and since MS have that
market share there is no conceivable reason for them to rewrite all the
broken code, in the near future. It sucks but we have to live with it.
--
Brian O'Connor (ironcorona) ph**************@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.
Okay, I've solved your problem.
First though, a bit of a markup problem:
You have the table <div>s wrapped in <p> tags. <p> can only contain
inline elements http://www.w3.org/TR/html4/struct/text.html#edef-P
This has nothing to do with the padding error.
If you take away the cell's padding then you have specified that the
button's content and the cell's content are *exactly* the same size
(100%). It seems that borders on the left cannot overlap so the cell
pushes the content 1px over to the right. This 1px overlap seems to
continue even after there is padding added to the cell.
Now add the 2px padding to the cell.
Since you have defined the cell and the button to be the same size
(because you have defined the button as being width:100%;) when you add
3px padding-left to the button; the cell must also add 3px of width to
compensate (because they're the same size remember).
Experiment: Add 3px of padding-left to the button. What you see is that
the button moves out 6px. Now look where the button border is
*relative* to the cell border: Before the padding-left was added there
was no gap between the button border and the cell border. When you add
the 3px padding-left the button border-right ends up 2px to the right of
the cell border-right (exactly where you'd expect *relatively*). So 1px
right means the borders would overlap. 2px right means the button
border is 1px to the right of the cell border. And finally 3px right
brings the border to 2px to the right of the cell. So it's in the
correct position relative to the cell but the compensation that the cell
creates because the button and the cell are the *same* size makes the
doubling.
The same restrictions don't seem to hold on the top and bottom borders
which is why you didn't see any padding problem on the vertical axis.
This is why it seems to work when you take out the width:100%;
--
Brian O'Connor (ironcorona)
To further the education of mankind, ironcorona <ir*********@gmail.com>
vouchsafed: I'm even having a look at the beta version
of the new IE7, which *still* doesn't conform. Reading the MSIE blog;
they've said that when it ships that it still won't be ready to
conform.
I wonder why the hell they're bothering to release the product if
it's
still broken.
They have 6 years or so of lethargy/Bill Gate's bad attitude to make up
for. That can't be done in less than a year, so if their concept is to
release a major improvement first and then improve that in the course of
time, I can't fault them. Mozilla (nor Opera) wasn't terrific to begin
with, either, and only got really good in steps.
The simple fact is that too many people use IE and since MS have that
market share there is no conceivable reason for them to rewrite all
the broken code, in the near future. It sucks but we have to live
with it.
No we don't. I was on the verge of making all my pages workable for
standards-compliant browsers only when MS announced the IE7 project. Had
there been no such announcement, I would have done my markup as I saw fit,
encouraged others to do the same, and let inferior renderers deal with the
results as best they could, -perhaps even contributing an explanatory note
to that effect. I was almost looking forward to it... Maybe _some_
people/enterprises have to "live with it," but most don't.
--
Neredbojias
Infinity has its limits.
Neredbojias wrote: No we don't. I was on the verge of making all my pages workable for
standards-compliant browsers only when MS announced the IE7 project. Had
there been no such announcement, I would have done my markup as I saw fit,
encouraged others to do the same, and let inferior renderers deal with the
results as best they could, -perhaps even contributing an explanatory note
to that effect. I was almost looking forward to it... Maybe _some_
people/enterprises have to "live with it," but most don't.
I meant that from the perspective of "if you want the greatest amount of
people *possible* to view your site then you just have to live with it".
I don't mean that anyone is forcing you to do what Bill says.
--
Brian O'Connor (ironcorona)
ironcorona wrote: Neredbojias wrote:
No we don't. I was on the verge of making all my pages workable for
standards-compliant browsers only when MS announced the IE7 project.
Had there been no such announcement, I would have done my markup as I
saw fit, encouraged others to do the same, and let inferior renderers
deal with the results as best they could, -perhaps even contributing
an explanatory note to that effect. I was almost looking forward to
it... Maybe _some_ people/enterprises have to "live with it," but
most don't.
I meant that from the perspective of "if you want the greatest amount of
people *possible* to view your site then you just have to live with it".
I don't mean that anyone is forcing you to do what Bill says.
I mean hell; if you really want to you can programme and distribute your
own browsers that only read your own, brand-new markup language. It
just wouldn't make people want to view your web pages.
--
Brian O'Connor (ironcorona)
On Fri, 12 May 2006 01:29:17 +0800 ironcorona <ir*********@gmail.com> wrote:
| Personally I think; if it works it works. I'm not trying to convert
| anyone over to anything here and I tend to stay out of the debate. I
| prefer not to use tables for layout simply because I find them confusing
| after a certain level of complexity. My brother, on the other hand, who
| is a professional programmer (but not web designer) uses tables to
| layout all his pages. It doesn't really bother me. I think the point
| is you have to make the page viewable to the most people under many,
| varying conditions.
I'm a programmer (academically since 1972, professionally since 1979).
Maybe there's something about the way some programmers think that make
tables "obvious" to us. You can see in some of my older pages that I
have made heavy use of tables, including programs generating them in C,
PHP, and Pike.
| For instance, it's a good idea to see if things look good in a
| text-browser (lynx on linux). Probably no one will be viewing it on one
| but screen readers use similar technology to parse the pages. The point
| there is; do you think people with certain disabilities should be
| facilitated? I'm not pushing a point here, they're just questions I
| think you have to ask yourself as a web designer.
|
| I personally like to use CSS because I think the pages look more elegant
| and clean. That's just me.
It depends on what you (as viewer) want out of the page, and what you (as
author) want to put in the page. If I'm making a page to document some
program I wrote, I do things quite different than if I'm making a page to
sell the services of some business client.
|
| [snip]
|
|> FWIW, I have managed to get _all_ of my family, and several non-techie
|> friends, to switch to Firefox. All that have switched like it and will
|> be staying with it. Of the friends that did not switch, half of them
|> already were using Firefox.
|
| As regards my family, me too. As regards my friends. Not so much.
| They're too used to clicking the big blue E on the desktop. AND the
Move the big blue E to a subfolder. Name it "cesspool".
| fact that many of them are still mainly using the Internet in University
| or their office where they can't download and install anything. Many
They should be calling tech support every day they see a page that will not
show up correctly even though correctly designed and validates strict.
| people simply can't convert over. In fact, my dad uses FF for all his
| browsing at home but still has to switch over to IE for his
| online-banking because the bank will only support IE. I've actually
He needs to be calling the bank and speaking to someone with responsibility.
The thing to do is ask when talking to someone if they have responsibility.
If not, tell that person that they are calling to speak to someone with
responsibility.
| heard this from many people. Banks, in particular, tend to have old,
| stable systems, and can't really afford to change over.
Quite a number of banks have been broken into. I don't call that stable.
|> If you want to see Microsoft Internet Explorer continue to be used (such
|> as because you hold stock in MSFT) then you should urge Microsoft to make
|> their software work with standards better, including W3C web standards and
|> OpenDocument standards (at least for import and export). Trying to urge
|> people to design for IE is not the right way. Urging them to find some
|> reasonable middle ground appropriate for their particular audience is fine.
|
| Don't get me wrong. I think that IE is an awful product that should
| never have been released. I'm even having a look at the beta version of
| the new IE7, which *still* doesn't conform. Reading the MSIE blog;
| they've said that when it ships that it still won't be ready to conform.
| I wonder why the hell they're bothering to release the product if it's
| still broken.
They think it does conform ... to the defacto standards they are pushing.
| The simple fact is that too many people use IE and since MS have that
| market share there is no conceivable reason for them to rewrite all the
| broken code, in the near future. It sucks but we have to live with it.
Every reason you see that someone still has to use IE is a reason you and
I both need to be trying harder to get them to change. If someone has to
use IE _only_ for the bank, they might eventually realize their bank is
the issue.
Ironically, I'm considering a move from my current bank because its branch
location is inconvenient for me. I opened an account there when it was
convenient. While I don't do any banking online, and specifically have my
account marked as disabled for internet access, your stories have convinced
me I need to ask some new questions when looking for a new bank (there are
about 6 I've identified so far with reasonably convenient locations that
could be my choice, including 2 of them with local main headquarters). So
one of the questions I will ask is "Which web browsers are supported by
your online banking web site, and your other web services?". Or maybe "Is
your online banking web site compliant with current web standards?".
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Fri, 12 May 2006 03:08:37 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@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.
|
| Okay, I've solved your problem.
|
| First though, a bit of a markup problem:
|
| You have the table <div>s wrapped in <p> tags. <p> can only contain
| inline elements
|
| http://www.w3.org/TR/html4/struct/text.html#edef-P
|
| This has nothing to do with the padding error.
|
|
| If you take away the cell's padding then you have specified that the
| button's content and the cell's content are *exactly* the same size
| (100%). It seems that borders on the left cannot overlap so the cell
| pushes the content 1px over to the right. This 1px overlap seems to
| continue even after there is padding added to the cell.
I assume this is with padding:0 but is this with border:0 or border:1px?
| Now add the 2px padding to the cell.
|
| Since you have defined the cell and the button to be the same size
| (because you have defined the button as being width:100%;) when you add
| 3px padding-left to the button; the cell must also add 3px of width to
| compensate (because they're the same size remember).
Right. So the cell is 3px larger, horizontally. This should, and does,
happen with 3px added to left only, or 3px added to right only, or 1px on
the left with 2px on the right, or 2px on the left with 1px on the right.
| Experiment: Add 3px of padding-left to the button. What you see is that
| the button moves out 6px. Now look where the button border is
| *relative* to the cell border: Before the padding-left was added there
| was no gap between the button border and the cell border. When you add
| the 3px padding-left the button border-right ends up 2px to the right of
| the cell border-right (exactly where you'd expect *relatively*). So 1px
No, I would _expect_ the button border-right to be just left of the cell
border-right, with no gap between, whether button padding-left is 0 or 3px.
| right means the borders would overlap. 2px right means the button
| border is 1px to the right of the cell border. And finally 3px right
| brings the border to 2px to the right of the cell. So it's in the
| correct position relative to the cell but the compensation that the cell
| creates because the button and the cell are the *same* size makes the
| doubling.
The compensation should be the same. The cell content box (the inner
edge of the border when the cell has padding:0) should get wider by 3px.
The button content box will stay the same width. But the inner edge of
the button border should be 3px wider, of which the first 3px of that
is the padding area.
Here's my ASCII ART illustration:
With both cell and button having padding:0 and border:1px we would see
the borders right together with no gap between:
+--<this is the cell border>---------------------+
|+--<this is the button border>-----------------+|
||This is the outermost pixels of button content||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
|+----------------------------------------------+|
+------------------------------------------------+
The content widthe is 46, so the button border is 48 and the cell border
is 50 wide.
Adding button{padding-left:3px} we SHOULD (IMHO) have the following with
dots for the padding area:
+-----<this is the cell border>---------------------+
|+-----<this is the button border>-----------------+|
||...This is the outermost pixels of button content||
||...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X||
||...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X||
|+-------------------------------------------------+|
+---------------------------------------------------+
The content area has moved to the right by 3px and the cell is enlarged
to compensate. Now the button border is 51 wide and the cell border is
53 wide.
But what Firefox 1.5.0.3 gives is MORE than that:
+-----<this is the cell border>---------------------+
|+-----<this is the button border>--------------------+
||...This is the outermost pixels of button content???|
||...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X???|
||...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X???|
|+----------------------------------------------------+
+---------------------------------------------------+
This is all the same as what I would expect EXCEPT that the extra space
exists within the confines of the button border. I just don't know if
it is content or padding. It is colored with the background-color, but
both content and padding would have that, so this is not indicative.
I filled the unknown part with question marks. The button border is 54
wide and the cell broder is 53 wide.
So tell me what YOU think is what that area with the question marks is.
Is it false padding? Is it content growing by 3px to 49?
I _suspect_ that the layout phase (calculating where everything is to be
rendered) is working correctly, but that the rendering phase (making the
appropriate calls to do graphical drawing) is working with dimensions
that are not the same as used in layout. It is _drawing_ the button as
if there was padding-left:3px _and_ padding-right:3px (thought that may
not be the mechanism of how that happens). I also believe it is NOT a
case of accidentally picking up a number from the padding-left variable
when it should pick up a number from the padding-right variable, because
doing all of this with padding-right:3px instead still gives the same
effect of widening the button more than widening the cell. That leaves
the content shifted left as in:
+-----<this is the cell border>---------------------+
|+-----<this is the button border>--------------------+
||This is the outermost pixels of button content...???|
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.. .???|
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.. .???|
|+----------------------------------------------------+
+---------------------------------------------------+
Or maybe:
+-----<this is the cell border>---------------------+
|+-----<this is the button border>--------------------+
||This is the outermost pixels of button content???...|
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?? ?...|
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?? ?...|
|+----------------------------------------------------+
+---------------------------------------------------+
I don't know whether the excess width is something added to the content
or to the padding. But that's probably moot. I just don't want to show
that I'm assuming one or the other of those.
What I think button{padding-right:3px} should do is:
+-----<this is the cell border>---------------------+
|+-----<this is the button border>-----------------+|
||This is the outermost pixels of button content...||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.. .||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.. .||
|+-------------------------------------------------+|
+---------------------------------------------------+
| The same restrictions don't seem to hold on the top and bottom borders
| which is why you didn't see any padding problem on the vertical axis.
I don't see any "restrictions" that should increase the space inside the
button border by more than 3px when adding button{padding-left:3px}.
Whatever explanation you might give as to why I should get what I did get
should explain what that extra area with the question marks is.
| This is why it seems to work when you take out the width:100%;
Seems?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
To further the education of mankind, ironcorona <ir*********@gmail.com>
vouchsafed: ...Maybe _some_ people/enterprises have to "live with it," but
most don't.
I meant that from the perspective of "if you want the greatest amount
of people *possible* to view your site then you just have to live with
it".
I don't mean that anyone is forcing you to do what Bill says.
Sure, no argument here. But if "suddenly" a significant percentage of
websites were unreadable in IE, the ratio would change.
--
Neredbojias
Infinity has its limits.
To further the education of mankind, ironcorona <ir*********@gmail.com>
vouchsafed: I meant that from the perspective of "if you want the greatest amount
of people *possible* to view your site then you just have to live
with it".
I don't mean that anyone is forcing you to do what Bill says.
I mean hell; if you really want to you can programme and distribute
your own browsers that only read your own, brand-new markup language.
It just wouldn't make people want to view your web pages.
That would be taking a valid concept to an invalid extreme.
--
Neredbojias
Infinity has its limits.
Neredbojias wrote: Sure, no argument here. But if "suddenly" a significant percentage of
websites were unreadable in IE, the ratio would change.
I see your point now. Agreed!
--
Brian O'Connor (ironcorona) ph**************@ipal.net wrote: On Fri, 12 May 2006 03:08:37 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@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.
|
| Okay, I've solved your problem.
|
| First though, a bit of a markup problem:
|
| You have the table <div>s wrapped in <p> tags. <p> can only contain
| inline elements
|
| http://www.w3.org/TR/html4/struct/text.html#edef-P
|
| This has nothing to do with the padding error.
|
|
| If you take away the cell's padding then you have specified that the
| button's content and the cell's content are *exactly* the same size
| (100%). It seems that borders on the left cannot overlap so the cell
| pushes the content 1px over to the right. This 1px overlap seems to
| continue even after there is padding added to the cell.
I assume this is with padding:0 but is this with border:0 or border:1px?
This was with border:1px;. The only thing changed at this point is
setting the padding to 0px.
| Now add the 2px padding to the cell.
|
| Since you have defined the cell and the button to be the same size
| (because you have defined the button as being width:100%;) when you add
| 3px padding-left to the button; the cell must also add 3px of width to
| compensate (because they're the same size remember).
Right. So the cell is 3px larger, horizontally. This should, and does,
happen with 3px added to left only, or 3px added to right only, or 1px on
the left with 2px on the right, or 2px on the left with 1px on the right.
| Experiment: Add 3px of padding-left to the button. What you see is that
| the button moves out 6px. Now look where the button border is
| *relative* to the cell border: Before the padding-left was added there
| was no gap between the button border and the cell border. When you add
| the 3px padding-left the button border-right ends up 2px to the right of
| the cell border-right (exactly where you'd expect *relatively*). So 1px
No, I would _expect_ the button border-right to be just left of the cell
border-right, with no gap between, whether button padding-left is 0 or 3px.
But that would imply that the button is inside the cell. But they're
the same size (horizontally). So it can't be inside.
| right means the borders would overlap. 2px right means the button
| border is 1px to the right of the cell border. And finally 3px right
| brings the border to 2px to the right of the cell. So it's in the
| correct position relative to the cell but the compensation that the cell
| creates because the button and the cell are the *same* size makes the
| doubling.
The compensation should be the same. The cell content box (the inner
edge of the border when the cell has padding:0) should get wider by 3px.
The button content box will stay the same width. But the inner edge of
the button border should be 3px wider, of which the first 3px of that
is the padding area.
Here's my ASCII ART illustration:
With both cell and button having padding:0 and border:1px we would see
the borders right together with no gap between:
+--<this is the cell border>---------------------+
|+--<this is the button border>-----------------+|
||This is the outermost pixels of button content||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
|+----------------------------------------------+|
+------------------------------------------------+
The content widthe is 46, so the button border is 48 and the cell border
is 50 wide.
But you've told the browser that they're THE SAME SIZE. (width:100%;).
So in your above example the content area of the cell is 48px in width.
But you've said they're the same size so that makes the content area
of the button 48px.
The border is the problem. Borders on the left don't overlap. If you
take off the border all together (and change the background colour of
the cell, just so you can see it) you'll see there's no problem.
All of your drawn examples are flawed because they assume that the
button is inside the cell.
I _suspect_ that the layout phase (calculating where everything is to be
rendered) is working correctly, but that the rendering phase (making the
appropriate calls to do graphical drawing) is working with dimensions
that are not the same as used in layout. It is _drawing_ the button as
if there was padding-left:3px _and_ padding-right:3px
No it's not.
| The same restrictions don't seem to hold on the top and bottom borders
| which is why you didn't see any padding problem on the vertical axis.
I don't see any "restrictions" that should increase the space inside the
button border by more than 3px when adding button{padding-left:3px}.
Because they're the same size as each other. So you get 3px padding in
the button. You get 3px bigger in the cell (because they're the same
size) and then you get the 3px more on the button to put it in the
correct relative position position.
| This is why it seems to work when you take out the width:100%;
Seems?
Bad wording choice. This is why it WORKS when you take out the width:100%;
--
Brian O'Connor (ironcorona)
Neredbojias wrote: To further the education of mankind, ironcorona <ir*********@gmail.com>
vouchsafed:
I meant that from the perspective of "if you want the greatest amount
of people *possible* to view your site then you just have to live
with it".
I don't mean that anyone is forcing you to do what Bill says.
I mean hell; if you really want to you can programme and distribute
your own browsers that only read your own, brand-new markup language.
It just wouldn't make people want to view your web pages.
That would be taking a valid concept to an invalid extreme.
That's true but what you're saying is IE will go away if we all close
our eyes and hope it does.
--
Brian O'Connor (ironcorona)
On Fri, 12 May 2006 11:14:40 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Fri, 12 May 2006 03:08:37 +0800 ironcorona <ir*********@gmail.com> wrote:
|> | ph**************@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.
|> |
|> | Okay, I've solved your problem.
|> |
|> | First though, a bit of a markup problem:
|> |
|> | You have the table <div>s wrapped in <p> tags. <p> can only contain
|> | inline elements
|> |
|> | http://www.w3.org/TR/html4/struct/text.html#edef-P
|> |
|> | This has nothing to do with the padding error.
|> |
|> |
|> | If you take away the cell's padding then you have specified that the
|> | button's content and the cell's content are *exactly* the same size
|> | (100%). It seems that borders on the left cannot overlap so the cell
|> | pushes the content 1px over to the right. This 1px overlap seems to
|> | continue even after there is padding added to the cell.
|>
|> I assume this is with padding:0 but is this with border:0 or border:1px?
|
| This was with border:1px;. The only thing changed at this point is
| setting the padding to 0px.
|
|>
|> | Now add the 2px padding to the cell.
|> |
|> | Since you have defined the cell and the button to be the same size
|> | (because you have defined the button as being width:100%;) when you add
|> | 3px padding-left to the button; the cell must also add 3px of width to
|> | compensate (because they're the same size remember).
|>
|> Right. So the cell is 3px larger, horizontally. This should, and does,
|> happen with 3px added to left only, or 3px added to right only, or 1px on
|> the left with 2px on the right, or 2px on the left with 1px on the right.
|>
|>
|> | Experiment: Add 3px of padding-left to the button. What you see is that
|> | the button moves out 6px. Now look where the button border is
|> | *relative* to the cell border: Before the padding-left was added there
|> | was no gap between the button border and the cell border. When you add
|> | the 3px padding-left the button border-right ends up 2px to the right of
|> | the cell border-right (exactly where you'd expect *relatively*). So 1px
|>
|> No, I would _expect_ the button border-right to be just left of the cell
|> border-right, with no gap between, whether button padding-left is 0 or 3px.
|
| But that would imply that the button is inside the cell. But they're
| the same size (horizontally). So it can't be inside.
Not they are not the same size. The button is inside the cell.
|> | right means the borders would overlap. 2px right means the button
|> | border is 1px to the right of the cell border. And finally 3px right
|> | brings the border to 2px to the right of the cell. So it's in the
|> | correct position relative to the cell but the compensation that the cell
|> | creates because the button and the cell are the *same* size makes the
|> | doubling.
|>
|> The compensation should be the same. The cell content box (the inner
|> edge of the border when the cell has padding:0) should get wider by 3px.
|> The button content box will stay the same width. But the inner edge of
|> the button border should be 3px wider, of which the first 3px of that
|> is the padding area.
|>
|> Here's my ASCII ART illustration:
|>
|> With both cell and button having padding:0 and border:1px we would see
|> the borders right together with no gap between:
|>
|> +--<this is the cell border>---------------------+
|> |+--<this is the button border>-----------------+|
|> ||This is the outermost pixels of button content||
|> ||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
|> ||XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX||
|> |+----------------------------------------------+|
|> +------------------------------------------------+
|>
|> The content widthe is 46, so the button border is 48 and the cell border
|> is 50 wide.
|
| But you've told the browser that they're THE SAME SIZE. (width:100%;).
They were not the same size. Nor would I expect them to be. Firefox
did as I expected, not as you are explaining.
| So in your above example the content area of the cell is 48px in width.
| But you've said they're the same size so that makes the content area
| of the button 48px.
No. The available space for the button is inside the cell just as it
describes in 10.3.3 of CSS2.
| The border is the problem. Borders on the left don't overlap. If you
| take off the border all together (and change the background colour of
| the cell, just so you can see it) you'll see there's no problem.
|
| All of your drawn examples are flawed because they assume that the
| button is inside the cell.
That's because the button _is_ inside the cell. They exactly and correctly
represent my expectation. AND ... they also represent how Firefox really
did calculate the layout.
|> I _suspect_ that the layout phase (calculating where everything is to be
|> rendered) is working correctly, but that the rendering phase (making the
|> appropriate calls to do graphical drawing) is working with dimensions
|> that are not the same as used in layout. It is _drawing_ the button as
|> if there was padding-left:3px _and_ padding-right:3px
|
| No it's not.
It really is. That is _exactly_ the display I get from Firefox. Every
position location figured by layout is _exactly_ where I expect it to
be. The _only_ difference between what Firefox displays and what I think
it should display is the extend of the button being drawn ... it _exactly_
3px further to the right than I think it should be, which makes it exactly
6px wider than w/o the padding-left:6px.
|> | The same restrictions don't seem to hold on the top and bottom borders
|> | which is why you didn't see any padding problem on the vertical axis.
|>
|> I don't see any "restrictions" that should increase the space inside the
|> button border by more than 3px when adding button{padding-left:3px}.
|
| Because they're the same size as each other. So you get 3px padding in
| the button. You get 3px bigger in the cell (because they're the same
| size) and then you get the 3px more on the button to put it in the
| correct relative position position.
The button is wider by a total of 6 px. The _border_ of the button is not
changed in position. The _content_ of the button moves to the right by
_only_ 3px (as I expect it to for padding-left:3px). The right side of
the button border _should_ (also) move to the right by 3px but instead,
it moves to the right by 6px.
| Bad wording choice. This is why it WORKS when you take out the width:100%;
Without width:100% an entirely different path of calculations is performed
in the code. That's why I'm studying the code for width:100%.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
To further the education of mankind, ironcorona <ir*********@gmail.com>
vouchsafed: I mean hell; if you really want to you can programme and distribute
your own browsers that only read your own, brand-new markup language.
It just wouldn't make people want to view your web pages.
That would be taking a valid concept to an invalid extreme.
That's true but what you're saying is IE will go away if we all close
our eyes and hope it does.
No, I was implying that even mighty MS has to respect trends. IE could not
have lasted forever as an inferior browser/whatchamacallit. The point is
moot, anyway, since there is an IE7 in the offing.
--
Neredbojias
Infinity has its limits. ph**************@ipal.net wrote: That's because the button _is_ inside the cell. They exactly and correctly
represent my expectation. AND ... they also represent how Firefox really
did calculate the layout.
No, it's not. How could it be. You have told the browser that the
button is to be 100% of the cell. To pick an arbitrary figure this
means that if the width of the cell is 50px then the width of the button
MUST be 50px. What is 100% of 50px? 50px, of course.
50px CAN NOT fit inside 50px.
--
Brian O'Connor (ironcorona)
On Fri, 12 May 2006 16:21:12 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|
|> That's because the button _is_ inside the cell. They exactly and correctly
|> represent my expectation. AND ... they also represent how Firefox really
|> did calculate the layout.
|
| No, it's not. How could it be. You have told the browser that the
| button is to be 100% of the cell. To pick an arbitrary figure this
| means that if the width of the cell is 50px then the width of the button
| MUST be 50px. What is 100% of 50px? 50px, of course.
|
| 50px CAN NOT fit inside 50px.
I interpret the standard a different way that you seem to. And Firefox
did do the layout as I expected. It just did one aspect of drawing in a
different way.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Fri, 12 May 2006 02:18:02 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:
| To further the education of mankind, ironcorona <ir*********@gmail.com>
| vouchsafed:
|
|>>> I mean hell; if you really want to you can programme and distribute
|>>> your own browsers that only read your own, brand-new markup language.
|>>> It just wouldn't make people want to view your web pages.
|>>
|>> That would be taking a valid concept to an invalid extreme.
|>
|> That's true but what you're saying is IE will go away if we all close
|> our eyes and hope it does.
|
| No, I was implying that even mighty MS has to respect trends. IE could not
| have lasted forever as an inferior browser/whatchamacallit. The point is
| moot, anyway, since there is an IE7 in the offing.
Which is letting them maintain an "arm's distance" from web standards.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
To further the education of mankind, ph**************@ipal.net
vouchsafed: |> That's true but what you're saying is IE will go away if we all
|> close our eyes and hope it does.
|
| No, I was implying that even mighty MS has to respect trends. IE
| could not have lasted forever as an inferior browser/whatchamacallit.
| The point is moot, anyway, since there is an IE7 in the offing.
Which is letting them maintain an "arm's distance" from web standards.
Maybe, maybe not. While precedence has taught us to be cynical, who
knows?, IEx just might turn into a "model citizen". If Microsoft has any
real brains, it will...
--
Neredbojias
Infinity has its limits.
On Fri, 12 May 2006 20:49:58 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:
| To further the education of mankind, ph**************@ipal.net
| vouchsafed:
|
|>|> That's true but what you're saying is IE will go away if we all
|>|> close our eyes and hope it does.
|>|
|>| No, I was implying that even mighty MS has to respect trends. IE
|>| could not have lasted forever as an inferior browser/whatchamacallit.
|>| The point is moot, anyway, since there is an IE7 in the offing.
|>
|> Which is letting them maintain an "arm's distance" from web standards.
|
| Maybe, maybe not. While precedence has taught us to be cynical, who
| knows?, IEx just might turn into a "model citizen". If Microsoft has any
| real brains, it will...
Reports from beta testers indicate disappointment. Apparently they do
not even fully comply with CSS2, which has been out how many years?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
To further the education of mankind, ph**************@ipal.net
vouchsafed: |> Which is letting them maintain an "arm's distance" from web
|> standards.
|
| Maybe, maybe not. While precedence has taught us to be cynical, who
| knows?, IEx just might turn into a "model citizen". If Microsoft has
| any real brains, it will...
Reports from beta testers indicate disappointment. Apparently they do
not even fully comply with CSS2, which has been out how many years?
Neither does any other browser...
--
Neredbojias
Infinity has its limits. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: delerious |
last post by:
I'm trying to add some simple padding to an IMG by using a padding-right
style, but it doesn't work in IE. Works fine in Mozilla and Opera, though.
Here's a link to a page which displays this IE...
|
by: Alan Little |
last post by:
Is there a way to get NS7 to right-pad? With padding-right, it's completely
ignored. With padding, it pads top, bottom and left, but not right. In fact
if I push the padding up to a large number,...
|
by: Red |
last post by:
This is apparently an ie display bug, I can't seem to figure out which
ie bug this is.
a 3 sided border is created by wrapping the 'inner' box in the 'middle'
box and padding the 'middle' box...
|
by: Knoxy |
last post by:
Hello, I've noticed one or two people post on this before but nobody
seems to have replied so raising the issue again... is this a known
IE6 CSS bug?
I have placed the following in my...
|
by: Gustaf Liljegren |
last post by:
I continued on the example shown earlier today:
http://gusgus.cn/test/index.html
Now I get some unwanted space in Firefox (the red space just below the
first image) which doesn't appear in...
|
by: Wilhelm Kutting |
last post by:
hi,
when i use the padding-left attribut, i like to overwrite a default
value like that
..padding30 {margin-left: 30px;}
..padding0 {margin-left: 0px;}
<div class="padding30">
Padding 30...
|
by: Amarendra |
last post by:
Folks,
This structure padding issue is bothering me now, could
not locate a satisfactory answer on clc, so here it goes...
I have a structure, given below:
typedef struct {
int flag;
char...
|
by: Thomas Bügel |
last post by:
Hi!
Out of the book from Dan Cederholms (Bulletproof Webdesign - german ed.) I
tested chapter 4 (creativ floating). For no CDR is included I wrote the code
from the text in the book (images and...
|
by: john_aspinall |
last post by:
I want to put a simple padding on the right hand side of my text
container to stop the text from overflowing out of the box. Ive added
a padding-right rule and it refusing to recognise it in...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
|
by: GKJR |
last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...
| |
