Floating a div so divs flow around it


  • Trolleybus Mechanic

    Been banging my head around this one for a bit, and while I'm sure I can figure it out-- the punchline is "css".

    I've got three divs. I want them to position like below.  Depending on how much content is in the green div, either the blue or orange should flow around it.  Best I've done so far is to either get the blue and orange to be as wide as the green allows (no flowing), or to have them overlap each other like a stupid.

     So:

    1) Which order should I actually render the <div> in?  blue, orange, green?  Green first?

    2) What CSS should I apply to make the green float like that.

    I'm sure it's simple and I'm 100% willing to chalk this up to "Lorne needs to learn much wow css".  Which is why I'm asking. =P



  • ♿ (Parody)

    Divs don't really behave like that... they can only be rectangles.

    Flow content (text, etc) can wrap  around floating divs.

     

     



  • Alex is right about divs, but you can technically do it: http://jsfiddle.net/tY22q/

    I put the green div inside the blue div and floated it to the right. So technically the blue div isn't being drawn like a fat L, but instead contains the green div. However, with some clever use of negative margins and a white border, it will look like the blue div "wraps" around the green div. In reality, everything under the green div would be blue, too, but the content of the blue div will wrap around the green div since it's floated, so the whole blue div appears to wrap.

    Now, go to the CSS for the #imgs div, and change the height from 80px to 400px and click "Run" in the top. You should get 5 images of lovely Aya Ueto and the orange div appears to wrap around the green div. Once again, it's the same trick, when the green div bursts out of the boundary of the blue div--like a chestburster rupturing-forth from someone's thoracic cavity--since it is floated it will overlap the orange div (hiding its orangeness) and will force the content of the orange div to flow around it.

    Caveats: This should work in all modern browsers, but I only tried it in Chrome. The content of the blue and orange divs must itself be capable of flowing for this to work. It's not really flowing the divs around the green div, it just looks that way.

    Hope that helps. Let me know if you have any questions.



  • Like this?

    You definitely want the floated one first.



  • @Lorne Kates said:

    What CSS should I apply to make the green float like that.
     

    There must be something really, really weird in your html/css, because you know about floating and yet putting float:right on the green div and going to lunch apparently doesn't make it go the way you want?



  • @morbiuswilters said:

    Alex is right about divs, but you can technically do it: http://jsfiddle.net/tY22q/
     

    BabyShitGreen isn't a color keyword, but MediumTurquoise is.

    Fuck the W3C.

    Also what's the reason you put the green in the blue, instead of putting it before the blue?



  • @dhromed said:

    Also what's the reason you put the green in the blue, instead of putting it before the blue?

    Because, shut up, that's why.

    It was just my first instinct, because it keeps the green div with the blue div.



  • @morbiuswilters said:

    because it keeps the green div with the blue div.
     

    You made an assumption, you foolish fool o'folly!



  • @dhromed said:

    @morbiuswilters said:

    because it keeps the green div with the blue div.
     

    You made an assumption, you foolish fool o'folly!

    You know what they say when you assume: Morbs stabs you in the eye with a cocktail fork.



  •  assert(doCocktailFork())


  • Trolleybus Mechanic

    @morbiuswilters said:

    Alex is right about divs, but you can technically do it: http://jsfiddle.net/tY22q/

    Hope that helps. Let me know if you have any questions.

     

    Yes!  That's what I was hoping to do. I can futz around with the faux-borders a bit, since I'm not sure yet if the BabyShitGreen box needs to be flush or not.  I had a feeling it was going to come down to forcing CSS to do something it's uncomfortable doing on film, but needs to the money for school.

    Thanks!



  • dhromed is right. This needs less fooling about with margins and whatnot than Morbs used, if you simply don't nest the green div inside the blue one.



  • @flabdablet said:

    dhromed is right. This needs less fooling about with margins and whatnot than Morbs used, if you simply don't nest the green div inside the blue one.

    And whatnot? It's just an extra line of css that deals with margins.

    Two nice benefits of keeping the floated div as child: 1) you can set the position of the green div relative to the blue div, instead of to the parent; and 2) if there are other divs in the same container, you don't have to worry about clearing the float: http://jsfiddle.net/tY22q/4/

    One downside to nesting the green inside the blue is that if the blue and orange divs are themselves floated (say left) then the blue div will just expand in height to contain the green div (booo!) Anyway, it seems like six-of-one, half-a-dozen-of-another.



  • The "whatnot" I had in mind was nesting things that the original spec doesn't make clear should be nested, but the main point is that I agree with dhromed: this looks like something CSS was actually built to do, rather than something you need to fool it into doing. It's not like you're doing something wild and wacky like trying to lay stuff out in a grid.



  • @flabdablet said:

    but the main point is that I agree with dhromed: this looks like something CSS was actually built to do, rather than something you need to fool it into doing.

    More-or-less, although the fact that the divs are still behind the floated div makes it not very well-thought-out. For example, let's say Lorne is like "Wow, those corners look a bit sharp. I'd like to round them off to give the UI a less stab-y, tetanus-y look" he would end up with this: http://jsfiddle.net/tY22q/5/

    @flabdablet said:

    It's not like you're doing something wild and wacky like trying to lay stuff out in a grid.

    Truer words have never been spoken. I used to get people yelling at me for using tables to build grid layouts, but there was no other way to do it in CSS back then.



  • @morbiuswilters said:

    @flabdablet said:
    but the main point is that I agree with dhromed: this looks like something CSS was actually built to do, rather than something you need to fool it into doing.

    More-or-less, although the fact that the divs are still behind the floated div makes it not very well-thought-out. For example, let's say Lorne is like "Wow, those corners look a bit sharp. I'd like to round them off to give the UI a less stab-y, tetanus-y look" he would end up with this: http://jsfiddle.net/tY22q/5/

    Same thing seems to work just fine without nested divs as well: http://jsfiddle.net/tY22q/8/



  • @morbiuswilters said:

    I used to get people yelling at me for using tables to build grid layouts, but there was no other way to do it in CSS back then.
    I have never understood the hate for using tables to build layouts that have what tables have (i.e. rows and columns). If you avoid tables and do it with divs and CSS, you end up having to put a div tag everywhere you'd otherwise have to put a table, tr or td tag anyway, and it's a fuckload harder to see how it all hangs together. Bla bla bla semantic tags bla bla bla, separation of content and presentation bla bla bla, go find something else to do you wanker I'm laying out a web page here; if you're so fired up about separating content and presentation how about you give me a half decent templating system to work with and stop pretending that HTML markup is somehow "content" in a way that CSS isn't.


  • Trolleybus Mechanic

    @flabdablet said:

    I have never understood the hate for using tables to build layouts that have what tables have (i.e. rows and columns).
     

    1) A table can't do what I illustrated above.

    2) Bad designers use tables for everything. Need to centre an item? Wrap the element with an entire table. Need to have 5px of space around the element? Wrap the element in a table with 9 cells in a 3x3 grid, with spacer gifs in the outer cells. Etc.

    3) Tables within tables within tables within tables.  This is a subset of #2, but even a "not bad" designer will do this. An outer table for the left/right gutter. A table with multiple rows and columns for the header. Another table with 3 columns for left/right/content. Tables within those-- like a table for the navigation hyperlinks with one tr/td for each.  Once you start getting more than 2 tables deep, your browser starts to choke. Because although a table will absofuckingloutely guarantee a column-layout, it takes a lot to figure out exactly how to render it.  And as soon as an element in the inner table renders, the outer table recalculates-- which re-renders the outer table, and then table wrapping that and the table wrapping that, etc.  The more nested, the more fucking horrible the performance.

    4) Shit maintenance. Go grab any codebase at least 10 years old, where the entire layout is table based. Try to add or remove a single <td> from an innermost control. Try to guess which code in the spaghetti mess renders the sibling <tr>, because you'll need to remove (or add) a <td>, or adjust the colspan from that (those) tr to or everything fucks massively.  Well, it'll fuck, but it won't be completely apparent why, or where.

    5) Even though tables guarantee a column-layout, that's it. If you use css to make a div 250px wide, it'll fucking be 250px wide. A <td> might be-- unless another column is set to a different width, or the screen is too big or too small, or the table does or doesn't have a fixed width or a percentage width. Or there's a long bit of text in that column. Or there's whitespace between the <tr> and <td>-- maybe, depending on which browser and which version you're using. And 250px width might be 250, or 248 or 252 depending on if your browser does or doesn't count the border. Or padding. Or cell spacing. Or the browser scrollbar.

    6) You can't do something neat like freezing the top "header" row on a table while the body scrolls.  Well, you can, but it won't work as soon as you put any real data in there. The table is a single,unbroken entity and fuck you if you want to do anything different. Which leads me to

    7) MOTHERFUCKING RESPONSIVE. Again, a table is amazing for column presentation, and that's it.  If you want to reflow so a two-column layout is instead a one column on a 400px wide screen?  Fuck you, buddy, you be squinting at tiny tiny text instead.

    A table is fine for presenting column data-- but just barely. It isn't predictable, consistent, or completely controllable. It'll basically do what you need it to do, but that's literally all it will do. You're stuck with that layout, and can never change it in any way for any reason.  And worse, it becomes a crutch for bad programmers to solve all their layout problems, and once that happens it's so deeply rooted in your system that any major design change will take at least a month just to find all the tables.  



  • All of that is hate for abusing tables, not merely using them. If what you actually need is a grid based layout that adapts itself to the page size, a table is going to be the simplest and cleanest way to achieve that - even if what you're presenting is not semantically tabular.

    Using tables for everything simply because you can't be arsed understanding the CSS box model is indeed stupid and wrong.


  • Trolleybus Mechanic

    @flabdablet said:

    All of that is hate for abusing tables, not merely using them.
     

    It's about 70/30.

    @flabdablet said:

    Using tables for everything simply because you can't be arsed understanding the CSS box model is indeed stupid and wrong.

    Yes.



  • @flabdablet said:

    Same thing seems to work just fine without nested divs as well: http://jsfiddle.net/tY22q/8/

    Huh? It works exactly the same..



  • I agree with flabdabie, your points are against using tables wrong. Now, you shouldn't use them for columns (just use floated divs or using css3.) But if you need a table or grid, then a table is your best bet.



  • @morbiuswilters said:

    @flabdablet said:
    Same thing seems to work just fine without nested divs as well: http://jsfiddle.net/tY22q/8/

    Huh? It works exactly the same..

    Right, so I'm still struggling to understand what nesting buys you.


  • Discourse touched me in a no-no place

    @flabdablet said:

    Right, so I'm still struggling to understand what nesting buys you.
    Little baby birds.



  • @flabdablet said:

    @morbiuswilters said:
    @flabdablet said:
    Same thing seems to work just fine without nested divs as well: http://jsfiddle.net/tY22q/8/

    Huh? It works exactly the same..

    Right, so I'm still struggling to understand what nesting buys you.

    As I already said, they're virtually identical, with slight differences in usage. There's no real "right" way to do it, although each way has its own benefits depending on the markup and css of the surrounding content..



  • @Lorne Kates said:

    Been banging my head around this one for a bit, and while I'm sure I can figure it out-- the punchline is "css".

    "CSS" should come with a trigger warning. I can laugh about it now though, it's been a while since my last urge to kill myself. Quitting my front-end job helped a lot.



  • @flabdablet said:

    All of that is hate for abusing tables, not merely using them. If what you actually need is a grid based layout that adapts itself to the page size, a table is going to be the simplest and cleanest way to achieve that - even if what you're presenting is not semantically tabular.

    Using tables for everything simply because you can't be arsed understanding the CSS box model is indeed stupid and wrong.

    There's the grid-property of CSS3 now, however. At least for IE10, that is. ;)


Log in to reply