CSS3 Feedback: Layout
Published 15 years, 9 months past(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008’ series.)
In this round, layout. Not all of it, but the bits that struck me as either really useful or really, really way too long overdue.
Float containment — yes, we need a property that does just that. As long as we’re tied to floats for layout—and I plan to rant about that soon—there should be a clear, unambiguous, intentionally defined property that tells elements to wrap themselves around floated descendant elements. overflow works in most cases but can fall down in unusual circumstances (I’ve seen scrollbars appear where none were actually needed) and anyway, it wasn’t intended to provide the wrapping effect in the first place. That it does so is a happy side effect, but it’s still a side effect. The rest of the float-wrapping techniques are even more convoluted. “There are already ways to do that so we don’t need a property” is rather like saying “we can already do layout with tables so why do we need CSS layout?”.
Positioning by center — yes, please. The way to center an absolutely positioned element within its containing block is to set the top and left to 50% each and then define negative top and left margins that are half the positioned element’s height and width. That’s just awful, and requires at least an explicit width, if not an explicit height. When I did the structured timeline, here’s how I got the version numbers to center below the dots:
#timeline tbody td p {
position: absolute;
top: 50%;
width: 2.1em;
margin: -5px 0 0 -1em;
}
See that -1em left margin, and the 2.1em width? Just to get the center of positioned elements’ boxes sit on top of a certain left offset (defined elsewhere in the CSS). Ditto the negative top margin, to pull it upward just enough so that the elements’ boxes would have the point five pixels down from their tops line up with the vertical midpoint of their containing blocks.
I wanted to do something like this:
#timeline tbody td p {
position: absolute;
top: 50%;
position-anchor: 50% 5px;
}
That would have said that the point in the center of the absolutely positioned element should be placed at the point in the containing block 21.7% down from the top and 44% of the way across from the left. That would hang the positioned element’s center on that point, regardless of the size of the positioned element—note that I took out the width. I could stop defining explicit sizes and just let the elements be the size they want to be to show their content.
The problem is that approach doesn’t fit at all well with the way positioning layout is defined. Suppose I said this:
#timeline tbody td p {
position: absolute;
top: 50%; bottom: 0;
left: 50%; right: 25%;
position-anchor: 50% 5px;
}
Now what? I’m not even sure myself. Maybe define rename it to position-offset and define percentages to be relative to the height and width of the positioned element (not its containing block), so that it doesn’t interact directly with the offset properties like top and right?
All I want is a way to hang elements off of offset points, and not be restricted to the corners of the elements, and have the solution work even when the elements have automatic height and width, and not require extra markup to make it happen. Oh, and a ponycar.
Box sizing — what in the nine hells of Valeria is taking so long? We needed that one ten years ago. I no longer care if it’s done as its own property or as new keywords on height and width. I just want it. Someone will make it happen, with or without the WG or implementors—mark my words.
Same-height elements — yes, a way to tie element heights (whether they’re siblings or not) together would be welcome, although I can see how specifying it in an implementable would be tricky; no, display: table-cell is not the answer. Soon I will rant about this. Soon.
Comments (14)
Something I have always wanted is an expand property for floated boxes – so that if a neighouring float should drop, leaving the box with the property set as the rightmost (or leftmost), it will expand to take up the remaining room. That would make some fluid layouts work much better on small displays. (In my view, it’s not the end of the world if a float drops, it’s what they are meant to do. I’d rather have some content vertically out-of-place than squished to uselessness.
That line you quote about float containment in the original document had such a “let them eat cake” feel to it, it made me question the cluefulness of the entire group. What do they think they are there for, if not to turn a nasty hack that is used all the time into a specified feature?
The positioning by centre thing could be made much easier with the calc function. At least then you wouldn’t have to use negative margins.
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.
I feel your pain. ” “There are already ways to do that so we don”t need a property” is rather like saying “we can already do layout with tables so why do we need CSS layout?”.”
Indeed. Self-link from Feb 2006: Epicycles: are complex css layouts the new nested tables?
That sounds interesting, Richard—do you have a more detailed writeup or description I could check out?
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).
With the release of IE8, the box-sizing feature is now implemented in all four major browsers; Safari (requires vendor prefix), Opera (no prefix needed), Firefox (requires vendor prefix) & IE8 (no prefix needed).
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.
Not sure if all cases are covered, but I think the basic “positioning by center” is already more or less solved. At least a quick test [http://www.gunlaug.no/tos/moa_42.html] works ok in all the latest browsers. IE7 and older fail, but IE8rc1 get it right.
I disagree with your statement “[overflow] wasn”t intended to provide the wrapping effect in the first place.”
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
Nicole:
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.
What about instead of a ‘position-anchor’ property, you set it for each direction:
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;
This (slightly) addresses your concern as to what happens if the do say:
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…
Pingback ::
Max Design - standards based web design, development and training » Some links for light reading (24/2/09)
[…] CSS3 Feedback: Layout […]
Adding the properties vertical-center and horizontal-center to the box model would solve the issues of positioning by center, if certain other properties were to override one another according to cascading rules.
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.
Pingback ::
Stubbornella » Blog Archive » Overflow – a secret benefit
[…] an explicit height set, the browsers used the calculated height of the content instead. For more information on clearing, see this conversation Eric Meyer and I had on his […]