Almost-certain CSS margin-bottom Bug {2}, & Conclusion

To continue:

Almost Certain CSS margin-bottom Bug {2}
========================================
 [Further proof of "Almost-certain CSS margin-bottom Bug {1}",
  previously reported.]

* To reiterate, Amaya does not honor "body {margin-bottom:0}" (or "body
{margin-bottom:0px}", the bottom-relevant aspect of "body {margin:0}",
etc.).  Amaya creates a page-bottom margin *no matter what*.


Test:
-----

http://www.well.com/~mech/.AmayaTest/NewTEST2.html
(also attached here, with .css file, so you don't have to manually download
that to look at it.)

This test differs from the last one in that it:
a) uses "0px" for the margin width values instead of just "0" (which is
legal, but I want to rule out lack of unit as the problem);
b) uses the combined "margin:" syntax to rule out any specific problem
with the "margin-[foo]:" individual edge syntax; and
c) uses compact "BODY {margin-left:0px; margin-top:0px;...}" notation,
to rule out the possibility of it being a problem parsing my particular
CSS spacing and indentation style.  Didn't seem likely, but what the
heck.


Description of the issue:
-------------------------

As with the last test, there should be NO bottom margin at all, yet
there is a very large one. Again, Amaya IS properly handling the left,
right and top margins, just not the bottom one.

NewTEST3.html, attached, shows very clearly that Amaya is ignoring any
"margin-bottom" that applies to the entire document, whatever syntax is
used to arrive at it.

CONCLUSION:
===========

Amaya just seems to have a broad habit of coughing up invented, and
only imaginarily required, white space where it does not actually
belong, and does so in this case in direct violation of the parameters
being set by the CSS, so it is thus a failure of conformance to CSS 2
Level 1, specifically the failure to implement support for
"margin-bottom" on the body, rather than just on individual block and
inline elements (assuming it has implemented even those margins
completely; I haven't checked very thoroughly.)

Some may "see no error in the Amaya interpretation" of these test pages
but the error really is quite plain.

The ONLY circumstance in which Amaya should be creating "fake"
whitespace below the content when "margin-bottom:0" is applied is if
the total content on the page does not fill the browser window
horizontally on load, such that no vertical scrolling is required
(since it has to put SOMETHING there); otherwise it is a clear
violation of CSS 2L1 conformation.

I would have to say the proximal cause of this particular bug is that
when content IS taller the height of the window on load, and one
scrolls down, Amaya doesn't STOP scrolling at the bottom of the
content, but continues a ways farther, and thus *fools itself* into
thinking that it is in the same situation it would be in if it had
loaded a very short page that fit entirely into the window on loading,
and which needed to be "padded" at the bottom with some whitespace that
wasn't actually part of the document canvas.  If Amaya would just stop
scrolling at the appropriate point, the way all other browsers do (or
at least the 30+, not counting different versions, that I've tried on
half a dozen computing platforms), this problem condition simply would
not ever arise.

Cf. previously reported issues dealing with Amaya inventing sometimes
huge amounts of white space horizontally, inappropriately expanding the
document canvas in the process (and even violating the right edge of
the document canvas by placing rendered content outside of it), when it
encounters perfectly valid <IMG ALIGN="right"...> constructions, or
when expected like every other browser (and yet somehow failing) to
proportionally render a table with % cell widths that exceed 100% total
(see previous well-documented bug report on that issue, which I think I
sent yesterday).  And see also the table border overlapping problem I
also reported recently. All of these problems sound to me like maybe
they are probably related in some way, though that's for the Amaya
coders to determine.  (And yes, I DID notice that the right-aligned
image "document width explosion" bug was fixed in a recent CVS build.
Yay!  I'm just pondering here whether there might be a connection
between all of these somewhat similar spacing behaviors).

Anyway, I hope this helps track the issue down and eradicate it.

Best wishes,
 - S.McC.

PS: At least it's not as bad as the superficially similar MSIE/Mac bug
in which a bogus bottom border appears when content is inside a table
inside another table (and some other conditions are met), and in which
the "phantom" bottom whitespace grows and grows, multiplicatively, such
that for very long pages (e.g., say, 20 screenfuls) with several levels
of nested tables, the improper whitespace at the bottom can be MANY,
MANY screenfuls longer than the rest of the document...  Talk about a
bug!  Yeesh.