W3C home > Mailing lists > Public > www-style@w3.org > August 2003

Size of "inline-block" [CSS 2.1]

From: Roger Larsson <roger.larsson@incrementa.se>
Date: Fri, 1 Aug 2003 21:30:14 +0200
To: www-style@w3.org
Message-Id: <200308012130.15194.roger.larsson@incrementa.se>

How do I compute the width and height of an "inline-block" element?

I have implemented "display:inline-block" but had some problems when 
interpreting the CSS 2.1 specification. The only information I found on the 
subject was the following:

----Start excerpt from CSS 2.1 [9.2.4]
This value causes an element to generate a block box, which itself is flowed 
as a single inline box, similar to a replaced element. The inside of an 
inline-block is formatted as a block box, and the element itself is formatted 
as a replaced element on the line.
----End excerpt from CSS 2.1 [9.2.4]

My interpretation of this is that the size of the inline-block is based on the 
size of its content and/or on the "width" and "height" properties. 

This is no problems as long as the "width" and "height" properties are not 
"auto", and the "inline-block" only contains "inline" elements. But how to 
handle the case when "width" and/or "height" are "auto" and the 
"inline-block" contains at least one "block" element.

Since the inside of the "inline-block" is formatted as a "block" box it acts 
as "containing block" for the content, that is the "block" elements. 
Computing the width of the "block" elements then requires the width of the 
"inline-block", but to compute the width of the "inline-block" I need the 
width of the content, that is, the width of the "block" elements. I thus have 
a circular definition. 

As a quick and dirty workaround my implementation breaks the circle by 
computing the width of the content using the nearest ancestor "containing 
block" having a known width, but there must be a better and more correct way 
of handling the problem.

Instead of the current definition would it not be better to compute the width 
of an "inline-block" the same way we compute the width of absolutely 
positioned elements, that is, "shrink-to-fit"? The problems appear to be 
similar. In addition to the usually good reason, beeing consistent, another 
reason is that it might be a simple way to use the viewport efficiently as 
well as presenting structured information in a reasonably visually attractive 
way. Compared to tables it is more dynamic and would adapt better to 
different viewport aspect ratios. My hypothesis is based on work done on java 
layout managers.

In any way I would appreciate a lot if the specification elaborated more on 
the subject since it has such huge impact on the visual appearance, 
especially when "inline-blcok" elements contain "inline-block" elements.

Finally I think that "inline-block" is a powerful and much valuable addtion to 
CSS since it have such huge "user benefit" / "implementation effort" ratio. 
It seems to handle many simple ordinary cases which previously required 
tables, as well as beeing more dynamic than a fixed grid layout. Furthermore, 
to implement "inline-block" on top of "inline" and "block" was done in a 
couple of hours, while implementing _tables_ according to the specification 
seem to be somewhat more work... 

Does someone know, or know where I can read, the official motivation for 
"inline-block" since? Reading it would probably make the interpretation of 
the specification more clear.
Received on Friday, 1 August 2003 15:31:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:08 UTC