Last Comment Bug 391528 - Percentage relative positioning offsets don't work in auto-height containers
: Percentage relative positioning offsets don't work in auto-height containers
Status: RESOLVED DUPLICATE of bug 260348
: css2
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: unspecified
: All All
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://spectrostudio.com/bugs/mozilla...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-09 08:01 PDT by vituko
Modified: 2013-08-26 22:56 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
reporter's testcase (2.57 KB, text/html; charset=UTF-8)
2007-08-09 08:19 PDT, David Baron :dbaron: ⌚️UTC-10
no flags Details

Description vituko 2007-08-09 08:01:16 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)
Build Identifier: Gecko/20070725 Firefox/2.0.0.6

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
Comment 1 David Baron :dbaron: ⌚️UTC-10 2007-08-09 08:19:58 PDT
Created attachment 275973 [details]
reporter's testcase
Comment 2 David Baron :dbaron: ⌚️UTC-10 2007-08-09 08:47:55 PDT
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.
Comment 3 philippe (part-time) 2007-08-10 01:01:27 PDT
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).
Comment 4 Rob Belics 2007-08-10 02:57:37 PDT
The test case is without a doctype and contains errors.
Comment 5 Gérard Talbot 2007-08-15 06:24:57 PDT
> 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.
Comment 6 vituko 2007-08-16 00:14:27 PDT
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.
Comment 7 David Baron :dbaron: ⌚️UTC-10 2009-08-05 14:55:13 PDT
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.
Comment 8 David Baron :dbaron: ⌚️UTC-10 2013-08-26 22:56:47 PDT

*** This bug has been marked as a duplicate of bug 260348 ***

Note You need to log in before you can comment on or make changes to this bug.