Re: box-sizing alternative

What you say below Joe seems to me to be contradictor in some cases, but 
perhaps I don't understand correctly. To explain what bothers me though 
(without getting into all the gory details), one of the things I have always 
HATED about tables is that the widths of the elements (usually cells) were 
TOO flexible (read: never well defined as to which element widths overrode 
which others). MAYBE that was just sloppy UA implementation, but no matter;
what I still prefer is the ability to precisely define and control ALL widths 
rather than permitting content to "fill" by default.

I would LOVE to see a "content-width" element, but I do NOT want to see
it cause "WIDTH" to expand if "content-width" happens to be larger than
width. Content-width + border-width + padding-width should either WRAP within 
WIDTH or be CLIPPED by WIDTH at the user's discretion. If CLIPPED, some
mechanism for the dispensation of the overflow might be added, particularly
as related to element shapes which might not be BOXES. (As I recall there is
some mechanism being planned that will render content containers as circles, 
ovals, and polygons? Isn't there? Please. Really.)

Later,

Rick Johnson
firespring@nfx.net 

Joe Hewitt wrote:
> 
> 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:
> 
> <div style="content-width: 100px; padding: 2px; border-width:
> 2px;"&rt;Testing</div&rt;
> 
> The above div would have an actual resulting #WIDTH# of "104px".  Then, take
> this example:
> 
> <div style="width: 100px; padding: 2px; border-width:
> 2px;"&rt;Testing</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:
> 
> <div style="width: 100px; content-width: 50px; padding: 2px;
> border-width: 2px;"&rt;Testing</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:
> 
> <div style="width: 100px; content-width: 150px; padding: 2px;
> border-width: 2px;"&rt;Testing</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:
> 
> <TABLE WIDTH="100"&rt;
> <TBODY&rt;
>         <TR&rt;
>                 <TD WIDTH="150"&rt;Testing</TD&rt;
>         </TR&rt;
> </TBODY&rt;
> </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 13:01:44 UTC