Re: CSS Positioning Draft

> 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