What is the reason of using float:left for an element with width:100% in the 1140px Grid V2 by Andy Taylor https://github.com/andytlr/cssgrid
.row .twelvecol {
width: 100%;
float: left;
}
If for no other reason, probably consistency. Since all the other column numbers have to be floated (to get them as column groups across the row), it may be simply so that the full width column .twelvecol would have the same float applied, therefore being less likely to cause issues of it behaving differently with its wrappers or content compared to other column groupings.
Look at this fiddle even in a modern browser (Firefox 18) and note how the second full width row (the third row of the example) is not showing its yellow background color because the float was removed from it but it holds a floated element in it. This would be the type of issue avoided by putting a float on it.
Related
I'm trying to add a flexbox element to the content area of a two column layout. The layout has a fixed width sidebar and fluid content. It uses float: left and negative margins to achieve this.
The goal is for the flex container to be 100% width of the parent. Flex items should be displayed in rows, with excess items wrapping to the next row.
The straight-forward approach works fine in Firefox and Chrome:
.flex-container {
display: flex;
flex-direction: row;
flex-wrap: wrap;
align-items: stretch;
}
.flex-item {
flex: 1 0 100px;
padding: 10px;
border: 1px solid gray;
}
...
<div class="flex-container">
<div class="flex-item">Item</div>
<!-- more items here -->
<div class="flex-item">Item</div>
</div>
Full example (works in FF and Chrome, but not IE 11):
http://jsfiddle.net/btc9chw0/3/
The problem
In Internet Explorer 11, all items are displayed on a single row. They never wrap to the next row, even when there are lots of items. This causes the page to become much wider than the browser window.
After lots of experimentation, it appears that this is somehow related to the fact that the flex container is inside a float: left element. Removing the float allows items to wrap correctly, but breaks other parts of the layout. The content area can have other content in addition to the flexbox, and some of that content needs to use float: left and clear: both. Without a floating parent element, a clear: both would push everything below the sidebar. Giving .flex-container a fixed width also fixes the problem, but in this case we want it be 100% width.
Firefox screenshot:
IE 11 screenshot:
The question
Is there are way to make flex items wrap to the next row in IE 11 when the parent of the flexbox container has "float: left"?
Disclaimer: Please disregard, for the moment, the fact that this layout uses both floats and flexbox instead of just one or the other. In this case, flexbox is a nice-to-have enhancement for one part of the page, while the general layout must be more robust.
The underlying issue here actually has to do with the auto measurement of a container in a shrink-to-fit context. By making .content have a min-width of 100% you've left the max-width to auto so the browser needs to measure the content to know its max-width to shrink down around it.
In IE, complete layout will be done to get the exact result with no limitations if none were set (as is the case here, we actually have infinite space since we can scroll and you have limited the width anywhere within its ancestor tree). Webkit and Gecko had made some changes in the past to avoid having to actually do layout and do an approximation, even though the actual measurement results were incorrect since they didn't know how big other (shrink-to-fit containers were) they decided the perf benefits were worth the tradeoff. With Gecko, Webkit and Blink (due to forking from webkit) all using this same behavior we changed our implementation to match this in Microsoft Edge and so we render the same as Firefox, Chrome, Safari. To get the same result in IE11 you'll need to provide a maximum width constraint when in a shrink-to-fit context (floats, abspos, table cell, etc).
Ultimately I prefer the IE behavior because it actually makes sense and is consistent. If there is enough space to lay out the content, the layout shouldn't change (as is the case here). Here is a simpler example showing why this approximation can cause issues, there is still enough room in the viewport to render the same result in each case but because they can't determine the actual dimensions of the floated blocks you get different results in Chrome/Firefox/Safari/Edge; while in IE they produce the same consistent result.
Sorry for the long reply, but I wanted to provide the context for why IE seems incorrect here.
Let me know if you need any further clarification.
I have some very simple sub-navigation that I'm trying to build across the top of the content area within my web site, but CSS doesn't seem to have any simple solutions for such a common problem: I want either 3 or 4 equally spaced DIVs across the top of the page.
1) e.g. 3 Variable-Width, Equally-Spaced DIVs
[[LEFT] [CENTER] [RIGHT]]
2) e.g. 4 Variable-Width, Equally-Spaced DIVs
[[LEFT] [LEFT CENTER] [RIGHT CENTER] [RIGHT]]
My solution for the first problem with only 3 DIVs was to float the left and right DIVs, and then assign an arbitrary size to the middle DIV and give it "margin: 0 auto". That's not really a solution, but assuming there are no changes to the navigation, it gives a rough approximation of what I want the results to be.
The solution I have for the second problem with 4 DIVs is to simply center a DIV in the same way as before, but then float two DIVs within that, e.g.
[[LEFT] [[LEFT CENTER] [RIGHT CENTER]] [RIGHT]]
But again, this requires applying an arbitrary size to the middle DIV for alignment, and if any language or image changes are made to the site, alignment values will have to be recalculated. As well, it's simply an over-complicated solution that requires merging structure with presentation.
Any help is greatly appreciated.
EDIT 07/20/2012 5:00PM
Alright, I put the "table-cell" solution into place using percents, but I encountered another issue within my slightly more complex implementation: the issue at hand is that each DIV I was referring to is actually a container for two more DIVs which are icon-label pairs, inlined either by float or by display:inline-block.
e.g. http://jsfiddle.net/c3yrm/1/
As you can see, the final element in the list is displayed improperly.
Any help is again greatly appreciated!
EDIT 07/20/2012 7:16PM
Final solution with arttronics' help: http://jsfiddle.net/CuQ7r/4/
Reference: jsFiddle Pure CSS Demo
The solution was to float the individual breadcrumbs while using a simple formula to determine the percentage of breadcrumb width based on the number total breadcrumbs.
You could use percentages, then it just comes down to simple math:
[[LEFT=22%]2% margin><2% margin[LEFT CENTER=22%]2% margin><2% margin[RIGHT CENTER=22%]2% margin><2% marginRIGHT=22%]]=100%/??px
You could then specify a width for its container and use
display:inline;
to keep them inline.
Note: If you use borders to see what the divs are doing that will add space unnaccounted for so you would need to reduce your elements width by 1% or so OR just change their background colors.
ol {
width: 400px;
/*width: 800px;*/
display: table;
table-layout: fixed; /* the magic dust that ensure equal width */
background: #ccc
}
ol > li {
display: table-cell;
border: 1px dashed red;
text-align: center
}
like here: http://jsfiddle.net/QzYAr/
One way I've found to do it is using flex boxes (or inline-flex).
Here is a great explanation and example of how it can be done.
I think in the future, flex boxes will be the superior way of handling this sort of thing, but until other browsers catch up with Mozilla's way of thinking for how to use the flex-basis attribute (with min-content, max-content, fit-content, etc. as values), these flex boxes will continue to be problematic for responsive designs. For example, occasionally the inner content (a_really_really_long_word) can't fit in the allotted space when the window is squished down, and so sometimes some things might not be visible off to the right of the screen if you're not careful.
I think perhaps if you make use of the flex-wrap property, you might be able to ensure everything fits. Here is another example of how this might be done (in Mozilla browsers anyway).
I tend to use flex boxes for letterheads or tables where the width is fairly fixed (not too small) because they usually space themselves nicely; I tend to use nested float and inline-block objects for websites where the content must squish down very small (as suggested in some of the other answers here).
The problem I'm having is I have two divs at the top of my page, one contains a repeating blue background, the other contains a background image.
I have to set the height of both divs in order for them to expand vertically, the don't expand with the content. I have that form on the right hand side set to overflow. Which I believe is what's causing the problem.
I have tried not having the height css in the code, but it still won't expand vertically.
In order to get the backgrounds to even show up I have to manually set the height.
This is the page: http://www.repipespecialists.com/landing/google/repiping.html
This is the CSS code:
#top_container {
width:100%;
height:1040px;
background-image:url(../images/top_bg_repeat.jpg);
background-repeat:repeat-x;
background-color:#83b4e9;
}
#top_header {
width:1200px;
height:1040px;
background-image:url(../images/header_bg.jpg);
background-repeat:no-repeat;
background-color:#83b4e9;
margin: 0 auto;
}
I agree with WDan in that the issue you are having is due to your use of float: left and float: right on the left_content and right_content div elements.
When you use float on an element, you are basically removing it from the normal flow of the document. By default, elements will appear on the page in whatever order you specify in the markup. Using float (or things like position: absolute) will remove the element from this "order", or "document flow", such that the floated element will be ignored when placing other elements in their default position on the page.
Since the space used by these floated elements are ignored, the top_header div does not take the floated element's size into account when determining its own size. This is why your div is not automatically expanding.
Another alternative to float is to use display: inline-block. Here are some links you can read to learn more about the differences:
http://www.ternstyle.us/blog/float-vs-inline-block
http://www.onderhond.com/blog/work/inline-block-vs-float/
http://designshack.net/articles/css/whats-the-deal-with-display-inline-block/
http://robertnyman.com/2010/02/24/css-display-inline-block-why-it-rocks-and-why-it-sucks/
I think the problem is you use float in 'left_content' and 'right_content'
Use “overflow: hidden” in the wrapper div.
I'm trying to fill 100% of the viewport in WebKit (Chrome) using maths.
What I'm doing right now is counting the number of elements and dividing that into 100 and then setting all of the widths for the elements to the resulting percentage, following the basic plan of liquid elements.
The problem is that as the number of elements gets very high, but even after the first few are added, there quickly begins to be an issue where a large amount of space opens up on the right of the elements as the browser fights between percentages, pixels, and rounding.
So my question is, how might you go about taking a variable number of elements and ensuring that the entire viewport is filled?
CSS and Javascript are both fair game, but I would prefer to avoid jQuery unless it has an incredibly simple solution. However, if you can only do it through jQuery, even if it's longer, post it anyway and I can see if I can unravel it.
I should stipulate clearly that this solution must work for a liquid layout. The browser and the containing elements must be able to resize down to about 200px. Any solution that depends on cutting apart a known quantity of pixels won't work for me.
I've published a test site if you're not sure what I mean.
display: table to the rescue!
The problem with my initial solution, of course, is that the elements are floated left and then given explicit widths. The upshot is that as the browser rounds the widths to the nearest pixel, you get jumpiness on the right-hand side of the viewport as you slowly gain and loose total pixels.
The beauty of a table is that the browser already knows that each cell should fill exactly its portion of 100% of the table's width. If the table is 100% as wide as the viewport and you have 4 cells each cell will be 25% of the viewport. Add another and the browser gives each cell as close as it can to 20% of the viewport. It handles all rounding for you so at any given time some of the cells may be a pixel bigger than other ones but the difference is always a pixel and the viewport is still filled perfectly.
The only downside I can see is that you need to have elements that you can put stuff in to be able to use display: table-cell because table cells are non-block level elements and can't be given explicit widths. They need content in order to display. Luckily for me, I can have a ul with li elements filled with a elements and thus I can hang the CSS nicely.
For the list
<ul class="mess">
<li class="mess-part"></li>
<li class="mess-part"></li>
<li class="mess-part"></li>
<li class="mess-part"></li>
</ul>
You need to apply the styles
.mess { display: table; height: 300px; width: 100%; margin: 0; padding: 0; }
.mess-part { display: table-cell; height: 100%; }
And you get a nice, pretty, 100% wide, always filled, liquid-layout spread of elements.
I've published an interactive version of the fix.
Pretty neat, eh?
HT to this question for getting the gears in my head turning.
Maybe because for example 5.4% is rounded to bottom, so if you got 10 elements, which all miss 0.4% you are missing 4% of the page, so if you got 20 elements, your missing 8% and so on. Maybe if you Math.ceil 1 element and Math.floor the next one. You will have less white space on the right side. Because you then only miss 0.2% each 2 elements. But still generating a white space.
What is the best solution is to not use % but us PX. Because those are round to PX instead of % which is a lot more. But then still you can use Math.ceil and Math.floor to fix the floating point numbers and have no white spaces anymore.
i'm really stumped by this current page i'm working on. The layout is a grid.
The page is dynamic so the cells (divs) will be shifting about or even disappearing over time.
Because the location of the last cell will be changing, i want this last cell(div) to always extend horizontally across the remainder of the containing div. The point being to create a gray top border.
here's a link, it's obvious to see what i'm trying to do.
http://www.tomcarden.net/ug-post.html
i thought it would be easy. i thought the last cell (div) if not given a width attribute would naturally take up the remaining space in the row but it's not (?)
the class of this div is .last-cell.
i tried making the width:100% but that doesn't work. that breaks the page. the cell clears and starts a new row, i tried clear:none so it would stay floated to left but that didn't work. this can't be that hard...?? can anyone lend some advice on this?,
big thanks in advance.
Quite tricky, but try adding this:
.last-cell {
width: 100%;
margin-top: -153px;
}
The width: 100%; will indeed make it into one row, bumped by the last picture, but with the negative margin you push it back up. To keep the image on top, apply:
.grid {
z-index: 100;
}