Re: [css3-ui] specifying box-sizing in greater detail to solve issue 69

On 02/22/2015 02:28 AM, Florian Rivoal wrote:
>
> First, there is a sentence about the width and height properties in (the
> otherwise quite unusable) css-box that seems correct and relevant here,
> and that I believe should be added to css3-ui:
>
>    The keyword values (in contrast to length and percentage values)
>    are not influenced by the ‘box-sizing’ property,
>    they always set the size of the content box.

I agree 100% with this sentence and in adding it to the spec,
it correctly describes the intended behavior. However, I would
make it a note, since it should be a clarifying statement over
the normative definition.

The current normative definitions need some changes, though.

Instead of saying

   # padding-box
   #    The specified width and height (and respective min/max properties)
   #    on this element determine the padding box of the element. That is,
   #    any padding specified on the element is laid out and drawn inside
   #    this specified width and height. The content width and height are
   #    calculated by subtracting the padding widths of the respective sides
   #    from the specified width and height properties. As the content width
   #    and height cannot be negative ([CSS21], section 10.2), this computation
   #    is floored at 0.

You'd say something like

   | padding-box
   |    Length and percentage values for width and height (and
   |    their respective min/max properties) on this element are
   |    interpreted to include the padding area of the element.
   |    That is, the padding box of the element (as opposed to
   |    its content box) is sized to the specified size.
   |
   |    The specified content-box width ... floored at 0.
   | ...
   | The resulting content-box sizes are then used as input to the
   | layout rules in [[CSS21]] and elsewhere.

This restricts what it's affecting to the values that actually
are affected. The note then becomes an informative, but helpful,
restatement of that restriction.

This rewording also talks about the interpretation of values on
certain properties rather than redefining what width and height
mean generally.

> Then, we simply need to go through all of chapter 10 in CSS2.1, and
> disambiguate all instances of words like width, height, min-*, max-*
>that are not linked to 'auto'. I've attached to this mail a chunk of
> text (in bikeshed format) to be added to the the box-sizing section
> of css3-ui that does just that, or you can see the spec with text
> included on my github:
>
> https://github.com/frivoal/csswg-drafts/compare/florian/box-sizing
> https://rawgit.com/frivoal/csswg-drafts/florian/box-sizing/css-ui/Overview.html#box-sizing

I disagree with this approach. There are two problems:

   1. CSS uses the terms "inner width" and "outer width" throughout its
      layout algorithms. These are precisely defined in CSS2.1 as the
      content-box width and the margin-box width, respectively.
      If neither is specified, it is assumed to be the inner width.

      Going through and editing all of the layout algorithms with diffs
      in CSS3 UI seems unnecessarily awkward and hard to maintain.

   2. We have min-content and max-content widths and heights, and they
      are very much not what you define here! So the terminology you
      chose is confusing...

However, if we restrict the effect of box-sizing to the interpretation of
values on the width/height properties, and clarify that box-sizing just
modifies those values and then hands them over as input to the layout rules,
then this problem goes away.

~fantasai

Received on Wednesday, 18 March 2015 23:40:17 UTC