If it was me, I’d just say to use the CSS-compliant version that does work (from my post #2 above, which I just re-verified again). If anyone complains, chide them into getting a standards-compliant browser. 
Your code from before aligns all the boxes vertically (rather than horizontally) in Windows Firefox 1.0.
That could just mean that Firefox has a bug, too.
http://www.webmasterworld.com/forum83/1729.htm
This link says that your problem is that you can’t specify the width of an inline element. That’s why your boxes are so goofy in Firefox in the first post. I haven’t gotten the list suggestion in the link to do what you want, but you may have more luck with it. (I need to go home 
)
inline-block? What the hell is that? No wonder it doesn’t work.
Okay, I see… that’s something from CSS2.1. I bet it wouldn’t pass the w3c checker at this point. So one day it will be standard, but then so will border images in CSS3 (can’t wait).
Ok, so given that there apparently exists no such browser, what would you suggest?
dlack, you can specify the width of an IMG, and that’s an inline element.
As to why I’d want to do this, well, I guess I have no good excuse, other than that’s the design I have in mind. I like the 3-across look, but I hate pages that make you scroll to the right if your window isn’t wide enough. Maybe I could force the DIVs to be a particular size by sticking a dummy image in them. No time to play with it at the moment.
Be that as it may, the reason the page in the OP looks messed up in Firefox is that the text is filling the width of the page and the divs are expanding for the text. Your width specification is being ignored.
I am interested in this problem, though. It would be nice to see a good solution.
Had a chance to do a little checking into it.
The trouble lies in the philosphical question: “What does CSS support mean?”
I don’t know Firefox’s specific claims in this area, but when any browser claims compliance with CSS, you need to ask “Yes, but which version?”
IE is fairly compliant with the CSS, Level 1 Recommendation, which is fairly rudimentary.
Hot on its heels, the W3C came out with CSS, Level 2, before most browser developers even knew what had hit them with CSS1. CSS2, among a vast aray of advancements, added the behavior you seek, by including “inline-block” as a possible value for the “display” property. An inline-block should act like an image, flowing with the text that surrounds it, but maintaining a block shape and breaking in its entirety to a new line on a window-resize.
However, the browser developers howled in protest at the drastic increase in features that CSS2 demanded. That is, they would have howled in protest if they had bothered to pay much mind to the new standard at all. To say the support for CSS2 among the major-release browsers is piecemeal is putting it mildly. I don’t even think the W3C’s own browser, Amaya, supports all of it. Some browsers support some new features, others support a differest subset, and it’s a mess in general. The W3C’s CSS Homepage doesn’t even link to to CSS2 anymore, even though it’s a full Recommendation, so chagrined are they by the fallout.
In a rare display of caving in to the real world, the W3C announced a two-prong approach:
Firstly, CSS3 will be modularized. All aspects of the language will be broken up into bite-sized chunks, and if a browser wants to say that they support a particular module, they have to support all valid values of all properties in the module. The various modules are working their way through the W3C’s Recommendation-development process, and almost all are behind their announced schedule.
Secondly, in the meantime, the W3C is working on the CSS Level 2, Revision 1 (CSS2.1) Recommendation, which is a reduced set of CSS2, and mostly contains the CSS2 stuff most of the browsers already support. Your “inline-block” value is there as of this time. Unfortunately, CSS2.1 just barely reached Candidate Recommendation" status a year ago.
From the CSS2.1 Technical Report:
A Proposed Recommendation sits around, possibly but not usually gathering minor tweaks until Tim Berners-Lee gets around to signing off on it.
More:
So most browsers aren’t saying they support CSS2 (although some say they support CSS and hope you think it means CSS2), and since CSS2.1 isn’t yet a complete standard, no one’s in a rush to make their browser compliant with it.
At this stage of the game, I’d say the “inline-block” value of the “display” property is unlikely to be removed, but you never know. I think it will remain, since browsers already do images correctly, so it shouldn’t be too much of a stretch.
So what you have on your hands, galt, is a workaround hack for the lack of support for the “inline-block” value. Unfortunately, it only works in IE.
I have a couple of really really really ugly ideas for a cross-browser workaround (that I don’t have time to experiment with), that may tide you over until CSS2.1 or CSS3: Box Model become Recommendations and gain widespread browser support (shouldn’t be more than five years from now).
- Use Paint or somesuch to create an image of the text you want.
- Keep your non-standards-compliant div-inside-p elements, decide how you want the text to lay out in each block. Where line breaks should occur, insert the standard <br /> tag. Where spaces are, replace them with the entity, which will create a non-breaking space between the words.
Yes, both of these option suck royally.
The “inline-block” doesn’t work in IExplorer or FireFox, and I’ve not tried Safari. But for the record, “inline-block” is new in recommendation 2.1. Here’s the [url=http://www.w3.org/TR/CSS2/visuren.html#display-prop]2.0 version without inline-block*.
So everyone can stop harping on my use of DIV inside P, I created a new version of the page which doesn’t do that.
Anyway, the question remains unanswered, other than basically, “you can’t do that with CSS.” Very disappointing. As long as there is layout you can do with tables but not with CSS, tables seem to be a necessary evil.
As an aside, one thing I really don’t get about Firefox’s behavior with respect to these inline divs is how they wrap over themselves on successive lines, and they obscure the content immediately following them in the document. Surely, the upper and lower margins and padding should prevent stuff from automatically being positioned so close, right? I’m having a hard time imagining a scenario where the exhibited behavior is desirable.
How can you get the wrapping behavior you want using tables?
Have you considered using DHTML (an ugly hack, I know)? I haven’t tried this, but presumably you can get the results you want with a few dynamically-sized spacers (in floating elements like in my first example).
It all comes down to the difference between inline and block elements. Here (the same page I linked before) is a description of how element dimensions are to be computed (in CSS2; but this seems to be what Mozilla is doing in this case). For “inline, non-replaced” elements (which is what your class=boxybox DIVs are) the computed height depends only on the line-height property, and not on the margins or padding.
You are correct. I misread “inline-table” as “inline-block” in the properties index of CSS2.
Even more of an explanation, therefore, why the browsers don’t support it yet.
Yet.
Oh, and to answer your other question, DHTML is not an option, as far as I’m concerned. The last thing I want is for people to have trouble viewing my page because they have javascript turned off, and I certainly don’t think my page is important enough to demand that people turn it on for me.
Hmm. After seeing your other examples I didn’t expect that to work…
You know, relatively speaking, your use of tables is not as evil as you might think. Semantically it’s not really correct, but in practice you’re keeping with the spirit of not using tables for layout. You’re using the tables in place of individual DIV’s, and you’re not defining an entire page layout with tables. I’d say that if this is all you’re doing, then you can run with it.
As an option, you maybe could conceivably use the display property using inline-table, table-row-group, table-column, table-column-group and so on to make DIV’s the behave like tables. Then strictly speaking you’d have no tables, just some semantically incorrect DIV’s, which isn’t that great a sin, relatively speaking. Using nested selectors you won’t even really have to specifically set parameters in your HTML. Check out http://www.redmelon.net/tstme/4corners/ – this shows how to define automatically nesting DIV’s, you’ll still have to play with the display properties to make them behave like table elements.
Not doubting you, I’m honestly curious here … what’s semantically incorrect about it? I’ve been thinking of “DIV” as a “generic container” in that it can go most anywhere and that pretty much anything can go inside it. In other words, it’s just a logical grouping object. Your statement and others made in this thread make me think that my understanding may be incorrect. Is it?
I have never read the spec end-to-end, but I do use it as a reference, and I’m afraid it really doesn’t offer much help as to “here’s what this object is intended to be used for” in most cases.
Lessee, we got:
<!ELEMENT DIV - - (%flow;)* – generic language/style container →
<!ELEMENT (TH|TD) - O (%flow;)* – table header cell, table data cell–>
<!ENTITY % flow “%block; | %inline;”>
<!ENTITY % block
“P | %heading; | %list; | %preformatted; | DL | DIV | CENTER |
NOSCRIPT | NOFRAMES | BLOCKQUOTE | FORM | ISINDEX | HR |
TABLE | FIELDSET | ADDRESS”>
TABLE is part of the block entity, which is part of the flow entity, which is valid content for a DIV element.
Similarly, DIV is part of block, which is part of flow, which valid content for aTD element.
So it’s Kosher in HTML 4 Transitional.
Whoops: pardon the winkies, those are semicolons followed by rh parentheses.
(Preview is your friend… :smack: )