?

Log in

No account? Create an account
 
 
30 April 2007 @ 02:30 am
Fixing image overlap problem?  
I haven't touched Flexible Squares in so long that I don't remember if anyone has brought this up before, but have we ever tried playing with overflow: auto on various elements? I've provided working example with links. I know you guys can code it up yourselves, but this is easier ;).

By default, I've forced the entries to be scrunched together to force the overlap. To remove that code (.separator, .clear {height: 0px; }), just click on the "noscrunch" links.

  1. Apply it to .subcontent

    This is mostly useful for when there are a bunch of short entries all in a row, which causes a cascading userpics effect. It's also a partial fix for floated images -- at least the floated image won't overlap the next entry, though will still intersect with the comment bar.

  2. Apply it to .subcontent and .comments

    This behaves the same as the previous, but the comments bar no longer lies over floated elements.
    Advantage: floated images aren't obscured by the comments bar
    Disadvantage: makes the comment bar move away from the floated userpic div (remember what IE users see when the userpics overlap the comment bar?)

    Applying overflow: auto to .entry_text is good for both floated images, and the userpic overlapping in short entries, but also prevents the entry text from wrapping around the userpic


  3. Apply it to entry_text

    Better results for tall images in entries, but doesn't help with the stacked overlapping userpics when there's a series of short entries



Best thing with this is that it should stop floats from one entry from affecting the next one *without* needing to use clears, which causes problems with the sidebar.

I've only tested it in Firefox 2.0.0.3 -- would love it if someone else could test in other browsers with other blah. Can anyone test to see if either causes any problems? Might eventually post this to s2flexisquares where I can get more eyes on it, but for now -- any thoughts? :D

ETA:
I spoke too soon. overflow: auto on subcontent causes a scrollbar when there's wide content. So it fixes one thing but changes the behavior of another.

ETA 2:
I vaguely remember discussing overflow with someone else before, but that was in the context of figuring out what to do with wide content, and not with overlapping due to floats.

ETA 3: Table of behavior in Firefox 2.0.0.3
  normal entry length series of short entries tall floating image wide floating image
normal entry wraps around userpic

no real problems
userpics stack indentation overlaps next entry extends to the side
no sidebar
^noscrunch same as scrunched no real problem same as scrunched same as scrunched
subcontent entry wraps around userpic

no real problems
userpic float doesn't affect next entry image doesn't affect next entry

commentbar overlaps image
scrollbar appears

commentbar overlaps image
^noscrunch same as scrunched
subcontent + comments entry wraps around userpic

no real problems
userpic float doesn't affect next entry

weird commentbar when userpic float overlaps it
image doesn't affect next entry

commentbar doesn't overlap image
scrollbar around entry contents + commentbar

commentbar overlaps image
^noscrunch same as scrunched
entry_text entry doesn't wrap around userpic userpics stack indentation image doesn't affect next entry

BUT this entry doesn't wrap around userpic
scrollbar around entry contents
^noscrunch same as scrunched


ETA 4:
Added another two methods, contributed by murklins :) These solve a bunch of problems with the comment bar, but do require that the entry background be the same as the subcontent or maincontent background. These two aren't in the table. Just check out the working example.
 
 
 
Snakelingsnakeling on April 29th, 2007 08:15 pm (UTC)
Have tested on Opera 9.20 and Konqueror 3.5.6 running on Ubuntu 7.04. It all behaves as it should, which does not surprise me.

As for the scrollbar on wide content, isn't there a way to apply overflow to only the x or y axis?
Snakelingsnakeling on April 29th, 2007 08:19 pm (UTC)
isn't there a way to apply overflow to only the x or y axis?
Could have sworn it existed, but I can't find it in the CSS2.1 specs. Hmm.
shiny happy glowyafuna on April 29th, 2007 08:23 pm (UTC)
It's in CSS3 specs. I think IE supports it. Supposedly Mozilla does as well, but that's just something I heard someone mention; haven't checked myself.
shiny happy glowyafuna on April 29th, 2007 08:21 pm (UTC)
I tried using overflow-y, but it didn't seem to make a difference. Try testing it on your own, maybe?
shiny happy glowyafuna on April 29th, 2007 08:34 pm (UTC)
Ooh, could you test again? I added a tall image this time, and it's behaving differently from the wide one. No scrollbars, for one thing.
murklinsmurklins on April 29th, 2007 08:27 pm (UTC)
I'm pretty sure you used murfuna for exactly its intended purpose: dummy posts. We are dumb, remember? :)

