# Question from a CSS dummy

**URL:** <https://boards.straightdope.com/t/question-from-a-css-dummy/292401>\
**Category:** Factual Questions\
**Created:** [March 1, 2005, 6:33am UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401 "2005-03-01T06:33:36Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![rjung](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rjung](https://boards.straightdope.com/u/rjung)\
**Post date:** [March 3, 2005, 7:23am UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/21 "2005-03-03T07:23:46Z")

</div>

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. 😉

---

<div class="post-metadata">

**Author:** ![dlack](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dlack](https://boards.straightdope.com/u/dlack)\
**Post date:** [March 3, 2005, 1:02pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/22 "2005-03-03T13:02:33Z")

</div>

> [@rjung](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![rjung](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@rjung](https://boards.straightdope.com/u/rjung)\
**Post date:** [March 3, 2005, 9:20pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/23 "2005-03-03T21:20:41Z")

</div>

> [@dlack](#):
>
> 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://gudbrand.no/start/bugs/inline-block.html)

---

<div class="post-metadata">

**Author:** ![dlack](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dlack](https://boards.straightdope.com/u/dlack)\
**Post date:** [March 3, 2005, 10:20pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/24 "2005-03-03T22:20:16Z")

</div>

[http://www.webmasterworld.com/forum83/1729.htm](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 🙂 )

---

<div class="post-metadata">

**Author:** ![Balthisar](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/balthisar/32/2825_2.png) [@Balthisar](https://boards.straightdope.com/u/Balthisar)\
**Post date:** [March 4, 2005, 12:00am UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/25 "2005-03-04T00:00:16Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![galt](https://avatars.discourse-cdn.com/v4/letter/g/35a633/32.png) [@galt](https://boards.straightdope.com/u/galt)\
**Post date:** [March 4, 2005, 1:03am UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/26 "2005-03-04T01:03:54Z")

</div>

> [@rjung](#):
>
> 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. 😉

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.

---

<div class="post-metadata">

**Author:** ![dlack](https://avatars.discourse-cdn.com/v4/letter/d/b5ac83/32.png) [@dlack](https://boards.straightdope.com/u/dlack)\
**Post date:** [March 4, 2005, 3:32pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/27 "2005-03-04T15:32:11Z")

</div>

> [@galt](#):
>
> **dlack** , you can specify the width of an IMG, and that’s an inline element.

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.

---

<div class="post-metadata">

**Author:** ![scotandrsn](https://avatars.discourse-cdn.com/v4/letter/s/a4c791/32.png) [@scotandrsn](https://boards.straightdope.com/u/scotandrsn)\
**Post date:** [March 4, 2005, 7:12pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/28 "2005-03-04T19:12:12Z")

</div>

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](http://www.w3.org/TR/REC-CSS1) Recommendation, which is fairly rudimentary.

Hot on its heels, the W3C came out with [CSS, Level 2](http://www.w3.org/TR/REC-CSS2/), 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](http://www.w3.org/Style/CSS/) 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](http://www.w3.org/Style/CSS/current-work) 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)](http://www.w3.org/TR/CSS21/) 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:

> [@](#):
>
> This is a W3C Candidate Recommendation, which means the specification has been widely reviewed and W3C recommends that it be implemented. It will remain Candidate Recommendation at least until 1 September 2004.
> 
> Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. It is inappropriate to cite this document as other than work in progress.
> 
> A test suite and a report on implementations will be provided before the document becomes a Proposed Recommendation.

A Proposed Recommendation sits around, possibly but not usually gathering minor tweaks until Tim Berners-Lee gets around to signing off on it.

More:

> [@](#):
>
> Candidate Recommendation Exit Criteria
> 
> For this specification to exit the CR stage, the following conditions must be met:
> 
> 1.There must be at least two interoperable implementations for every feature. For the purposes of this criterion, we define the following terms:
> 
> **feature**  
> A section or subsection of the specification.
> 
> \*\*interoperable \*\*  
> passing the respective test cases in the test suite, or, if the implementation is not a web browser, equivalent tests. Every relevant test in the test suite should have an equivalent test created if such a UA is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publicly available for the purposes of peer review.
> 
> **implementation**  
> a user agent which:
> 
> 1. implements the feature.
> 
> 2. is available (i.e. publicly downloadable or available through some other public point of sale mechanism). This is the “show me” requirement.
> 
> 3. is shipping (i.e. development, private or unofficial versions are insufficient).
> 
> 4. is not experimental (i.e. is intended for a wide audience and could be used on a daily basis).
> 
> 5. A minimum of six months of the CR period must have elapsed. This is to ensure that enough time is given for any remaining major errors to be caught.
> 
> 6. The CR period will be extended if implementations are slow to appear.
> 
> 7. Features that were not in CSS1 will be dropped (thus reducing the list of “all” features mentioned above) if two or more interoperable implementations of those features are not found by the end of the CR period.
> 
> 8. Features will also be dropped if sufficient and adequate tests (by judgment of the working group) have not been produced for those features by the end of the CR period.

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).

1. Use Paint or somesuch to create an image of the text you want.
2. 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 &nbsp; entity, which will create a non-breaking space between the words.

Yes, both of these option suck royally.

---

<div class="post-metadata">

**Author:** ![Balthisar](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/balthisar/32/2825_2.png) [@Balthisar](https://boards.straightdope.com/u/Balthisar)\
**Post date:** [March 4, 2005, 8:27pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/29 "2005-03-04T20:27:35Z")

</div>

> [@scotandrsn](#):
>
> 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.
> 
> …
> 
> Secondly, in the meantime, the W3C is working on the [CSS Level 2, Revision 1 (CSS2.1)](http://www.w3.org/TR/CSS21/) 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.

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\*.

---

<div class="post-metadata">

**Author:** ![galt](https://avatars.discourse-cdn.com/v4/letter/g/35a633/32.png) [@galt](https://boards.straightdope.com/u/galt)\
**Post date:** [March 4, 2005, 8:53pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/30 "2005-03-04T20:53:46Z")

</div>

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.](http://www.codsquad.com/~galt/csstest5.html)

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.

---

<div class="post-metadata">

**Author:** ![Omphaloskeptic](https://avatars.discourse-cdn.com/v4/letter/o/bcef8e/32.png) [@Omphaloskeptic](https://boards.straightdope.com/u/Omphaloskeptic)\
**Post date:** [March 4, 2005, 9:57pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/31 "2005-03-04T21:57:01Z")

</div>

> [@galt](#):
>
> 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.](http://www.codsquad.com/~galt/csstest5.html)
> 
> 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.

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).

> [@](#):
>
> 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.

It all comes down to the difference between inline and block elements. [Here](http://www.w3.org/TR/REC-CSS2/visudet.html#Computing_heights_and_margins) (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.

---

<div class="post-metadata">

**Author:** ![scotandrsn](https://avatars.discourse-cdn.com/v4/letter/s/a4c791/32.png) [@scotandrsn](https://boards.straightdope.com/u/scotandrsn)\
**Post date:** [March 4, 2005, 11:11pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/32 "2005-03-04T23:11:25Z")

</div>

> [@Balthisar](#):
>
> 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\*.

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.

---

<div class="post-metadata">

**Author:** ![scotandrsn](https://avatars.discourse-cdn.com/v4/letter/s/a4c791/32.png) [@scotandrsn](https://boards.straightdope.com/u/scotandrsn)\
**Post date:** [March 4, 2005, 11:14pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/33 "2005-03-04T23:14:07Z")

</div>

> [@galt](#):
>
> “you can’t do that with CSS.”

Yet.

---

<div class="post-metadata">

**Author:** ![galt](https://avatars.discourse-cdn.com/v4/letter/g/35a633/32.png) [@galt](https://boards.straightdope.com/u/galt)\
**Post date:** [March 7, 2005, 4:17pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/34 "2005-03-07T16:17:20Z")

</div>

> [@Omphaloskeptic](#):
>
> How can you get the wrapping behavior you want using tables?

[Like this](http://www.codsquad.com/~galt/csstest6.html).

---

<div class="post-metadata">

**Author:** ![galt](https://avatars.discourse-cdn.com/v4/letter/g/35a633/32.png) [@galt](https://boards.straightdope.com/u/galt)\
**Post date:** [March 7, 2005, 4:23pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/35 "2005-03-07T16:23:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Omphaloskeptic](https://avatars.discourse-cdn.com/v4/letter/o/bcef8e/32.png) [@Omphaloskeptic](https://boards.straightdope.com/u/Omphaloskeptic)\
**Post date:** [March 7, 2005, 5:21pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/36 "2005-03-07T17:21:14Z")

</div>

> [@galt](#):
>
> [Like this](http://www.codsquad.com/~galt/csstest6.html).

Hmm. After seeing your other examples I didn’t expect that to work…

---

<div class="post-metadata">

**Author:** ![Balthisar](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/balthisar/32/2825_2.png) [@Balthisar](https://boards.straightdope.com/u/Balthisar)\
**Post date:** [March 7, 2005, 5:37pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/37 "2005-03-07T17:37:23Z")

</div>

> [@galt](#):
>
> [Like this](http://www.codsquad.com/~galt/csstest6.html).

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/](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.

---

<div class="post-metadata">

**Author:** ![galt](https://avatars.discourse-cdn.com/v4/letter/g/35a633/32.png) [@galt](https://boards.straightdope.com/u/galt)\
**Post date:** [March 7, 2005, 5:58pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/38 "2005-03-07T17:58:30Z")

</div>

> [@Balthisar](#):
>
> You know, relatively speaking, your use of tables is _not_ as evil as you might think. Semantically it’s not really correct, but …

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.

---

<div class="post-metadata">

**Author:** ![scotandrsn](https://avatars.discourse-cdn.com/v4/letter/s/a4c791/32.png) [@scotandrsn](https://boards.straightdope.com/u/scotandrsn)\
**Post date:** [March 7, 2005, 6:17pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/39 "2005-03-07T18:17:51Z")

</div>

> [@Balthisar](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![scotandrsn](https://avatars.discourse-cdn.com/v4/letter/s/a4c791/32.png) [@scotandrsn](https://boards.straightdope.com/u/scotandrsn)\
**Post date:** [March 7, 2005, 6:19pm UTC](https://boards.straightdope.com/t/question-from-a-css-dummy/292401/40 "2005-03-07T18:19:05Z")

</div>

Whoops: pardon the winkies, those are semicolons followed by rh parentheses.

(Preview is your friend… :smack: )

[Previous page](https://boards.straightdope.com/t/question-from-a-css-dummy/292401.md?page=1)

[Next page](https://boards.straightdope.com/t/question-from-a-css-dummy/292401.md?page=3)
