Re: simpler example of the padding bug

On Tue, 09 May 2006 12:32:48 +0800 ironcorona <iron.corona@xxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx wrote:
|> On Tue, 09 May 2006 04:12:58 +0800 ironcorona <iron.corona@xxxxxxxxx> wrote:
|> | phil-news-nospam@xxxxxxxx wrote:
|> |> On Tue, 09 May 2006 02:28:26 +0800 ironcorona <iron.corona@xxxxxxxxx> wrote:
|> |> | ironcorona wrote:
|> |> |> phil-news-nospam@xxxxxxxx wrote:
|> |> |>> Here is a simpler (no drop shadows) example of the padding bug I see:
|> |> |>>
|> |> |>> http://phil.ipal.org/usenet/ciwas/2006-05-08/buttons-1.html
|> |> |>>
|> |> |>> So far I find nothing in the CSS2 document that says I should get this
|> |> |>> kind of inconsistent result.
|> |> |>
|> |> |> 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/ |
-----------------------------------------------------------------------------
.

Loading