In the following code a space shows up between the two divs under Firefox, Chromium, and Opera (all pretty much the latest versions). <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <style type="text/css"> .col1 { margin: 0; display: inline-block; background:#a31afe; width: 12.7em; } .col2 { margin: 0; display: inline-block; text-align: center; background:#a31aaa; width: 22.3em; } </style> </head> <body> <div class="col1"> User Set Values </div> <div class="col2"> Default Values in Here </div> </body> </html> Code (markup): If I make the div into float:left the space disappears. But I don't want floats just to get rid of the space. If I remove the new line after the ending "</div>" of class="col1" the space disappears too. But...I don't want to remove the newline and "break" my nicely formatted source code. Any suggestions as to how else to remove that little ol' space that appears? Thanks. Carlos
This code probably remove the gap between two div's .col1 { margin: 0; float:left; background:#a31afe; width: 12.7em; }
Display: inline-block makes things have block properties but act like inlines. Your space is from the inline side of things. Words have spaces between them, so browsers don't strip them out (though they do make whitespace more than one collapse down to one space character). So the spaces in your HTML code count as spaces between inlines. Setting them to float makes them totally blocks, and like all blocks the spaces are collapsed entirely. Say you had this: <span>foo</span> <span>foo</span><span>FOO</span> You'd get foo fooFOO If those were blocks you'd get foo foo FOO unless they were floats, where you'd get foofooFOO So you can either do something weird with negative word spacing in CSS, or remove the newlines (that's whitespace) in your HTML code, or just float them (why not? You get mostly the same effect floating them: you can give them heights and widths like blocks, but like inlines they shrink-wrap to content when you don't set a width... and you don't get the weirdness of inline-block in K-Meleon and other FF2 geckotard browsers).
Thanks! Whatever your name is that responded last. You explained that very well! Better than I have been able to find anywhere else on the net!! Cudos to you and thanks again for your explanation. I guess I will go back to using floats. The reason I got away from using them is that I am trying to keep my code as simple as possible without introducing more "advanced" things like floats and such. I am kinda in between the point of hating CSS with a passion and loving it. I am beginning to understand it but man oh man...what an absolutely royal pain it is to work with it. If everything was straightforward and consistent it wouldn't be so bad but even when the standards of CSS are consistent individual browsers may not be and even individual HTML elements are not treated as they should be. For example the INPUT html tag is considered inline. Which as an inline...it should not respect a width property setting. But it DOES! See what I mean? CSS has a bunch of gotcha's like that! I understand why they made an exemption (to prevent a bunch of forms from breaking that had been created with INPUT before CSS even came out) but my goodness! What a royal pain to figure all this out. Just yesterday I spend another hour or two trying to figure out why Firefox was showing a blue box around an image I had turned into a link whereas Chromium and Opera were not. The culprit? Firefox be default puts a border around images such that if they are turned into links the border shows up blue!! Nobody told me that. Firefox didn't tell me that. As usual I had to go around and try to figure it out by Googling. That's what I mean. CSS has all kinds of quirks and maybe's and possibly this and possibly that and yes but no except when it's this. I hate that about CSS! But I also love that it gives me power to change a whole site look and feel quickly. Anyway thanks for the input. You've helped me pin down another quirk about CSS this or that that I can add to my list of them. Hopefully at some point I can get past these quirks and gotcha's and get back to being productive! Carlos
Cause actually it's not a true inline, but is inline-block. That's also why inputs can haz vertical margins (another thing blocks tend to only get). It's dense, and weird, but you may get a heck of a lot more out of the specs than I did at first (it's not so bad for me nowadays): http://www.w3.org/TR/html4/ and css: http://www.w3.org/TR/CSS21/about.html and how to read them by TOmmy: http://www.autisticcuckoo.net/archive.php?id=2005/05/01/art-of-reading-dtd (seems he has a goof on his page but I assume it'll come back and that'll be a good URL) visual formatting model: http://www.w3.org/TR/CSS21/visuren.html
Actually SP, it depends on the browser. In IE, inputs are a 'special' type just like 'image' - they obey valign slightly differently... FF also does not treat them exactly like inline-block adding margin between them over which you have no control. Opera 9.x/earlier did treat them exactly as inline-block by default, but Opera 10 now styles them as chrome would, so that's been thrown right out the window though at least you can still rely on margins, padding, width and height to have semi-predictable behavior... ... and Safari, well... Let's not go there. I'm in pissy enough a mood with Dan's passing without starting that rant up again. The CSS and HTML specs are great, especially if you can comprehend them - but are ultimately a bit less than useful since a lot of elements are 'intentionally vague' in terms of what they look like... Meaning the browser makers all went their own directions when it comes to styling them. IE adds padding you have no control over and obeys line-height as the height of it, ignoring the height property. FF has 0.2em padding all around in addition to whatever you set in the CSS, Opera and chrome apply no extra padding/margins, and safari throws away 90% of the CSS you throw at form elements in it.
Yeah I noticed... something to do with when they tried to fix that floated anything inside a fieldset can't clear in 1.5 or something? Now that I read a few Operadevs' blogs I notice more and more Opera switching to Mozilla habits (sometimes bugs) just to comply with majority behaviour in things. : ( Yeah I have major trouble in the comprehending part... one thing that still gets me is while I can look up an element and see who can be inside it, I can't just see right there what kind of element it is (block, inline), so I end up testing in browsers. Which comes back to the problem of, they don't always agree with each other. That coupled with Mozilla's "if the specs are undefined we will leave the bugs and call them "'conforming'".
Nothing that complex - it styles them 100% like how Netscape 4 did. It's why before FF 3.x dropped I used to call all Mozilla based browsers "Netscape 4's sweetly retarded cousins" - Oh, but Gecko was a clean break from the Netscape 4 codebase... Sure it was... That's why I still use the decade old WDG HTML4 reference page... Why not, the specification hasn't changed since 1999, so who needs it updated? http://htmlhelp.com/reference/html40/ It really does take a lot of what the specification says and turns it into plain english. AND they grey out deprecated tags on the two organized lists, and say right there on each tag's page what attributes are valid, it's "level", what it can contain, and what can contain it. They often include CSS styling examples and advice, the text often incorporates advice that ended up in the later WCAG, and sometimes even extra suggestions on how to use it. ... AND Liam offers downloadable versions too. Pretty damned impressive, complete and handy for something not updated since 2003. (I use the download copy, but change the "transitional" class to text-decoration:line-through; )
Yeah...you all have pointed to exactly why CSS is such an incredible pain (compared to something like PHP programming for example which is much more cut and dried). It's not just that the specs themselves are at times unclear and somewhat nebulous in some respects but more importantly from the standpoint of just making a page render well and appear well while using CSS to control it's appearance...you don't know what the appearance is going to be like until you spend the time it takes to strain out what you had in your mind's eye on to the web page you are working on. One keeps bumping into invisible quirks. Quirks that are unseen such as the amount of margin put around elements invisibly by each browser. It's not something that is in your face. Inconsistencies in the standards and other such things. You only know that the margins are off in some browsers and not in others or they look good one day, you add a new element, and it gets all messed up again. It's having to discover and search for solutions and get past these invisible quirks that are not explicitly addressed in the standards that is such a pain. Oh well...such is life on the web. I have no choice about it. It just is and I either accept it and move on as best I can or give up web development as a career choice which is not an option for me as I want to make a living over the internet and absolutely need the flexibility that being able to create web sites gives me. Thanks again for your all's input. Much appreciated. Carlos