This may be a quick answer for one:
I typically use display: inline-block; to set a list of divs horizontally. But I noticed in IE7 it's a no go, the only way around it is using float: left; but I lose that relativity position, causing everything else afterwards to push upwards as if it were literally floating on top. So how can I a achieve the same display: inline-block;, so it doesn't "float" and works in IE7 and all the modern day goodness.
Thanks,
Try the techniques in this article. It may be more than you need for this particular application, but it should work:
http://blog.mozilla.com/webdev/2009/02/20/cross-browser-inline-block/
Related
i got a website here that i am building up HERE
the right arrow, in chrome, is LOW as you can see here
but when i debug it with the debugger and check float on/off, it comeback to the place it should be...
so the question is, what is the problem ? the CSS, the browser, the debugger the system (mac?) or HTML... if need your light !... thanks in advance
Yeah, it's not really intuitive, however, try one of two following, both of which will fix it for you:
Add float:left to .bx-wrapper, which then makes all the elements floating.
OR
move the "fg" div before the bx-wrapper div.
you need to clear the float
try adding
float: clear;
what is happening when you uncheck and then check is it is getting cleared out on it's own
or....
don't use floats and you can see why make them all
display: inline-block;
i'm going to get negative comments about that one, but seriously it's so much easier and more dependable . If the items that are all inline-block fit in the row then they will stay in the row
I have a site that can be seen at gronenproperties . com
I am using a div with an id "contact-add"
and absolute positioning it in the DIV where I want it to be.
Firefox shows it fine for the most part, but it shifts when i resize the window, and different browsers and OS's seem to place it somewhere else entirely.
I have been out of the game for awhile when it comes to css and making things cross compatible...In my research, it says to make the parent div relevant and should solve issue.
Pretty sure Ive done that.
If someone could teach me old tricks, but new trick to me.
Id greatly appreciate it
Thanks
Put everthing in a div with margin: 0 auto; and width: 960; or width: 1120;
I'm experimenting with ways to create a two-tiered multi-column form that looks balanced. My latest attempt involves enveloping each label/input in an li and having them float into place. The attempt is somewhat successful, but there is a dimension issue that I can't resolve.
The form is 600px wide and I made the lis 280px which would put the two columns roughly centered in the form. However, the effect is lopsided; everything is way too much to the left. It's like there is a huge margin of about 150px on the right hand side of the form - only there isn't.
In analyzing it, I noticed that the inputs are actually measuring at 175px. However, if I try to increase the width, it goes to a new line, so they are acting like they are 280px. But you will notice in the jsfiddle, the last li is extending to the full width - 600px. Therefore, it can't be a result of any fieldset formatting. Furthermore, if I change the float to 'right', the 150px fake-margin is still there. Firebug detects all margins and padding as normal.
I just don't get it.
I've tried renaming, applying additional classes, changing order of the li, removing attributes and adding other ones, and changing styling protocols... but usually I just make things worse. I would give up on the ol li concept altogether if any of my other techniques came as close to providing the display I am looking for.
What's causing that 150px right margin? And how do I get rid of it?
I need to understand this as the second part of the form is supposed to have two and three columns. So if lis cannot provide consistent widths, I have to try something else.
Here is the link: jsfiddle
[http://jsfiddle.net/9344a/]
Thank you in advance. (I've tried to clean it up, but the CSS/HTML may be a little bit messy as a result of trying different combinations. Let me know if anything is still difficult to understand.)
You can give
fieldset.partOne
{
text-align: center;
}
The problem was actually a compounding of errors.
First, the input size was incorrectly targeted through li when it should have been targeted directly.
Example: fieldset.partOne ol li { width:280px; padding:5px 0 } WRONG! fieldset.partOne ol li input { width:280px; padding:5px 0 } or simply fieldset.partOne input { width:280px; padding:5px 0 }
In addition, setting the width of the ol li to 100% (a misguided attempt to increase the size of the input) would obviously prevent the float.
The margin issue is caused by fieldset.partOne ol li { width:280px; padding:5px 0 }. Removing this width eliminates the fake margin. Not quite certain why, but the lesson is ol li works slightly differently within forms, so be aware of that.
My concept for this form was fairly odd, and I made several errors with both my HTML and CSS in trying to achieve the end result. So I went back to the beginning and rebuilt from scratch and was able to create a non-standard multi-column form that met my odd criteria, used only CSS, and worked across most browsers.
The Stackoverflow posts were invaluable in addressing all the little quirks that I came across, so I thought I'd return the favour and provide a jsfiddle that may help other newbies identify what they want and possibly how to get there.
I would have found something like this enormously helpful.
Issues addressed:
Aligning two and three column forms with various sized input elements.
{ol li} or {div}? {li} Not a good solution for non-standard formats. I had to use {li} for one section and {div} for another section to make the form work.
{select} sizing inconsistent. It usually has to be larger than your {input}
Keeping smaller {inputs} from floating into gaps.
Aligning odd shaped {input} and {label} fields.
Font sizes and styles reverting to browser default (reset not applying to HTML5?)
A non-resolved issue is FF top-aligning {select} data. There are many posts regarding this issue, but I have not found a good solution as of yet (one that targets only FF and does not affect other browsers). This is not a priority for me, but if it is for you, lots of advice is available. Do a search.
Here is link that displays the form and shows the code: http://jsfiddle.net/LAVJn/1/
Remember that this is written by a newbie, and you will certainly find many ways to improve upon it. But it does work and may be a good place to start or at least refine any questions you may have.
I don't think I am breaking any protocols doing this, but please let me know if that is not the case.
The layout in question is here: http://www.davedaranjo.com/media.html
This is probably an issue in standard positioning with css, but I've tried every positioning combination I can think of to achieve this:
http://i.imgur.com/y1qRU.jpg
Every time I try to move the player anywhere on the page, it positions itself at the bottom, even below the footer. I've even tried putting the content in a table with the links and video in the left td and the player in the right, but the player won't even sit in the table. I've also tried a number of positioning tags in the css file and at best, it will move if I give it a fixed position, but because the rest of the layout isn't fixed (and isn't on the rest of the site), that's not a viable solution.
I realize this is probably something fundamental that I'm missing here, but any suggestions would be extremely helpful.
Thank you!
Had a quick look at the source of that page and saw quite a few things i would change, so i will not go into detail but maybe this will get you started.
You could try floating your main div (look for <div align="center"> in your code) with css float: left; and also make your player inline-block like so;
.ttw-music-player { display: inline-block; }
I'm making more of an effort to separate my html structure from presentation, but sometimes when I look at the complexity of the hacks or workarounds to make things work cross-browser, I'm amazed at huge collective waste of productive hours that are put into this.
As I understand it, floats were never created for creating layouts, but because many layouts need a footer, that's how they're often being used. To clear the floats, you can add an empty div that clears both sides (div class="clear"). That is simple and works cross browser, but it adds "non-semantic" html rather than solving the presentation problem within the CSS.
I realize this, but after looking at all of the solutions with their benefits and drawbacks, it seems to make more sense to go with the empty div (predictable behavior across browsers), rather than create separate stylesheets, including various css hacks and workarounds, etc. which would also need to change as CSS evolves.
Is it o.k. to do this as long as you do understand what you're doing and why you're doing it? Or is it better to find the CSS workarounds, hacks and separate structure from presentation at all costs, even when the CSS presentation tools provided are not evolved to the point where they can handle such basic layout issues?
Clearfix is unnecessary most of the time, and the popular version of hack is needlessly verbose and complicated.
You can get clearing effect by applying overflow:hidden to the container. If container doesn't have fixed height, it will stretch to size of content anyway. It's not a hack, but specified behavior that works in all browsers.
And when you really need overflow:visible you can still clear without extra element in the markup:
.container::after {
content:""; /* not "."! */
display:block;
clear:both;
}
and that's perfectly standard CSS 2.1. In IE versions that don't support CSS 2.1, hasLayout happens to have desired effect:
.container {
zoom:1;
}
Yours is the right approach. Rules are created for those who do not understand them. If you know all pros and contras, make your own call.
You are particularly justified in this case. CSS decided to ignore common wish to separate content A from content B horizontally, so you have to choose a hack you dislike least. I compare the three solutions already presented here.
Your solution is bad because it changed content of the document, inserting element C whose only purpose is visual separation between A and B. Content should not serve layout purpose.
Karpie’s solution is slightly worse (in my book) because it does the same in a sly way. Pseudo element ":after" was not designed for that. It has a great advantage, however, of never actually changing the HTML.
PorneL’s solution achieves desired separation between A and B by radical change of properties of A. The change will not only separate A from B, but also separate A from preceding content, change the way width of A is calculated and so on. Of course, sometimes it’s perfectly OK, but you have to be aware of those unexpected side effects.
The choice is ours.
I definitely don't agree with the idea of using extra markup just to clear divs.
I favour the 'group' approach - putting class="group" on the parent div, with the following CSS:
/* Clear groups of floats by putting class="group" on their parent */
.group:after
{
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}
And in an IE-specific stylesheet for IE6/7:
/* IE7 */
.group
{
min-height: 1px;
}
/* IE6 */
* html .group
{
height: 1%;
}
This was detailed in CSS Mastery, by Andy Budd. It stretches semantics a little bit, but it makes sense - you're grouping together floated divs, which obviously have some relation to each other.
edit: I wouldn't consider this a huge hack or workaround either - the method has been around for years in various incarnations, (usually known as the 'clearfix' method), and I don't see it going away anytime soon.