I have found a very strange bug in my css layout.
I have a 3 x 3 products table. The styling is really simple, just 9 list items, styled as
display:block, float: left; width: 32%
Everything works perfectly across all modern browsers.
However, I have been experiencing a strange bug. Every now and then the 3x3 table breaks.
Here is the image:
List item 7 is the white watch, 8 is the blue watch and 9 is the golden watch.
Sometimes this appears between the 1st and 2nd rows, and sometimes it appears between the 2nd and 3rd rows. More so, sometimes everything loads fine, without the break.
I have reproduced this bug on Safari and Mozilla, so I'm guessing this is a gecko related bug. More so, this never happens when I F5 the page. So I get the feeling this happens when the browser starts pulling files from its cache.
Any ideas on what is going on here and how to fix this?
Safari is webkit I believe :).
Do you have a website where we can take a look at this? Even with the screenshot (which isn't approved yet, and doubtfully ever will. I never see attachments approved anymore), I doubt that'll be enough to help us recreate the problem.
At the very least we need the full HTML and CSS so we can recreate the problem ourselves :).
% widths are a headache and a half because they do weird out sometimes, though I'm hoping this:
display:block, float: left; width: 32%
... is a typo, since first, commas can't separate properties, and second there is no reason to ever say display:block on a float, since they are inherently so. The only reason to state display on a float is for :inline, and that's JUST to trip a rendering bug in IE that actually fixes the broken margin behavior -- where IE will stack or even double facing floats..
Though as Ryan said, we'd have to see the site in question to weigh in -- though it SOUNDS like you might have a fixed layout, which is accessibility rubbish, or a fluid layout in which case the floats will still expand to what's inside them, so if you have a image or single word longer than it wants to collapse, your floats will stack too big and bust onto the next line.
Honestly, I'd probably use inline-block, let natural spacing do it's job so it's NOT a fixed width table.... since fixed widths are broken inaccessible trash and a complete/miserable /fail/ at web design.
Though again -- wild guess pulling a conclusion out of my rump; would have to see the actual page and it's full code to say for sure.
I didn't notice that the attachment was pending approval, since I could see it from my account. Sorry about that.
The page in question is here: http://www.replicaster.com
There was a typo up in my first post. That comma is not present in the actual code. And I meant webkit. Sorry
I have changed the code right now to display:inline-block;width:32%
The trick was to also give the encapsulating UL a text-align:justify;width:100%
That got the table completely filling the fluid width layout.
However it does seem to break at small resolutions.
Just flag it if we've missed it.
By the looks of you screen shot, the boxes were snagging because of unequal heights. inline-block fixes that.
One of you columns drops in some browsers on narrow screens because of your padding. Mixing fixed-width padding with % widths is dangerous, because there's always the risk that the total width of the boxes will exceed the available container width as some screen sizes.
Oh, I see. So I should use % padding in a fluid table? Never occurred to me that this could be risky!
unfortunately no, because % on padding is based on font size, NOT element width.
Inline-block also has white-space between them, and since you shouldn't be using px metric fonts declaring % width can break when the font auto enlarges.
Which is why multiple % widths going across on content elements is usually rubbish. "Not viable web design" -- even though you see people TRYING to do it all the time (and why it's broken on my machine ALL the time!)
As to mixing width and padding, usually the solution is to margin or pad the child elements instead of padding the parent.
This topic is now closed. New replies are no longer allowed.