Anyone know why these <li> tags that contain the thumbnail pictures are not stacking up appropriately?
This is blowing my mind away.
http://hqinternetsolutions.com/Websites/NuPhase/index.php?id=4
All the floats, are right, and there's enough width.
Update
I'm using Firefox 6.0
There's nothing strange here - the behaviour is expected.
Most of your lis have a computed height of 58px. However, some of them are slightly different, for example 64px or 57px. The reason for this is that some of the images are a different height.
The best fix is to simply make all the images the same height.
Related
I have a really weird issue thats seen in Safari and Chrome. Somehow it works just fine in Firefox.
Look at this URL in one of the above browsers: https://musik.dk/therollingstones/videoer
If you scroll down, you'll notice a videothumb that floats very different than the rest. The "sinner" is the video starting with the name "Arrive in Japan" thats just a single pixel height than the rest.
I've looked into the inspector, but everything is exact as heigh and wide as all others (its the same template) and the image is 100% the same height and width. It could be a render issue, but its the same video all the time.
Can anyone figure that out?
Screenshot:
The floated article in question is "snagging" on the article to the left above it, which is slightly taller than the others. That's the problem with floating.
My advice would be to remove all of the float: left; declarations (there are two for desktop and various instances within media queries as well) and use display: inline-block instead, perhaps with a reduced right margin of, say, 0.5% (although these get a bit inaccurate).
Instead of right margins, you could apply text-align: justify to the container of all those articles. That will only mess up the last row if there aren't 4 articles, but that's fixable, too.
Or you could use flexbox, which is the modern way to do this, though not fully supported across the board yet.
The reason is due to that video having japanese characters in the name. For whatever reason, they render slightly larger, making the .ellipsis box 1px larger.
As mentioned by ralph.m I would make then display:inline-block; and remove the float, then set margin-right: 23.8%;
If you were to look at the following website in Chrome, you would see the printers in 2 rows. Which is how it is supposed to be. But in FireFox and Internet Explorer the 4th product is aligned on the right by itself.
I have tried everything I can think of, and scoured the web. I would really welcome any help anybody can give me regarding this issue.
http://www.thewideformatgroup.co.uk/Products/general-office-use
Change float: left to display: inline-block on the items (.shop-main li, to be exact).
If you float items to do this, then the height of the items needs to be exactly the same. In this case, the items are rendered in such a fashion that the 3rd item is slightly less high than the second. That is causing the fourth item to float next to the second as well.
If a bit exaggerated, it looks like this. Notice how 3 is slightly less high, causing 4 to be stuck behind 2 as well.
This might be caused by a weird scaling of the product image, for instance, or by any other rounding difference. Also, it might look good at first, but change as soon as a user starts zooming in or out, or messes with their font settings.
By using inline-block, you basically create a long text-line of items, that will wrap as soon as the line is full. It is a better approach when you want a wrapping list of items like this, because you won't at all be affected by the rounding problems I mentioned above.
Now, you might be tempted to solve this rounding issue so every block is the same size. And you might do that as well, because it might look a bit weird when the red line that appears on hover is shifted a pixel or so. But start by using inline-block, so you prevent incorrect wrapping, so even if some unpredictable rounding errors occur, they surface only in detail and won't mess up your entire page.
Have you tried to make the elements float or give them a relative positioning? The way i'm seeing it is that they inherit their positions from the parent div but on ie and firefox it's rendered differently.
I've had this problem and the solution for me was to make everything float left and give it margins and clearing as needed, the end-result was that it had a certain margin from the top so the elements always remained at a certain distance from the top and each other while maintaining their position
Try adding height to the .inner class:
.shop-product-small .inner {
border-bottom: 3px solid #FFFFFF;
height: 140px;
}
I've had quite a few problems with IE6 and our website.
http://www.sweetlets.com/w/solutions/click-stream/features/
At the very top the teaser boxes have scrollbars in IE6, but not IE7, IE8, FF or Chrome. Does anyone have an explanation for this?
Same effect in the footer with the 3 boxes in one row. Also scrollbars. Mathematically all fits into the row of 960px. I added up paddings, margins, borders and width and even kept some pixels left...
I simply don't know what is wrong. Any ideas?
Not sure if it'll fix it but I'd put a clear: both on #cf_content and remove overflow on the following:
#main
#content
#cf_content
#cf_content_teaser
You can set overflow:hidden; on the #cf_content_teaser to get rid of the scrollbars. Dunno if it's worth investigating further if that resolves the issue. You can apply the same to whatever other div it's happening on.
I've got three columns inside of a div that is the full page width. The two on either side are 25% width and the one in the center is 50% width. This layout is working fine except in IE6 where at certain page widths it bumps the right column to the next line. Is there a fix for this? Maybe an alternate way to layout a page like this?
Edit: I'm using a cross browser inline-block hack that works great in FF, IE, S, Chrome. I'm pretty sure this quirk has to do with the way IE calculates widths on fluid content, and happens due to miscalculation (rounding maybe?). I've put up an example here. Try slowly adjusting the window width in IE6 (maybe later versions too) and watch as the green DIV gets bumped down at certain widths.
Thanks,
Brendan
It's a rounding problem in IE6's box model. Generally, you can't have a combination equal 100%. Try making your values sum to 99% of total width, and it should work fine. This solution has always worked for me.
It sounds like a piece of content in that column might have a defined width which is more than what the 25% of page width it is given. Can you provide CSS examples?
EDIT: IE6 does not support inline-block which could also be the issue.
EDIT 2: I looked at it on a 1680x1050 screen in IE6 in a virtual machine. When I drag the width slowly over time from about 800px to 1600px, it randomly moves the right column around. I suspect it's an issue with the hack that you're trying to use. Your code is so simple that I think you should consider researching an alternate hack instead. I've also never seen the *<property>: <value> hack. What's the * do, all compliant browsers?
Say I have textboxes, dropdownlists and submit buttons. They are all inline-elements. Which means that "officially" margin, padding, width and height properties should be ignored (in practice not really). If I were to go the right way to set the height to a button I would write something like display:block and then define the height. But there are considerations that a block level element would expand itself unexpectedly so I'd better set its width to some fixed value. The problem is that I don't know its width since it can be dynamically defined upon the text of the button.
Another scenario: I wish to create a menu via <ul> and <li>. I want to have it horizontally aligned, with some items grouped to the left, and with a few stretched to the right. Both <ul> and <li> are block-level elements. Since I wish my menu to take all available horizontal space, then to play with the items height and to have menu items pushed to both sides, the block-mode is fine to me. I'll just use float:left and float:right to achieve the task. But again use should kinda set a width to menu elements, since they are block elements. I do not know their widths because the text of the items can vary. But it seems that everything is rendered just fine as it is.
I have not noticed any issues with both inline elements forced to render as block elements without being floated or width set, or with the list item example. It works just fine in IE7, FF3, Opera 9 and Safari whatever the current version is. The question remains: should I worry about these inline-to-block elements or real block elements floated but without the width set or just leave everything as it is? Am I missing something or is it just one more of those things you simply should not expect to get right?
Say I have textboxes, dropdownlists
and submit buttons. They are all
inline-elements. Which means that
"officially" margin, padding, width
and height properties should be
ignored (in practice not really). If I
were to go the right way to set the
height to a button I would write
something like display:block and then
define the height. But there are
considerations that a block level
element would expand itself
unexpectedly so I'd better set its
width to some fixed value. The problem
is that I don't know its width since
it can be dynamically defined upon the
text of the button.
Unless you're referring to Internet Explorer's box model quirks, you shouldn't be worried about anything expanding or contracting unexpectedly. As long as you take care of normalizing for browser variation, you will be fine. If you have an unexpected and unwanted side-effect along the way to design glory, you debug it, as that is programmer error you contend with. CSS can be quirky, but that is not an appropriate excuse 95% of the time for most major browsers. The other 5% we don't talk about.
This is how I understand your problem:
You want a menu of floated <li> so that you have a horizontal menu that spans the width of the viewport (what your user sees 'in the browser window') to be consistently the full width of the viewport.
It sounds like you are thinking in terms of a fixed width design, when really what sounds like it would suit your purposes is a fluid-width design. This means you create a design that is 'elastic' and expands and contracts relative to the size of the user's browser window. If you created your design anticipating pixel widths being set on each element, you can probably find an elegant way to maintain a fluid-width header and navigation, but have a fixed-width main content area. You can find a happy medium without a full redesign. This walkthrough will likely be what you're looking for. A good explanation of the terms fixed-width and fluid-width can be found here if you're unfamiliar with the jargon and want a closer look at these ideas.
One more for the road:
Setting a width on all floated elements is not only recommended, but is a part of the CSS2 standard as per W3C.
Angelina
You're getting yourself a bit over stressed I think :)
Check out these links, especially 9.4, 9.5 and 10.3. And ctrl-f "inline-block"
If we take the "Official" line that you mention then life is easy as we don't need to worry about widths, heights and on for these elements.
Don't think pixel perfect, don't worry about the minutia of presentation, follow the standards, allow the browser & its users to define styles...
(if only it was really that straight-forward in the "un-Offical" real-world)
Ok, I suppose my question was not understood correctly.
What will happen if i do not set width for floated boxes? I can't set it, I don;t know it. because it depends on the content. Will all boxes just shrink to their content width? This is how it's working in practice. And i'm satisfied with it. Is there any official confirmation that this behaviour should be expected?
Added:
I foudn something interesting here: http://www.webmasterworld.com/css/3811603.htm
I suggest checking the recommendations for a more technical explanantion for the differences, but simply put, the behaviour of floats changed between css2(1998) and css2.1(a couple months of 2005, and then 2007). Per css2 it was mandatory to set a width on floats, while the "shrink-wrapping" you see in ff3 is css2.1. That means pre-Jul/2007 browsers are conforming to the recommendation relevant to their time of manufacture when they stretch div#container the full viewport width. (Which doesn't explain Opera, but it always has done its own thing.)
If so, then i'm contended. As I mentioned, it works in current IE7, FF3, Opera 9 and Safari.
Any more comments?
(assuming if i understand you problem)
In most cases you don't need to set width on list items.
But (yes, there is a but here) if you have a link with display:block (let say you want to use sliding door) you have to do a little trick:
the html:
<ul class="menu">
<li>Link</li>
<li>Link</li>
<li>Link</li>
</ul>
And CSS:
.menu li {
float:left
}
.menu li a {
display:block;
}
/* ===================== */
/* = and the IE6 trick = */
/* ===================== */
* html .menu li a {
width:1%;
white-space:nowrap;
}
If you don't do like this, then the LINK will be stretched to all parent. The LINK not the LIST Element ;) Doing this way you set a "min-width" to IE6 and you won't have any other problems.