#565: Review of CSS Sizing 3

Visit on Github.

Opened Oct 23, 2020

HIQaH! QaH! TAG!

I'm requesting a TAG review of CSS Sizing Level 3.

This CSS module defines the various sizing properties and concepts used throughout CSS. New features since CSS2 are summarized in https://www.w3.org/TR/css-sizing-3/#changes-3

  • Explainer¹ (minimally containing user needs and example code): None
  • Specification URL: https://www.w3.org/TR/css-sizing-3/
  • Tests: throughout the CSS WPT repo
  • Security and Privacy self-review²: The only relevant concern seems to be that content-based sizes can expose information about the contents of an element via the size.
  • GitHub repo (if you prefer feedback filed there): https://github.com/w3c/csswg-drafts/issues
  • Primary contacts (and their relationship to the specification): @fantasai and @tabatkins (editors)
  • Organization(s)/project(s) driving the specification: CSSWG
  • Key pieces of existing multi-stakeholder review or discussion of this specification: Nothing particularly exciting, just an interminably long list of issues from everyone working on CSS layout since ~2000.
  • External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Unaware of any meta tracking, just individual bugs. If you really want me to triage all the engines' sizing bugs so I can list them all here, please ask for that work explicitly as I'd rather not spend a few months on it if it's not required.

Further details:

  • [tl;dr but I promise to review it once you put it on w3.org] I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: aiming to transition to CR this year
  • The group where the work on this specification is currently being done: CSSWG
  • Major unresolved issues with or opposition to this specification: https://github.com/w3c/csswg-drafts/issues/5650
  • This work is being funded by: Google, previously also Mozilla

You should also know that... Can't think of anything.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Comment by @hadleybeeman Nov 11, 2020 (See Github)

Hi @fantasai! Our API Design Principles are now in TR space. https://www.w3.org/TR/design-principles/

We'll be interested to hear your thoughts!

Comment by @torgo Nov 11, 2020 (See Github)

Hi - we are just triaging this today. We kind of require an explainer for all of our reviews which starts from user needs. There are people in the TAG who are contributors to CSS who are definitely aware of this work but for the rest of us can you put something together so we can better understand it? Please see our explainer explainer https://w3ctag.github.io/explainers for a run-down of what we look for in an explainer.

Discussed Dec 7, 2020 (See Github)

Elika:

... CSS3 text is like a collection of separate side dishes...

... From the CSS system point of view, terminology section is most interesting. Features listed in the review are the most interesting

.. Terminology gives names to a bunch of concepts which have always existed in CSS.

... the features mentioned in the comment are what's changing in this version.

... They are shipping in several implementations (some with prefixes), definitions of what they mean is pretty clear to CSSWG, just giving names to behaviour you could access in CSS2; previously height access didn't have any varying behaviour. TAG would be unlikely to be interested in that. Probably only interested in interaction between replaced elements and these things.

... replaced elements are external to the document, transferring info to doc about themselves (e.g. sizing info); that's the interface between CSS and other tech. Most of the spec doesn't need TAG review, but TAG is in the loop on everything.

... Some questions that might go into a CSS-specific review template:

  • Why did you write this spec (what prompted the features in it)?
  • If you were the TAG, which sections would you focus on?

Peter: Explanations like this one are helpful not only for TAG, but also for other horizontal reviews and newcomers to CSSWG.

Elika: Snapshot gives an overview. ...

Peter: Web developer is better served by the snapshot. Someone joining CSSWG needs more context ...

Elika: If people want to get involved, they can start filing issues... then we can provide context on the issue. Pre-emptively generating that context isn't scalable.

Peter: Could we on CSSWG have some process going forward to make this process easier, without Elika needing to personally write explainers for every single feature?

Elika: Issues also linked to commit logs... you do have to go dig, though. Alternative is to have us write continuous status reports... and we already give more context on commits than most WGs.

Comment by @tabatkins Dec 7, 2020 (See Github)

We're going to assume that you're not asking for explainers for features that were originally defined in other specs like CSS2 / CSS UI Level 3 / CSS Flexbox, but only for the features which are new in this specification. These are:

  • the min-content and max-content keywords
  • the fit-content() function

The user needs underlying all of these are straightforward: they let authors reproduce, explicitly, useful layout behaviors that they could previously achieve as a side-effect of certain circumstances, such as floats and table layout. In particular, min-content is the size that a float takes if its container is smaller than its min-content size in that axis (aka "as narrow as it can get without causing overflow"), max-content is the size a float takes if its container is larger than its max-content size in that axis (aka "as wide as it needs to be to fit everything without text wrapping"), and fit-content(<length-percentage>) is the “shrink to fit” size a float takes if its container is the given size in that axis: the smaller of its max-content size and its container's size, floored by its min-content size.

Authors have long used these concepts in their layouts, but it can be awkward to trigger the correct conditions to get exactly the desired layout behavior, and depending on the circumstance can require adding extraneous wrapper elements. Adding these keywords makes these kinds of layouts easier to achieve, and substantially easier to read and understand the intent of than the previous "layout hacks" that were required. They also give us (the CSSWG) useful hooks to key off of in layout algorithms, since they meaningfully signal intent from the author about how they want the element to size.

The entire rest of the spec is defining the terminology and concepts nessary to specify how these keywords, and other foundational aspects of the CSS sizing algorithms, actually work. Most of it is dictated by behaviors existing in, but only very loosely defined in, CSS2; the only area where the CSSWG has had significant discretion is the handling of cyclic percentages and the handling of replaced elements without an intrinsic size.

~Tab and fantasai

Discussed Jan 1, 2021 (See Github)

Rossen: (summarizing CSSWG/TAG reviews, explainers etc.)

Peter: The changes section looks good. What was missed by the original list of added features is box-sizing and to be fair this dates way back to the 90's so it's fine.

Rossen: Ack. Leaving comment and closing then.

Comment by @atanassov Jan 26, 2021 (See Github)

@LeaVerou, @plinss and myself looked at this during our "Kronos" virtual f2f. The overall list of changes looks good. What was missed from the list of major additions listed by @tabatkins is box-sizing but to be fair that has a long history going back to the 90's. With that review we are happy to see the spec move forward the REC track. Thank you for playing TAG.

Comment by @fantasai Mar 25, 2021 (See Github)

@atanassov (box-sizing was introduced in css-ui-3, it's not new in css-sizing-3, that's why it wasn't listed)