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

> On 19 Mar 2015, at 00:39, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> 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.

I agree that your rephrasing "The specified width and height[...]" into
"Length and percentage values for width and height [...]" and turning the
sentence about auto and other keyword values into a note is an improvement
over how things were worded so far.

I've made a commit on my branch applying this change. (visible using
the same github links as in my earlier mail).

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

I am less sure about that. From an editorial perspective, the rest
of your wording sounds fairly good. I'm still on the fence as to
whether it is better that what's already in the spec, but I am leaning
towards agreeing with you. However from normative perspective, I am not
sure I see how it resolves the ambiguities I am trying to address.

Looking separately at the 3 (remaining) parts in your changed wording:

> "[...] 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."
> ->
> "[...] 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."

I am not a fan of the original phrasing's use of "drawn", and your phrasing
is probably a bit better, but I don't think it resolves any ambiguity.

> "The content width and height are calculated [...]"
> ->
> "The specified content-box width and height are calculated [...]"

Replacing "content" with "content-box" doesn't hurt probably good. "Specified value" is only defined for properties, and "content-box width" isn't one, but it hints at the fact that you're not done and still need to do something to get at the computed values and used, so that's probably good anyway (and I've allowed the same type of language in my patched CSS2.1).

>  The resulting content-box sizes are then used as input to the
>  layout rules in [[CSS21]] and elsewhere.

Explicitly invoking the CSS21 rules is good (although I also do it further down).

On the other hand, I don't think "used as input" is good, and may even introduce different mistakes.

1) The 2.1 rules are mostly written as a set of constraints, not as functions, so input and output are not well defined concepts.

2) "Outputs" of the CSS21 rules should also be in terms of content-box, and you need to add back the padding (resp. and border) to get to the used value of the width (etc) property under box-sizing:padding-box (resp. border-box), as they can be observed for instance from getComputedStyle.

Which actually makes me realized that I have only partly accounted for that. With the way I've written it so far, the used values of the properties will be right when the input were lengths or percentages, but not when they were keywords.

<div id="d" style="box-sizing:border-box; position:absolute; padding: 10px;"></div>
<script>console.log(getComputedStyle(document.getElementById("d")).width);</script>

Firefox/Chrome/Safari/Presto --> 20px

IE --> 0px

Oops, looks like not everybody agrees on what the specs mean, and that a few more spots need to be patched.

>  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.
> 
>  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...

Indeed, poor choice of words. That said:

[~/src/csswg-drafts] $ egrep -ri "(outer height)|(outer width)" . |wc
      45    1261   16829
[~/src/csswg-drafts] $ egrep -ri "(inner height)|(inner width)" . |wc
       0       0       0
[~/src/csswg-drafts] $ egrep -ri "(content height)|(content width)" . |wc
     311    4183   55045

Not sure if we should define inner width and inner height to be synonymous
of content width and content height, but I agree that for the other terms
I was trying to define and use, using 'inner' instead of 'content' would
avoid the clash with 'min-content' and 'max-content'.

I've made a commit on my branch applying this change. (visible using
the same github links as in my earlier mail).

>> 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.
> 

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

Right, it is certainly tedious, and hopefully specs that aren't frozen in REC
should disambiguate themselves by using the explicit terms rather than remain ambiguous or rely on CSS3-UI to patch them.

I'd even be happy to errata 2.1 instead, and only leave in CSS3-UI the
definition of "[min|max] inner [width|height]" when box-sizing is not
content-box.

However, (This part of) CSS 2.1 uses the word "width" (resp. height,
min-width, min-height, max-width, max-height) interchangeably to
refer to the value of the width (resp...) property, or to the inner width
(resp...). I agree that in the many cases, there's only one
reasonable way to understand the terms, and it is fairly obvious which one
it is. However, the fact that it wasn't obvious everywhere is what
caused Boris Zbarsky to raise this issue in the first place, and the lack of interop in used values highlighted above further proves the point.

In making this patch, I deliberately erred on the side of being too explicit,
just to make sure that we could all look at the explicitly disambiguated
rules and agree on what they mean.

Once we do agree, if we can make the argument for some (many) cases
that even without explicit disambiguation, there is only one possible meaning
(not the same as "only one reasonable meaning"), and there is no need to be
explicit, then great, and maybe we can just turn (parts of) my tedious enumeration
into a note. Or maybe discard it entirely (although I am less sure about that).

 - Florian

Received on Monday, 23 March 2015 15:54:35 UTC