W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2019

[csswg-drafts] [css-sizing] intrinsic-size lost the thread :( (#4531)

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Fri, 22 Nov 2019 23:18:16 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-527459588-1574464695-sysbot+gh@w3.org>
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-sizing] intrinsic-size lost the thread :( ==
At the last f2f, when we discussed the proposal to allow an async-layout element to specify a "default" size while it's not actually laying out its contents (effectively `contain:size`), over the course of the conversation we ended up redefining it into a more general ability to manually set the intrinsic size of an element.

As we've experimented with implementation, tho, we've come to realize that this generalization accidentally significantly broke the usability of the feature for its original use-case.

* With the original [(attribute-based)](https://github.com/WICG/display-locking/) proposal, previously authors could set the "default size" property on all async-layout elements, and it would only trigger when needed (when the element wasn't displaying its children); it would stop affecting anything once full layout started working. With this change, authors instead have to carefully target their rules so that 'intrinsic-size' stops applying when full layout starts, or else lingering effects of the property can produce confusing layout artifacts.
* With our exploration into an alternative CSS-based async layout, you can't even target things carefully anymore; you instead have to track "is locked/unlocked" separately with script and rely on *that* to apply/unapply 'intrinsic-size', breaking all the elegant simplicity.

Regarding the additional use-cases we ended up addressing with the revised "applies all the time" property:
* Per [dbaron's comment](https://github.com/w3c/csswg-drafts/issues/4229#issuecomment-555286700), the auto/legacy usecase that partially justified the expansion of the concept needs some more thought anyway, and should maybe be a separate feature.
* The "generate appropriate scrollbars for virtual scrollers" use-case (#4415) was just a nice freebie feature; it's not an important feature to preserve right now, and can be easily hacked with a fake element at the moment.

So after discussion with @vmpstr and @chrishtr, we'd like to change tactics: we want to withdraw the general intrinsic-size property for now, and return to the earlier concept of something that solely provides a non-zero size for contents *solely when size containment is applying*.

Name is up for grabs; it just needs to be something other than 'intrinsic-size', since it's explicitly *not* setting that general concept.

---

And then separately we'll still want to figure out a good solution to the auto/legacy use-case, but need to review dbaron's feedback.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4531 using your GitHub account
Received on Friday, 22 November 2019 23:18:18 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:56 UTC