Re: positioned elements: center

On Jan 5, 2008, at 6:31 PM, John Oyler wrote:

>
> On Jan 5, 2008, at 8:02 PM, Brad Kemper wrote:
>
>> I don't know if this subject has been broached before...
>>
>> Using absolute positioning to center an element is not as simple  
>> as it should be. I can position the element by setting its top,  
>> bottom, right, and left. But if I set "left:50%; top:50%;", but to  
>> center the whole element (instead of just the top left corner) I  
>> have to know its height and width, divide them in half, and use  
>> them as negative margin. It would be much simpler if I could set  
>> "center-x:50%; center-y:50%" instead of top, left, and negative  
>> margin.
>
> I like this in principle, especially since you could use those  
> independently of each other, or in conjuction with left/right/top/ 
> bottom. Bottom centering, or left centering seems a good use.

Yes, and you could always use values other than 50% too, of course.  
Sometimes you might care about where the center of a thing is more  
than where the left and right edges were, even when you are not  
trying to actually center it in some other area.

> But I don't like center-$ where $ is the direction. Is that already  
> part of other property names? If so, I guess you'd stick with  
> convention. But if not, even though I dislike it, I don't have any  
> good alternatives.

I got that from overflow-x and overflow-y, so there is precedent. I'm  
not glued to the names, but it did seem that you would need one for  
each direction.

For overflow, we have this, so I imagined it could work in a similar  
way syntacticly:

‘Overflow’ is a shorthand. If it has one keyword, it sets both  
‘overflow-x’ and ‘overflow-y’ to that keyword; if it has two, it sets  
‘overflow-x’ to the first and ‘overflow-y’ to the second.

Thus, "center:50%" would center an item horizontally and vertically  
at the same time.

> Also, what are the implications of implementing this? With absolute  
> positioning where it doesn't affect the flow of other elements, it  
> seems like there'd not be any algorithmic trouble, but maybe I'm  
> missing something...\

As in, possible trouble areas? Nothing major that I can imagine off  
the top of my head.

We'd have to specify it with a little more detail. For instance, if  
left, right, and center-x are all specified on an element, only two  
of those three values would make sense, so we'd have to say which  
two. But it is no worse than when left, right, and width are all  
specified, i would think.

A different way to go would be to match how background-position is  
supposed to work, where if you say "background-position: 50% 0", that  
means the horizontal middle of the image starts half way over, and if  
you say "background-position: 25% 0", that means the end of the left  
horizontal quarter of the image starts one fourth of the way over.  
That would clearly break existing layouts if we did that with  
position and "left" or "top" (not to mention "bottom" and "right").  
But it could work if we came up with two new positioning properties  
such a horizontal and vertical. That might look like this:

{ position: absolute; horizontal: 50%; vertical: 50%; }

However, my intuition tells me that doing it that way would be more  
likely to cause other problems, would be somewhat harder to  
implement, and would not be as valuable as being able to say exactly  
where the center of the object should fall. For instance, it wouldn't  
be able to do this:

{ position: absolute; center-x: 20em; center-y: 300px; }

Actually the one big problem with either of these is that most  
authors would not want to use them until they new that most browsers  
were implementing them, because there is no graceful degradation  
(another arguments for "supports(propertyname", I suppose). I still  
like to see it though. It doesn't seem like center-x and center-y  
would be all that difficult to implement (easy for me to say).

>
>
> John Oyler
> john@discrevolt.com
>
>
>