From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011214 BuildID: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011214 With an HTML 4.01 Transitional doctype tag (http://www.optio.be/test/html401.html ), a <table style='height:100%'> renders with a 100% screen height. With an XHTML 1.0 Transitional doctype tag, the same table does not have its height applied. Reproducible: Always Steps to Reproduce: 1. Click on the test URL. Actual Results: Page renders, about 50% of the content window height at 1024x768. Expected Results: Page renders at 100% of the content window height. Page validates as XHTML 1.0 Transitional.
Originally reported by firstname.lastname@example.org at http://freewarejava.com/ubb/Forum4/HTML/008024.html . I can't take credit for this. I've asked him to sign up for a Bugzilla account so we can cc him.
Should quirks mode apply when someone specifies an XHTML doctype? With HTML it's needed to account for old pages, but with XHTML surely mozilla shouldn't be encouraging the use of non-standard attributes. Just my 2p
What's non-standard about this? style is defined in %coreattrs; in XHTML 1.0 Strict and XHTML 1.0 Transitional.
fyi: setting the table's CSS height property to an explicit pixels value (such as 600px) works correctly.
Bug 67903 may be related, based on a comment I saw in another bug (I can't locate right now) about iframe and table using the same height mechanism.
This is simply a quirks vs standards issue. The height of <body> is _not_ the height of the viewport. In standards mode you have <body> which is an auto height block, so height is height of content. The content is a height:100% block. So the height of the content is the height of the parent. If you trace the CSS algorithm for heights given this data you get a height of 0 for both. So the table is as short as it can be given its contents. Setting a height on the body (or better yet making the body the size of the viewport using absolute positioning and 0 offsets) will lead to better behavior. In quirks mode we deliberately break layout of this case because so many old pages depend on the non-CSS rendering. This is invalid.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
*** Bug 123505 has been marked as a duplicate of this bug. ***
With respect to Boris Zbarsky's Comment: Now the following works: <html style="height: 100%;"> <body style="margin: 0px; height: 100%;"> <table height="100%"> ... But to quote from the Spec: http://www.w3.org/TR/REC-CSS2/visuren.html#initial-containing-block > The root of the document tree generates a box that serves as the initial > containing block for subsequent layout. > > The width of the initial containing block may be specified with the 'width' > property for the root element. If this property has the value 'auto', the user > agent supplies the initial width (e.g., the user agent uses the current width > of the viewport). > > The height of the initial containing block may be specified with the 'height' > property for the root element. If this property has the value 'auto', the > containing block height will grow to accommodate the document's content. Ergo the following should work too, but doesn't: <html style="height: auto;"> <body style="margin: 0px; height: 100%;"> <table height="100%"> Doesn't the above quote even suggest ommitting the body style when using "height: auto;" with the <html> element? What is the reason for not defining the height property of the html element as auto by default? This is obviously done for the width property.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
the question is where do you get the 100% from. Not whether if it grows to accomodate to the height. read http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-height again: <percentage> Specifies a percentage height. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like 'auto'. Note the last sentence. A way to get the height of the containing block is to do height: inherit; on both the <table> and <body>.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → INVALID
>> The height of the initial containing block may be specified with the 'height' >> property for the root element. If this property has the value 'auto', the >> containing block height will grow to accommodate the document's content. > Doesn't the above quote even suggest ommitting the body style when using > "height: auto;" with the <html> element? It does kind of suggest that but not for the reason you expect. All heights default to auto. If you specify the height of the root, then the 100 percentage heights which you are specifying for the children elements really have no or little noticable effect. The point that Boris was making suggests that if the height is set to auto, then the height will grow (or shrink) to fit the document's content. See http://www.w3.org/TR/REC-CSS2/visudet.html#q17 for a detailed description of this. The sections before and after 10.6.3 specify how to calculate height for other types of content blocks. > What is the reason for not defining the height property of the html element > as auto by default? This is obviously done for the width property. Actually, it *is* defined that way. See the CSS2 specification for height. http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-height That of course is the whole reason why explicitly setting the root element's height to auto in this case has no effect on the document. A good way to think about this is that setting height: auto in this case should display the same as if you had not specified a height at all. The same of course goes for all non-replaced block elements in the normal flow. Please don't confuse auto with 100%. But note that 100% of auto is basically auto itself.
Status: RESOLVED → VERIFIED
*** Bug 119409 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.