I have a bunch of blocks I'm floating left. They're of varying heights; some short, some tall.
Now, these blocks are dynamically generated, so there's no predicting how tall each block will be (or how many there'll be). Needs to be flexible, though, so if those blocks don't all fit one one row, well, I need a second row.
Problem: since the blocks are of varying height, any block that spills over onto the next row gets "nestled" among the existing floats:
I need the spillover-blocks to form their own row:
I know this is proper behavior (floats favor higher positions over left-er positions), but what's the best solution for this? I can change the HTML structure (and obviously any CSS), but I can't hardcode in a clear: left.
Here's a jsFiddle.
Use display: inline-block on the blocks; save float for situations where you actually need to wrap text around an element.
Results: http://jsfiddle.net/EQyVy/18/
Related
I'm trying to make a list of thumbnails of variable amount be centered while the thumbnails all fit on one line, but then subsequent lines be left-aligned, while the parent element responsively stays centered in the page. width:fit-content works well for one line, but when there are multiple lines it goes to 100% width (in mac chrome anyway). Illustration of the problem:
http://codepen.io/scotthorn/pen/eutAH?editors=110
If there is another way to achieve my desired goal, I wouldn't mind changing any part of the css or html markup. A background that fits the area isn't necessary, it's only in my example to better show what's going on. My primary goal is to have a list that behaves like a centered container of inline-block elements for one-line, but then when a second line has to be created, the first element in it lines up below the first element of the first row rather than being centered by itself.
Hopefully that makes sense, if not I can make a mockup.
I would imagine wrapping the whole thing in a div and centering that with a % width would do what you want. But a mock up would help me understand.
Or you may be able to use margins to squish the inside content.
Your example works well, except you probably want to add a max-width to your UL..
For example, if you wanted to have a max of 7 items per line in your case, you would
add:
ul { max-width:630px}
updated codepen
good luck =)
I want to have a region of my page that is reserved for context sensitive help text. It is blank, except when hovering over certain particular elements. But, of course, there are several independent pieces of text from which the visible selection might be chosen. This is in a page flow, with more stuff below it. I tried using a div "positioned", and putting help divs inside that. Each of the help divs is position: absolute; top: 0px; visibility: hidden; with the intention that JS would make one of them visible at a time, yet the space would have been reserved for the biggest piece of text in any of the help divs. Well, as most of you have guessed, because the help divs are position: absolute, their heights don't affect the height of the enclosing div, which ends up at a height of zero.
how can I achieve this? I don't want to use pixel sizing to force a height, because it's almost always wrong on some browser/font combination, and would be a bear to keep tweaking every time the help text were changed, or a new, longer help segment gets added to this.
Did I make sense, or do I need to try to draw pictures?
Yep, you're making sense. As you indicate correctly the containing element is collapsing to zero height since it doesn't contain any flow children with size. There is no simple solution to this without resorting to Javascript as obvious alternatives mean making all of them part of the flow layout, meaning the container would grow to accomodate all of the texts.
Solutions that would work:
Apply display:inline-block to all of the help texts to put them next to eachother, put them in a container element that has a width of 10000px or more as required, and encapsulate that element in a container with overflow:hidden. This way the container will actually assume the height of the largest child. Activating a text would then require moving the element in the DOM to the front so it is drawn first, or scrolling to bring it to the right position, which could be complex.
After loading the page use Javascript to measure the actual heights of the elements, set the largest one as the height of the container, and then apply display:none to the children instead of visibility:hidden.
The second option is easiest, and would be my preferred choice. It all depends a bit on your specific case though whether there's a better alternative.
I have a design I'm working on that is almost complete, but I'm having trouble getting the CSS to do what I want. What I am trying to do is something like this:
However, when the page is generated, this is what the output looks like:
How can I get the third box to float up under the first and next to the second? I have tried every trick I know, but can't get it to work. I should also mention that each block is added to the page by a loop in PHP pulling from a database, so I'm kinda limited by not having static content, and have no way of knowing ahead of time how tall a particular block is going to be.
If the number of columns is variable, CSS can't really do it (if you want it to work in all common browsers), so instead use jQuery Masonry which is designed to solve exactly this problem.
Here's me saying the same thing, but with more words: CSS two columns with known children width
Per the second layout, a good option is using three primary columns. There are several grid systems available including Twitter Bootstrap and 960 Grid that will help you get the basic framework laid out quickly and sans quirks. When divs (block elements) fall within any of the three columns, they'll stack up, top-to-bottom, naturally.
Regarding the bottom of the divs lining up perfectly, you'll be able to use JavaScript to calculate the overall height of the parent of the columns (which will naturally inherit the height of the tallest column), calculate the total height of the block elements within each column, and use javascript to add the difference in height to the lowest block element for each.
Be sure to account for padding and margin in the JS height calculations.
Try putting the divs into 3 columns instead of stacking them in the order they appear.
That behaviour is because of the float rules. The top of a floating element cannot be over the top of another element that came before it in the normal flow of the page. I don't know exactly how you position your elements but you might want to look into that.
Here is the Css Specs for float: http://www.w3.org/TR/CSS2/visuren.html#float-rules (It's css2 but the rules still apply)
Look at rules 5 and 6
Is thee any benefit to wrap Main content and Context div in a content div?
Column can be increased. like 1. Main content 2. left sidebar 3. right sidebar.
My main question is is there any benefit to wrap all in another div?
(source: wpdfd.com)
There can be. So the answer is... it depends.
Generally I will wrap adjacent divs like this, particularly if there is a semantic reason to do so. But even if there isn't there's next to no overhead. Often you will find it much less awkward if you have this kind of nesting. For example, it would make it much easier if you wanted to float one or both child elements.
In this case you could argue your document consists of:
Header
Content
Footer
On this page there are two columns to the content but on other pages there might not be. Other pages might be a single column or have five. Whatever the case, having that content div wrapping all the columns will make a general layout (for all cases) much easier.
Is it necessary? Absolutely not. You could make it work either way. Both approaches are fine and work.
Use it if you intend to "group" the positions of main content and context together, so that you for example can position them relative from each other without influencing the other elements such as header and footer negatively. In semantic/SEO terms that extra div has in fact no impact.
If the sidebar and main-content divs are always together, I think the second option is smarter, because you can use the id for the outer-content wrapper for both css and javascript to manipulate the entire area at once.
The only reason to NOT do it, other than a strong minimalist attitude (which I tend to have) is if you want each area of the page to be truly modular and independent. Experiments like csszengarden are founded on such a principle. This philosophy, in a nutshell, thinks that divs and other elements are chunks of information that should have the ability to be arranged in any way a designer wants (putting your header at the bottom, for instances, or swapping the main-content with the sidebar div, etc). By using a wrapper div, you are forced to use techniques like fixed positioning to break that inner div out of the wrapper (maybe to put it in the upper left corner, for instance).
But aside from that, semantically the two chunks seem to go together, so wrapping them is not a hack. Look forward to the HTML 5 element <aside> which is explicitly meant for side notes like the one in your example.
I sometimes find myself creating a div which serves no other purpose than to hold another element.
For example when creating a menu, I would create a div and assign it a background colour, position etc. Then within it I would create an unordered list.
I could surely assign all the properties I assigned to the DIV to the UL and not use a div at all.
Any ideas of what is best practice and reasons for it.
Thanks
Zenna
DIVs can be useful for grouping semantically related elements. If you are simply wrapping a single element that is also a block element, then you are simply adding bytes to the file.
No, they are not. The purpose of a div element is to create block level structure in the document. If you can lose them just lose them. Never use divs to solve design purposes, css is for that. Use html elements each like list, data definitions or tables (which were overabused in the past and used as the divs are now for css purposes). The more diverse your HTML knowledge is the less you are using divs all over the place.
I use often divs to keep child-padding/margins from ruining parent-width. But you need to be careful with this type of stuff - you could end up adding a bunch of nonsense.
The real issue is that we are using HTML in ways that its creators had never imagined. The need for 'all those divs' is because some really smart people have found some very creative ways to take a very old standard and do some very modern things with it.
Best practice should be to use as few div elements as possible. If you've got a div elements with only one child, chances are it's a useless div. The div element should really only be used when you need a block element and there is no semantic pre-defined element at hand. This includes grouping elements as Renesis suggests.
In the case of a UL, yes, the DIV is unnecessary. They are both block elements, so anything you can do with a DIV wrapped around the outside you can do directly to the UL itself.
However, because of the Box Model problem with some IE browsers, some people tell you to add these DIVs as a workaround. When you combine padding and width, IE6 disagrees with other browsers about what the final size of the element will be. So one workaround is to put padding but no width on an inner element, and width but no padding on an outer element.
Div's are really a necessary evil without a more semantically rich set of tags.
Their purpose is to server as a generic container. Therefore, I suppose you could say they do their job well.
If you can do what you're trying to do without the additional div, then leave it out. If it's an important part of your design that you can't fix with some clever CSS, then it's still a whole lot better than using tables...
I use DIVS primarily for at least one of two main reasons:
I need it to provide a new physical level of CSS in some way (either child padding inside a fixed width element, a shadow or a double border around an image, etc.)
It logically groups the elements it contains (for future portability and semantics in both HTML and CSS - I.E. "div#menu .label". This way I can use the "label" class several places but have a specific style applied to labels within the "menu" div).
For example, if you were to transfer all attributes to the UL, but then decided you wanted a caption or image above or below the menu but in the same location, you would have to create the DIV again to place the new element inside, and transfer half of the attributes back to it.