- From: Peter Moulder <peter.moulder@monash.edu>
- Date: Fri, 02 Sep 2011 16:19:31 +1000
- To: www-style@w3.org
visudet.html#propdef-height: # Computed value: the percentage or 'auto' (see prose under # <percentage>) or the absolute length # # ... # # <percentage>: # ... If the height of the containing block is not specified # explicitly (i.e., it depends on content height), and this element # is not absolutely positioned, the value computes to 'auto'. Given the phrase "computes to" and the reference in the Computed-value field to that paragraph, I would interpret that as saying that the *computed value* is 'auto' if the element is not absolutely positioned and the height of the element's containing block is "not specified explicitly (i.e., it depends on content height)". That is surprising, because it would seem that calculating the computed value of a property requires determining the containing block of the element and whether its height is "specified explicitly" or whether it "depends on content height". This would make it unique to my knowledge among CSS 2.1 properties, and pushes at the boundary between computed value and used value that section 6.1.3 gives. Once we move to css3 territory (run-in etc., where the containing block isn't an ancestor if it runs in, and determining whether it runs in is an involved process), that would become more onerous still. Furthermore, when I try to test the behaviour (based on the behaviour of height:inherit in a child), all UAs I've tested inherit the specified percentage rather than 'auto' in this condition. Thus, I suggest that the computed value for 'height' for percentages be simply the percentage as specified in this condition. I would guess that the intent of the current wording was for purposes of the text that specifies the final used length of the content area, which is currently expressed in terms of an input of the computed value of 'height'. However, this text needs changing anyway for purposes of the rules for 'min-height' and 'max-height', which already require that the 10.6 rules use something other than the computed value of 'height' as input. For example, one might introduce an additional named value, perhaps "the input height". A related issue is that the corresponding text for percentage min-height and max-height uses the phrase "is treated as", which is one of those phrases like "as if" that creates conflicts and misunderstandings because other bits of text just say simply "the [used] value of min-height (or max-height)", which some people might take literally while others honour the "treated as if" text. I suggest changing the value to simply "the used value is ...", and make sure that other text (8.3.1 in box.html, and visudet.html) refers explicitly to either the computed value or the used value as appropriate. pjrm. (Appended is the test case for whether 'auto' or the percentage is inherited. Also available at http://bowman.infotech.monash.edu.au/~pmoulder/html-tests/pcnt-height-computed-val.html .) <!DOCTYPE html> <html> <head> <title>Test of computed value of percentage height/min-height/max-height</title </head> <body> <div style="position:absolute; right:10px; height:25%; background:yellow;">height:25% in root</div> <div style="position:relative; margin-right:50px;"> 0<br /> 1<br /> <div style="position:absolute; right:10px; height:25%; background:#caf;">height:25% in 8-line height:auto relpos</div> 2<br /> 3<br /> <div style="position:absolute; right:100px; height:auto; background:#afa;">height:auto in relpos</div> 4<br /> 5<br /> 6<br /> 7 <div style="height:25%"> height:25% non-abspos in height:auto relpos, so computed height:auto per spec <div style="position:absolute; left:20px; height:inherit; background:cyan;"> height:inherit child of the above non-abspos </div> </div> </div> <hr style="margin-top:4em" /> <p>Result: In all browsers tested, the height:inherit abspos behaves like height:25% rather than height:auto, so it seems that its parent has a computed value of simply 25% rather than auto.</p> </body> </html>
Received on Friday, 2 September 2011 06:19:58 UTC