Re: [csswg-drafts] [css-ui-4] Who defines box-sizing?

@fantasai 
I'd like to (since I was the one who reported #1906), but the the definition was rewritten (by you and/or Tab) when moving adding it to css-sizing, and I had not yet taken the time to check whether anything normative had been lost or changed during the rewrite.

Now I have, so here's my review:

----

The rewrite is generally an improvement, both in purely editorial terms, and because it makes us of more anchoring terminology than what was available for the css-ui version.

However:

1. The statement that `box-sizing` affects flex-basis is good, but a new addition to the definition of `box-sizing`. I cannot find any test that supports it. There's a [2012 resolution](https://lists.w3.org/Archives/Public/www-style/2012May/0520.html) about flexbox that supports it and it was in flexbox before, so that addition is correct, but adding tests when modifying post-CR normative prose, or at least flagging the need for it, would be good.
2. Same comment about "Values affected by box-sizing include [...] those used in functional notations such as fit-content()". That addition is a good one, but it should be supported by tests, and currently isn't.
3. The new examples are good, but you dropped the one that showed how `box-sizing` let you put two `width: 50%` things with a `1em` border and have them fit side by side as their outer size adds up to `100%`. I think that was worth having. Even if we've invented things like flexbox since that example was written, it remains true.
4. The CSS-UI version defined terms line `inner min width` and monkey patched css2.1 to use these terms where appropriate rather than the ambiguous `minimum width` which might refer to the inner one or the outer one, as well as `content width` as opposed to just `width`. The resulting monkey patch was not pleasant to read (or to write), but CSS21 was judged sufficiently non obvious that @bzbarsky had requested (multiple times) full disambiguation, and that writing it (and the corresponding tests) uncovered bugs. 
    You dropped both the term definitions and the money-patch, and replaced it with a much tighter statement that terms like `width`, `minimum width` and friends always refer to the inner size, defining them to be non-ambiguous.
    I don't think this is a good idea:
    * If you read the minutes leading to the the resolution recorded in #1906, we were talking about moving the monkey-patch, not dropping it.
    * The monkey patch was needed because CSS2.1 does not consistently use `width` (and friends) to mean the inner size. It uses it to mean any of: `the inner size`, `the width property`, `the specified/computer/used value of the width property`. 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 100% certain is what caused @bzbarsky  to raise this issue in the first place, and the lack of interop discovered during testing further proves the point. Note that when this was raised, the spec already said that box-sizing affects [min-|max-]?[width|height], already said to subtract padding and border from the outer size  to get to the inner size and to floor at 0 when `box-sizing` is `border-box`, and that browsers were already largely interoperable in the trivial cases.
    * Terms like `width` are inherently ambiguous, since they can easily in casual speech refer to various concepts. Just defining them in one of the possible meanings does not guarantee that it will be used correctly everywhere going forward, and we already know it has been used incorrectly in the past.
    * Since "the correct term" and  "the ambiguous term" look identical, the reader of a spec cannot easily know if the spec author used the word in the precises sense or in the casual and ambiguous sense.

    Now, I don't like monkey patching more than anyone else, but I would recommend:
    * css-sizing (like css-ui-3 before it) should define anchoring terminology for the inner [min-|max-]?[with|height] that cannot accidentally be used when you mean something else. Since it already defines `inner size`, defining `inner [min|max](imum)? size` doesn't seem like much of a stretch. We can also use bikeshed's `lt=""` to make sure that we still link there if we use `width` `height` `inline size` or `block size` instead of just `size`
    * Spec authors may use convenient-but-amgbigous terms like "width" when context is sufficient to be sure about what is meant, but should use precise terminology when there's any chance of ambiguity.
    * Either include the monkey patch of CSS21 in css-sizing-3 (in an appendix if that makes you feel less dirty), or normatively point to the one in CSS-UI-3 until we complete the next point
    * Errata CSS21 to inline the patch (Since CSS-UI-3 is PR and should soon be REC we can normatively use the terminology from CSS2.1) OR write a precisely worded Level 3 alternative to [CSS21/visudet](https://www.w3.org/TR/CSS21/visudet.html) 

----

Point 1, 2, and 3 are not blocking, but for point 4, I think you'll need to convince me or I'll need to convince you, before dropping one spec for the other.

If you're ok with that, I'm happy to write a Pull Request that:
* adds anchor terminology for `inner [min|max](imum)? size` with the relevant `lt=""` to css-sizing
* puts the monkey-patch in an appendix
* removes it box-sizing from css-ui-4
* Optionally, adds back the example from css-ui along the ones in css-sizing.

If you're not OK with that, please say why :)

----

Historical references for point 4:
* [@bzbarsky asking for precise clarification of the equations in 21](https://lists.w3.org/Archives/Public/www-style/2011Jul/0232.html)
* [thread where the current css-ui text was proposed and tweaked](https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html)


-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2458#issuecomment-374848414 using your GitHub account

Received on Wednesday, 21 March 2018 07:02:25 UTC