- From: Ka-Ping Yee <kryee@wheat.uwaterloo.ca>
- Date: Fri, 31 Jan 1997 16:01:53 -0500
- To: Chris.Lilley@sophia.inria.fr, kryee@wheat.uwaterloo.ca, www-style@www10.w3.org
> Good point. Without adding constant expressions (100%-2in) it > seems that syntax to select the reference point could be needed. [...] > And if a conflict does occur, how should it be resolved? [PROPOSAL 1] Okay. How about a more concrete proposal: One of the properties 'left', 'hcenter', or 'right' may be used to specify the horizontal position of a block element (in terms of the position of the element's left edge, horizontal midpoint, or right edge respectively). An implementation should pay attention to only the property which is specified first out of these three properties. If none of these properties is given, the assumed default is 'left: auto'. One of the properties 'top', 'vcenter', or 'bottom' may be used to specify the vertical position of a block element (in terms of the position of the element's left edge, vertical midpoint, or bottom edge respectively). An implementation should pay attention to only the property which is specified first out of these three properties. If none of these properties is given, the assumed default is 'top: auto'. The example i described could then be written #menu { position: absolute; height: 100%; right: 100%; width: 2in } I gather from the WD that only 'position: relative' elements may be considered in-line; 'position: absolute' elements have their own box and formatting. So, it is necessary to add: Of these six properties, only 'left', 'top', 'vcenter', and 'bottom' properties are valid for in-line elements (which must be positioned with 'position: relative'), since such elements may be broken into multiple boxes across multiple lines of text. [SUGGESTIONS] Upon closer inspection, the examples with regard to 'relative' positioning seem somewhat inconsistent. Example 3 would seem to show that "relative" moves only the starting point for rendering without creating a new box. However, Example 4 shows the outer element in a new box (the entire margin is out by 10 pixels). It appears to me that the positioning of the change bars in the correct vertical position is handled by the default of 'top: auto' and has nothing to do with the parent being 'position: relative', right? It took me a little while to sort this out in my head, and i think it could be made more clear by (a) fixing the example, which i think should have 'position: absolute' for the parent element (is this correct?) and (b) adding a sentence or so to point out what 'auto' does. [PROPOSAL 2] The assumption of "relative to top-left" for 'absolute' positions and "relative to auto" for 'relative' is reasonable for handling many cases, but there are two particular things i can think of which are outside its capabilities. (a) "relative to auto" for an 'absolute' position. That is, the effect of specifying "auto + 2 in" or somesuch. (b) "relative" to other things -- like the baseline, especially. For correct positioning of in-line images, the ability to align with the surrounding baseline seems very important. In particular, it allows CSS to subsume all capabilities of the ALIGN attribute in a consistent, well-defined manner). This could be handled with an additional property in the spirit of the 'background-position' property from CSS1. origin: (<percentage> | left | center | right | auto) (<percentage> | top | center | bottom | auto | baseline) ^^^^^^^^^^^^ maybe? The first parameter gives the horizontal origin and the second parameter gives the vertical origin, within the parent element. Allowing <percentage> (possibly an option to consider) gives more precise control when needed. When the property is not specified or when only one parameter is specified, the unspecified parameters default (to '0% 0%' for 'position: absolute' and to 'auto auto' for 'position: relative'). For example, if i had an in-line image of a rendered font 25 pixels high which had a baseline 5 pixels from the bottom, i could align it with #image1 { position: relative; origin: auto baseline; bottom: 5 px; } The confusion about MIDDLE, ABSMIDDLE, TEXTMIDDLE, and all the rest of that garbage could be finally put to rest this way. [ANOTHER SUGGESTION] The wording in section 3.2, > For elements with 'absolute' positioning, 'left' and 'top' > are relative to the origin of the nearest element with > 'position' of value 'absolute' or 'relative'. should probably be clarified by replacing "nearest element" with "nearest ancestor" (i assume that is the intent). [QUESTION] Another curious issue that came to light while i was thinking about this (probably more of a CSS1 issue than a WD-positioning issue): when 'width' and/or 'height' are specified for a text element, should the characters be (possibly non-proportionally) scaled to fit the specified box? Such abilities could make for some interesting possibilities. Back to the original topic -- there are really two reference positions, one in the element and one in the parent, which are addressed respectively by proposals 1 and 2. Please consider them separately, if you could. Thanks for considering these issues. Ping
Received on Friday, 31 January 1997 16:11:24 UTC