Re: Sloppiness of `box', `area', and `width'

On Tue, 15 Nov 2011 10:13:34 -0800, Tab Atkins Jr. wrote:

> On Tue, Nov 15, 2011 at 7:22 AM, Michael Witten <mfwitten@gmail.com> wrote:

>>    * The phrase `content box' means "the box's content area".
>>    * The phrase `padding box' means "the box's padding area".
>>    * The phrase `border box'  means "the box's border area".
>>    * The phrase `margin box'  means "the box's margin area".
>
> This equivalence isn't stated explicitly, but it appears obvious.

It's sloppy.

The whole section begins by talking about the structure of a box;
it's sloppy to introduce the word `box' again with a different
meaning (just as it's sloppy to reuse the word `edge' with different
meanings).

>From sloppiness comes more sloppiness:

>>    * The sentence:
>>          The four content edges define the box's content box.
>>      really means:
>>          The content edge defines the box's content area.
>
> I don't see a difference here.
> [snip identical statements about padding/border/margin]

Firstly, the main issue I'm showing is the continuation of the
sloppy use of the term `edge' (hopefully discussed elsewhere
in this thread).

Secondly, those statements you "snipped" are NOT identical;
I shall reproduce them for you here:

    * The sentence:
          The four padding edges define the box's padding box. 
      really means:
          The content edge and the padding edge define the
          box's padding area.

    * The sentence:
          The four border edges define the box's border box. 
      really means:
          The padding edge and the border edge define the
          box's border area.

    * The sentence:
          The four margin edges define the box's margin box. 
      really means:
          The border edge and the margin edge define the
          box's margin area.

What gets defined is an *area*, not a *box* (which, again,
is not the same kind of box as that which is meant to be
described by the box model).

In particular, notice how the more precise language that I
use is something at which YOU hint in this other rebuttal:

>>    * The word `width' is a suitable synonym for the word `area'.
>
> No, that's not true, and it's not suggested in the text.  The "width"
> talked about in this chapter is the distance between a box's edge and
> the nearest enclosed box's edge. This can be different for each of the
> four edges.  It's almost never synonymous with "area", as even when
> the padding is zero, for example, the padding box will have the same
> area as the content box.

Do you see what you say? Here:

  The "width" talked about in this chapter is the distance between
  a box's edge and the nearest enclosed box's edge.

Do you see? CAN YOU SEE IT? You basically say what I want to say:

          The content edge and the padding edge define the
          box's padding area.

          etc.

Perhaps it will help to point out that `edge' DOES mean `perimeter',
as defined by the spec (reasonably, in your opinion), and what we
are talking ARE areas. Indeed, my problem with the use `width'
stems from these statements in the spec:

    * If the padding has 0 width, the padding edge is the
      same as the content edge.

    * If the border has 0 width, the border edge is the
      same as the padding edge.

    * If the margin has 0 width, the margin edge is the
      same as the border edge.

What does `the padding has 0 width' mean? It is complete nonsense!

However, the term `padding area' has been reasonably defined, and
it certainly makes sense to say:

    * If the padding area is 0, the padding edge is the
      same as the content edge.

where `padding edge', of course, means:

    the padding area's [outer] perimeter

etc.
etc.
etc.

Also, the term `width' has not at all been introduced before it is
used in the context of the distance between two... what should I
call them... edges?... maybe `sub-edges' as you said in order to
to clarify yourself in another email.

Sloppy.

I provide more consistent usage in my suggested copyedit.

Received on Tuesday, 15 November 2011 19:28:49 UTC