User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 When creating a popup window that has a form on it and a table with a height set to 100%, the actual height ends up being about 105%, forcing a scrollbar unless I disable scrolls bars. SAMPLE SITE: http://katanalegion.com/firefox/ I have tested this in FireFox 1.0.6, 1.0.7, 2005-09-26 nightly build, latest Mozilla Suite build. Reproducible: Always Steps to Reproduce: 1. Create a popup window. 2. Add a form to the popup window with a table set to height 100% inside the form. 3. Render the page Actual Results: Page loops just off the screen. If I set the height to 95%, it renders as I would expect it to. Expected Results: Rendered at 100% of the height not 105ish%
The table looks 100%ish to me, but the form extends below it and induces a scrollbar. I'm guessing that's what you don't like. Mozilla has a quirk (your test document is in quirks mode because you omitted a DOCTYPE) that adds a 1em margin on the bottom of a form. I suspect this will end up INVALID. ==> layout/forms
I just added the following to the document: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> And yes, its the addition of the scrollbar that I am talking about. Its as though the form adds a very small buffer vertically. Its nothing serious, just a trivial annoyance I noticed at work.
That DOCTYPE still triggers quirks mode. See: http://www.mozilla.org/docs/web-developer/quirks/doctypes.html Also, you won't like the strict mode rendering either. The body shrink-wraps content, so the height=100% has absolutely no effect at all.
I talked with a standards guru today and he informs me that it is not a Mozilla problem at all. The problem is with the HTML standards themselves which apparently added a small return to the end of a form. Since the form ends after my table, the problem will naturally occur for me. With this in mind, I'll mark this as invalid as its a problem for the W3C to handle. Oh and thanks for the link, I'll be sure to use that in the future.