Top, height, and bottom would all be considered the same, and override one another while vertical-center is defined, and likewise for left, width, and right for horizontal-center. With any one of these, a height or width can be calculated, and the last one defined should always be the one used for the calculation.

position: absolute;
top: 0;
bottom: 0;
position-anchor-top: 50%;

However, I don’t see an obvious set of defaults if they do:

position-anchor: 50%;

Right now with padding, this would make padding-top = 50%, padding-left = 50%, etc etc. Since the center of the element can’t be at both the top and the bottom, following suite with how padding and margin turn 1 number into 4 wouldn’t work.

Another issue is that, it wouldn’t make any sense to say:

position: absolute;
top: 0;
bottom: 0;
position-anchor-top: 70%;
position-anchor-bottom: 30%;

So you would have to ensure that the anchoring left value is to the left of the right value.

Or something. This is getting tricky…

position-anchor-top: 50%;
position-anchor-right: 10%;

The default would just be the top, bottom left or right of the element. Then you could make it so you could define all at once, like with padding or margin:

position-anchor: 50% 5px auto auto;

It is a sensible reaction to an element that has no height defined, but has overflow hidden, to set the height equal to the content height.

In hindsight, yes. But when the technique first came up, someone asked me if that was the intended effect. I thought not, but asked a couple of Working Group members if it was just to be sure. They said no—then, upon looking again at the relevant part of the spec, said words to the effect of, “Oh, hey, yeah! That IS what the spec’s wording implies! It isn’t the case we were trying to cover, but it’s covered nonetheless, so yay us.”

Thus my statement that it wasn’t intended for float wrapping in the first place, but that its utility in that manner was a happy side effect. I suppose it’s possible that whoever wrote that prose intended that behavior in that case, but if so, apparently it wasn’t shared with the rest of the WG.

It is a sensible reaction to an element that has no height defined, but has overflow hidden, to set the height equal to the content height. Generally this is my method of choice, but it does have a couple drawbacks.

1. Popups/popovers etc that originate in that block of code may be cropped.
2. Printing will skip chunks of content in some versions of FF (the bits that overflowed the page bounding box on which the overflow:hidden block originated).

Cheers,
Nicole

IMO if MS could have chosen one CSS3 proprerty to implement this was it. Implementing this property in Javscript (which you link to) however, is completely inpractical.

I know just how you feel, Tao, though I admit I understand the place from whence that attitude comes—the WG gets a ton of requests to add every idea anyone’s ever had for improving CSS, so they build up some automatic defenses. “There’s already a way to do that” is one of them. I get that, but it’s not an acceptable objection and so I thought I’d better address it head-on.

Jake, are you sure calc() will work in this case? I ask because it seems like percentages on offsets would be calculated with respect to the containing block, not the positioned element. Of course I may have missed something.

Bruce, if you think this post echoes you of three years ago, just wait until you read my next post (which is almost done).

Indeed. Self-link from Feb 2006: Epicycles: are complex css layouts the new nested tables?

Really enjoying these articles by the way. Hopefully more articles like this will get CSS moving quicker.

Some engines are messing around with complex (and IMO unnecessary) ideas like animation in CSS, I’d be more interested in them experimenting with solutions to common problems like the ones discussed here.

Jake.