W3C home > Mailing lists > Public > www-style@w3.org > February 2000

box-sizing alternative

From: Joe Hewitt <joe@joehewitt.com>
Date: Tue, 29 Feb 2000 10:09:43 -0500
To: <www-style@w3.org>
Message-ID: <000201bf82c7$02c4fbf0$31cfb326@zenimax.com>
I am of the believe that the defined behavior of sizing in CSS/CSS2 is very
misleading and will result in a good deal of confused developers and broken
layouts.  It seems to me that the property "width" (and height also) should
refer to the width of the ENTIRE element, including content, border and
padding, but not margin.  As it is defined by the W3C, "width" actually
means "content-width".  I believe it would be a good idea to then add an
element called "content-width" to CSS3, and change the meaning of "width".
For the sake of this discussion I will refer to actual, final width as
#WIDTH#.  For example:

&lt;div style="content-width: 100px; padding: 2px; border-width:
2px;"&rt;Testing&lt;/div&rt;

The above div would have an actual resulting #WIDTH# of "104px".  Then, take
this example:

&lt;div style="width: 100px; padding: 2px; border-width:
2px;"&rt;Testing&lt;/div&rt;

The above div would have a #WIDTH# of "100px".  The "border" and "padding"
would show up inside of the 100 pixel-wide box.  Then, take this example:

&lt;div style="width: 100px; content-width: 50px; padding: 2px;
border-width: 2px;"&rt;Testing&lt;/div&rt;

In this case, the "content-width" would count for nothing, as it doesn't
reach out to the edge of the "width".  The width of the content region would
expand to fit inside "width"-("padding"+"border"). Then, take this example:

&lt;div style="width: 100px; content-width: 150px; padding: 2px;
border-width: 2px;"&rt;Testing&lt;/div&rt;

In this case, the "content-width" is wider than the "width", and so the
width should actually expand to fit the content, and become "150px".  The
nice thing about this is that if "content-width" is left at "auto", the
browser must calculate the width of the contained text/elements and put that
value in "content-width", which gives the user the ability to make an
element adapt automatically.

When "width" is not defined, #WIDTH# = "padding" + "border" + "content".
When it is defined, #WIDTH# will be equal to "width" unless "padding" +
"border" + "content" &rt; "width", in which case #WIDTH# is equal to that
sum.

Another advantage of this method is that it works the same way that tables
work in HTML, which is something that the web development community at large
is used to.  If for example, you had a table like this:

&lt;TABLE WIDTH="100"&rt;
&lt;TBODY&rt;
	&lt;TR&rt;
		&lt;TD WIDTH="150"&rt;Testing&lt;/TD&rt;
	&lt;/TR&rt;
&lt;/TBODY&rt;
&lt;/TABLE&rt;

Essentially the TABLE's "WIDTH" is the same as CSS "width" while the TD's
"WIDTH" is the same as "content-width".  This is the same as my last CSS
example, and the table will expand to fit the TD's size.

I see not reason to have an attribute like box-sizing.  It seems
counter-intuitive to change the definition of sizing.  Instead, we should
clearly define these regions and how to control their size.  Now the user
can identify that "width" means width of everything, "margin" is a region
outside of the "width", "border" is a region inside the edge of "width",
"padding" is a region inside the edge of "border", and "content" is a region
inside the edge of "padding".  Now the user has firm control over the size
of all of these regions, with the ability to over-ride them all with
"width".

Does this make sense to anybody?
Received on Tuesday, 29 February 2000 10:06:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:04 GMT