User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20070310 Iceweasel/184.108.40.206 (Debian-220.127.116.11-1) Build Identifier: Gecko/20070725 Firefox/18.104.22.168 I cannot believe it, but today MSHTML/Trident works and gecko does not. We are searching a way to center (both dimensions) without tables and without fixed dimensions (an adaptative system). Any way we've found a bug : A relative positioned layer is inside another relative positioned too and left floated. So, the second one (the outer one) fits the dimensions of the first one (the inner one). All right, if the inner one is set to left:-50%, it's ok. But if it's set to top:-50%, nothing happens. It fails with relative units (%). Another case : the same situation, but we forget the top attribute and now we set margin-top:-50% (In our example -100%). In this case, we've seen that the render uses the width to get the relative margin but it should get the height. It would be really cool if you could give us a solution. Thanks Reproducible: Always Steps to Reproduce: 1.See our exemple, please
CSS2 ( http://www.w3.org/TR/REC-CSS2/visuren.html#position-props ) said: For 'top' and 'bottom', if the height of the containing block is not specified explicitly (i.e., it depends on content height), the percentage value is interpreted like 'auto'. but that's been removed in CSS2.1. Fixing it requires that we do an extra pass to fix up percentage relative positioning offsets at the end of block reflow, but I don't think it requires anything broader than that (except in cases where the containing block isn't a block; we might have some of those, e.g., with scrollframes, although probably not 'auto'-height). I'm not sure if this is a duplicate.
Fwiw: Opera 9.22 display the test case the same way as Gecko. Webkit latest build positions the yellow box at the top of the page (red box), but otherwise does the same as Gecko for test case 1 (CENTERING HACK 1).
The test case is without a doctype and contains errors.
> CSS2 ( http://www.w3.org/TR/REC-CSS2/visuren.html#position-props ) said: > > For 'top' and 'bottom', if the height of the containing block is not specified > explicitly (i.e., it depends on content height), the percentage value is > interpreted like 'auto'. > > but that's been removed in CSS2.1. IMHO, the latest CSS2.1 spec still maintains exactly this same interpretation but it is in 3 parts (sections 9.3.2, 10.1 and 10.5 of current/latest CSS 2.1) > I'm not sure if this is a duplicate. I am convinced this is the same bug as bug 260348; same summary, same description, roughly same comments.
Ok, we are speaking about two things,... 1 - top/bottom in percentage value when parentNode has its height as auto. Ok, gecko follows the w3c specification. Duplicated 2 - margin/padding-top/bottom in percentage is calculated with respect to the width of the generated box's containing block (and not the height...). Ok, gecko follows the w3c specification. Not sure if duplicated (not answered). I don't read the specification every time I have a problem. But mozilla/firefox often goes further than w3c specification. Simply, these both cases doesn't work logicaly for me. For me there's a problem. There is no simple way to center verticaly without table display, nor knowing "a priori" the dimensions of the box. It's a very important limitation.
The working group decided today (quoting from http://lists.w3.org/Archives/Public/www-style/2009Aug/0092.html ): - RESOLVED: CSS2.1 Issue 134 (percentage offsets for relpos in auto-height containers) closed No Change. http://wiki.csswg.org/spec/css2.1#issue-134 (the message that raised the issue was http://lists.w3.org/Archives/Public/www-style/2009Jun/0056.html .) That said, during the 30 seconds of time we had to discuss the issue I didn't remember why it was tricky; now I do.