Closed Bug 51230 Opened 24 years ago Closed 22 years ago

Width of Absolutely positioned, non-replaced elements calculated incorrectly.

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED INVALID
mozilla1.0.1

People

(Reporter: val, Assigned: ian)

References

Details

(Keywords: css2, testcase, Whiteboard: (INVALID pending errata))

Attachments

(1 file)

From Bugzilla Helper: User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (Win98; I) BuildID: 2000080712 According to CSS2 10.3.7, the Width of an Absolutely positioned non-replaced element, plus left, right, margins, borders and padding, should equal the width of the containing block. This is similar to the calculation of Width for Block-level, non-replaced elements in normal flow - for our purposes, if left, right and width are default auto, margins are default zero, and border-style is default none, then the calculated width should also be the same. Going through the steps in 10.3.7: (Border width => 0) 1. Left => 0 2. n/a 3. Right=> 0 4. margins already 0 (default) 5. n/a 6. solve equation for only remaining auto i.e. width => width of containing block 7. Right remains 0 However, in M17 the Absolutely positioned element is instead just wide enough for its contents. Reproducible: Always Steps to Reproduce: The attachment consists of four DIVs: - two Block-level, non-replaced elements in normal flow - one static and one relative, and - two Absolutely positioned, non-replaced elements - one fixed and one absolute. Actual Results: Notice that the widths are calculated correctly for the first two DIVs, but incorrectly for the second two. Expected Results: In this example, Widths of Absolutely positioned DIVs should equal width of containing block.
Attached file Auto Width testcase (deleted) —
There are (still unpublished, for some reason) errata to the CSS2 spec changing these rules.
Taking bug. I will investigate this at some point. However, I believe we are probably following the [new] rules correctly.
Assignee: clayton → py8ieh=bugzilla
QA Contact: petersen → py8ieh=bugzilla
Marking NEW since bug is under investigation.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that do not have the "testcase" keyword and yet have an attachement with the word "test" in the description field. Apologies for any mistakes.
Keywords: testcase
'Errata in REC-CSS2-19980512' - http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html - was published 2000/10/24. It contained Changes to the calculation of the _height_ of abs pos non-replaced elements, but not the width. Does anyone have any knowledge of future changes to the _width_ calculation? Otherwise, this is a bug which should be fixed.
Near the very bottom of the page you site there is a "[Text forthcoming]" for the errata for widths. The changes should be similar to the ones for heights.
OK. Hadn't noticed publication of later version of Errata. Thanks.
Does that mean this bug is INVALID after all?
Maybe it means there is a very high probability that this bug _will be_ INVALID. Pity it can't be RESOLVED 'PENDING'...
moving to m1.0.1.
Keywords: css2
Target Milestone: --- → mozilla1.0.1
It is my understanding that "absolutely positioned non-replaced elements" in the CSS2 spec actually refers to position:relative -- position:absolute and position:fixed are "absolutely positioned replaced elements". If this interpretation is correct, then Val's testcase exhibits the correct width calculation for all position types: position:static and position:relative calculate widths with reference to the containing block, and position:absolute and position:fixed calculate width according to the intrinsic width of their contents. (tested on Win2K build 2001072003) Can someone confirm this interpretation?
'absolutely positioned elements' are those with position:absolute; 'fixed positioned elements' are those with position:fixed; 'relatively positioned elements' are those with position:relative; 'non-positioned elements' are those with position:static; 'replaced elements' are images, applets, IFRAMEs and the like; 'non-replaced elements' are everything else. Thus an 'absolutely positioned replaced element' is an image with position: absolute, which an 'absolutely positioned non-replaced element' is any other element with position:absolute.
...although 'absolutely positioned elements' can in some cases refer both to those with 'position: absolute' and those with 'position: fixed'
Whiteboard: (INVALID pending errata)
Reconfirmed using FizzillaCFM/2002071208, at least as originally reported; boxes 3 and 4 are only as wide as their contents. Setting All/All.
OS: Windows 98 → All
Hardware: PC → All
Is this behaviour of mozilla on this issue currently acceptable? From 10.3.7 of the css2 spec: "The constraint that determines the computed values for these elements is: 'left' + 'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + 'right' = width of containing block " Rearranging this, you can say: 'width' = width of containing block - [all other variables] Yet, in Mozilla, if you specify a style for a top level <div> (ie containing block = page) as such: div.testcase { left: 50px; right: 50px; width: 100%; } The width is evaluated as the width of the page by Mozilla. Surely this is incorrect, as it should be [page width - (left + right)]. This is how IE, at least, evaluates it. And the differing behaviour kinda impedes cross-browser css. (Not that that is the reason it should be changed. It should be changed because it is incorrect.)
1) Please read CSS 2.1, not CSS 2, for positioning rules. 2) Percentages on 'width' *always* refer to the containing block width, period.
Blocks: 199702
http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width (CSS 2.1, section 10.3.7) has the new positioning rules. Going through them: pre-numbered-list: "If all three of 'left', 'width', and 'right' are 'auto': if 'direction' is 'ltr' set 'left' to the static position and apply rule number three below" Rule #3 is: "'width' and 'right' are 'auto' and 'left' is not 'auto', then the width is shrink-to-fit . Then solve for 'right'" Which is what we're doing.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: