[css-ui-4][css-sizing-3] Who defines box-sizing?

[annevk]

It seems both CSS Sizing and CSS UI put a claim on it. This makes linking it from other standards hard.

(In particular, I noticed this when looking at warnings for https://quirks.spec.whatwg.org/.)

[Loirooriol]

From #1906 it seems it should be CSS Sizing.

[annevk]

Thanks, it seems that was semi-fixed as nobody updated UI...

[fantasai]

@frivoal Mind removing from ui-4?

[frivoal]

@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 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 [css-ui-4][css-sizing] Moving box-sizing to the right spec #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

---

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
• thread where the current css-ui text was proposed and tweaked

[frivoal]

Agenda+F2F in to resolve the disagreement. @fantasai and @tabatkins , if you end up agreeing with me or convincing me before the F2F, we can take it off.

[fantasai]

I'm okay with normatively pointing at css-ui-3 and/or updating CSS2.1 to be more precise. Not OK with carrying around this monkey patch forever.

That said, the monkey patch can be compressed to a single sentence, since every unqualified reference in CSS2.1 resolves to the inner width/height: this is exactly what the monkey patch does, except it spends an entire awful page of English-description diffs to do so. If we have to keep it going forward, I want to keep it in compressed form.

I'm happy to give width/height a more ambiguous definition for L3 specs and add anchors for inner/outer min/max? size if that's seen as helpful.