Absolute Question
in [CSS]
|
Prev: Going Live
Next: Q: How do I create a "snaking-column"?
From: Ben C on 16 Apr 2010 15:12 On 2010-04-16, Gus Richter <gusrichter(a)netscape.net> wrote: > On 4/15/2010 7:36 PM, Mike wrote: >> Hello, >> Why is id= two relative to the corner of the "centerthis" div but >> id=three is not? > > The other respondent is right about the first character needing to be a > letter: ><http://www.w3.org/TR/html4/types.html#type-name> > > Explaining the 'why': > .Centerthis is the container and its position is "static". > The two divs in question are positioned "in-flow" to the static div. > That means they are stacked on top of each other right under .one > Position:absolute; does nothing until repositioning occurs. > #two is then vertically repositioned with top:100px; relative to the > initial containing block (body for simplicity) It's not body, but the viewport. It does make a difference because body usually has an 8px margin, and the body may be taller (and also wider) than the viewport, but bottom: 0 positions things at the bottom of the viewport.
From: Ben C on 16 Apr 2010 15:18 On 2010-04-16, Mike <ampeloso(a)gmail.com> wrote: > On Apr 16, 4:38�am, dorayme <dora...(a)optusnet.com.au> wrote: >> In article <hq93n4$cl...(a)news.eternal-september.org>, >> �Gus Richter <gusrich...(a)netscape.net> wrote: >> >> >> >> >> >> > On 4/15/2010 7:36 PM, Mike wrote: >> > > Hello, >> > > Why is id= two relative to the corner of the "centerthis" div but >> > > id=three is not? >> >> > The other respondent is right about the first character needing to be a >> > letter: >> > <http://www.w3.org/TR/html4/types.html#type-name> >> >> > Explaining the 'why': >> > .Centerthis �is the container and its position is "static". >> > The two divs in question are positioned "in-flow" to the static div. >> > That means they are stacked on top of each other right under �.one >> > Position:absolute; �does nothing until repositioning occurs. >> > #two is then vertically repositioned with �top:100px; �relative to the >> > initial containing block (body for simplicity) because the container >> > .Centerthis is "Static" (not 'absolute', 'relative' or 'fixed'). >> > The same as #three with �top:200px; >> > <http://www.w3.org/TR/CSS21/visudet.html#containing-block-details> >> >> > Note that the repositioning is relative to body which can be verified by >> > giving �position:relative �to .Centerthis which results in the vertical >> > positioning to be relative to the .Centerthis container - #two and >> > #three will be shifted further down. >> >> > #three also has �left:200px; �applied to it resulting in it being >> > repositioned horizontally relative to body, the initial containing block >> > - 200px from the leftmost edge of body. >> >> > If �position:relative; �is applied to .Centerthis the repositioning of >> > #three will be relative to the .Centerthis containing block - 200px from >> > the leftmost edge of .Centerthis >> >> With absolute positioning where there is no positioned ancestor >> to the element being absolutely positioned, it is only an >> illusion that it is positioned with respect to body. >> >> The body element might happen to be roughly there in the default >> top left position of viewport (if it is not down at the pub after >> a hard day containing its children and grandchildren). But if >> body were given a left and top margin and say a border, you will >> find that an absolutely positioned child (to take an example) is >> not positioned with respect to it. For example, if the child is >> top: 0 and left: 0 and has a short sentence in it and body is >> margin-top: 400px and margin-right: 400px, the child will not be >> within cooee of being within the borders of body. >> >> If one positions the body with a position: relative, this changes >> the situation but the point is that body is not a *positioned >> ancestor* of its contained elements. I said things about this in >> an earlier post. >> >> -- >> dorayme- Hide quoted text - >> >> - Show quoted text - > > One thing I dont understand completely > This: > h3 { > position: relative; / So that elements INSIDE this header can be > positioned relative to the header / > } > > this is stating that the relative declaration is pertaining to the > children of this not itself. Which seems to work. But why? Doesnt a > rule apply to itself? Think of it as a side-effect. Position: relative lets you move an element relative to its own ordinary position, but if you don't set top, left, right or bottom on it (which you usually don't) it stays where it is. _However_, a side-effect of position: relative is that starts a containing block for absolutely positioned descendents. And most of the time it's that side-effect you actually want. The naming is also all wrong. What they call fixed should have been called absolute, and what they call absolute relative. What they call relative should never have existed or be called something else like "offset".
From: Ben C on 16 Apr 2010 15:20 On 2010-04-16, Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote: > Mike wrote: > >> One thing I dont understand completely >> This: >> h3 { >> position: relative; / So that elements INSIDE this header can be >> positioned relative to the header / > > ... is a syntax error. > >> } >> >> this is stating that the relative declaration is pertaining to the >> children of this not itself. > > No, but it is an insufficient explanation. > >> Which seems to work. But why? Doesnt a rule apply to itself? > > If you declare `position: relative' for the H3 element it is positioned > relative with regard to its containing block Not "with regard to its containing block". The containing block is not involved at all in relative positioning. It's relative to its normal flow position. > (although that is irrelevant to display if it has not one of the > `left', `top', `right', `bottom' properties declared), and its serves > as the containing block for its positioned descendent elements. Strictly speaking not completely irrelevant. Position: relative also brings an element further forwards in the stacking order and also means that z-index starts applying to it.
From: Thomas 'PointedEars' Lahn on 16 Apr 2010 16:20 Rob W. wrote: > Op 16-4-2010 14:22, Thomas 'PointedEars' Lahn schreef: >> The root element is `HTML' in HTML, and `html' in XHTML. See also: <http://www.w3.org/TR/REC-html40/struct/global.html#h-7.3> > Eh, in the pages that I work with the root element in HTML is 'html' (no > caps). > > Would you mind explaining the difference or the possible negative effects? (This is a question that should have been asked in ciwa.html.) Element type names and attribute names are case-insensitive in HTML; no negative effects are to be expected from using the all-lowercase variant in non-declarative markup: <http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2> PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Gus Richter on 17 Apr 2010 05:29
On 4/16/2010 3:12 PM, Ben C wrote: > On 2010-04-16, Gus Richter<gusrichter(a)netscape.net> wrote: >> On 4/15/2010 7:36 PM, Mike wrote: >>> Hello, >>> Why is id= two relative to the corner of the "centerthis" div but >>> id=three is not? >> >> The other respondent is right about the first character needing to be a >> letter: >> <http://www.w3.org/TR/html4/types.html#type-name> >> >> Explaining the 'why': >> .Centerthis is the container and its position is "static". >> The two divs in question are positioned "in-flow" to the static div. >> That means they are stacked on top of each other right under .one >> Position:absolute; does nothing until repositioning occurs. >> #two is then vertically repositioned with top:100px; relative to the >> initial containing block (body for simplicity) > > It's not body, but the viewport. It does make a difference because body > usually has an 8px margin, and the body may be taller (and also wider) > than the viewport, but bottom: 0 positions things at the bottom of the > viewport. Of course you are right. I simply wanted to make things simpler with the "(body for simplicity)" and providing the link where one can read up on the detailed writeup. Here is my slightly modified version of it: Body lives in html (the root element), which in turn lives in the 'initial containing block' (which is the viewport) and which is the viewable portion of the infinite canvas area. I should have simply said "viewport" as you point out. When I composed, I thought that most had a clear vision of body and an unclear vision of viewport and that here the difference would probably be inconsequential. Perhaps if I had said "(body, less any margin and/or padding, for simplicity)"? By your singular correction, I take it that you find no other problem with my explanation of "why" for the OP? -- Gus |