I know I'm tragically out of the loop, but what was the problem with using min-height (and a hidden-by-hacks height for IE) for the short entry problem?

I'm surprised overflow works like that on those floats, actually. CSS confuses me so.

shiny happy glowyafuna on April 29th, 2007 08:29 pm (UTC)
min-height can help alleviate the problem, but some people don't like the extra whitespace (when it's unnecessary), and it doesn't help with floated images.

It's deliberate behavior, I think. Check my del ;)
murklinsmurklins on April 29th, 2007 08:57 pm (UTC)
Yes, and to those people I say pffft. Especially the ones who go out of their way to float images in their posts. :)

Huh. Interesting. But still strange to me, since floats are so stubbornly *not* contained that way any other time. But, getting over that, I think the only way to solve teh scrollbar problem is to make it a clipped content problem, by maybe putting another div within the subcontent div and making it overflow:hidden. This should clip the wide image and prevent the scrollbar, maybe? But then, people probably wouldn't like that either. Possibly they'd like it even less.

Oh, and with .subcontent { overflow: auto; } on the wide but short image, I get the comment bar becoming really long and obscuring the image. This is in FF 2.0.0.3. Adding overflow auto to the .comments div does not help -- it shrinks the comments div down, but adds a vertical scrollbar and moves the comments div to the far right of the image, and then cuts the div off so I can only see a few letters.
murklinsmurklins on April 29th, 2007 09:04 pm (UTC)
Or, just overflow: hidden instead of auto on subcontent to avoid the scrollbar. :) (I really am dumb.)
shiny happy glowyafuna on April 29th, 2007 09:05 pm (UTC)
Yeah, the stuff here helps with the tall content, but not the wide content. In fact, it makes wide content even *worse* ugh.

Hm, I think that I should have made the noscrunch versions the default (normal-unscrunched is actually what unmodified FS looks like).

Anyway, there seems to have been less problems lately with overlapping userpics, since most of the time there's a decent height for the separator/clear divs. I could be wrong though -- I don't monitor the community as much as I used to.

The main problem I'm trying to solve here, actually, is tall floated images overlapping the next entry. It's annoying that the fix for tall images causes problems for wide ones!

PS. overflow: hidden will help with tall floats in the same way that overflow: auto does, but I sort of hate the idea of cutting off the content, especially since it wasn't built into the layout from the beginning. I know that some layouts use it as well, but the behavior was there from the beginning, not added in suddenly.
murklinsmurklins on April 29th, 2007 09:18 pm (UTC)
Okay, hmm, I'm so glad I left all this behind me. Except I'm now thinking about it so YOU WIN. Or whatever.

The overflow only seems to work to enclose the tall floats if it's applied directly to the immediate float's parent, so entry_text, right? So that's kind of useless if you like the text to wrap, dammit.

So did we ever look at floating all the divs in there? Since floats will enclose floats? Thsi is crazy talk, isn't it?

Ahahahah, it's the middle of the day but I feel like I'm drunk or something! (Which I am not, btw. Maybe later.)
shiny happy glowyafuna on April 29th, 2007 09:26 pm (UTC)
I think we did, but I don't remember what happened to that. You want to test it? :D

(I'm working on creating a table of behavior now)
murklinsmurklins on April 29th, 2007 10:36 pm (UTC)
I think you've gone insane with all the bumming around and being awake until 5am.

Do I want to make everything float? Um, NO. But I might anyway. Later. :)

First, it appears that I need to pay the taxman. Or, file some forms so that the money I already paid can be verified or something.
shiny happy glowyafuna on April 29th, 2007 10:39 pm (UTC)
*peeks at clock* Actually, it's 7am (but who's counting?) and I need to sleep.

Pshaw, taxman, maxman. (So that's why you're not online. Have fun! )
murklinsmurklins on April 30th, 2007 10:26 pm (UTC)
(Was not fun. But done now, at least.)

I think Expressive handles all the images fine - my friends page suffered no problems from the tall floats. Is there something from that layout we can adapt?
shiny happy glowyafuna on May 2nd, 2007 03:48 pm (UTC)
We've already talked about this, but leaving a comment for the sake of anyone else who stumbles upon this:

Expressive solves this problem by making the entry section a float, but that won't work for flexible squares as it is right now because you have to set a width for maincontent. Also, floating entries-related divs stuff looks really funky when I tested without modifying anything else (might be a way to make this work, but haven't found any as of right now).
shiny happy glowyafuna on April 29th, 2007 08:34 pm (UTC)
By "it" I meant overflow.