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

Re: [csswg-drafts] Proposal: content-size CSS property (#4229)

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Aug 2019 17:27:50 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-523564966-1566408468-sysbot+gh@w3.org>
We thought about that, but it ends up working awkwardly with our current async-render design.

Basically, once you tell a subtree to be async-rendered, it automatically applies several containments, in addition to whatever else you might be specifying in your own stylesheet. One of those is size containment, so if you needed to apply it yourself to get this functionality, that wouldn't work.

* Our earlier design instead required *you* to apply the necessary containments to get async-rendering to work at all, but that seemed awkward and bad. It puts a non-obvious hurdle in the way of authors getting this to work ("why isn't my element rendering async? I set the attribute correctly!") and it's future-hostile if we add more containment options in the future that we want async stuff to rely on (suddenly all the old pages using async will just become sync, as they're lacking necessary containment values).
* We assign the necessary containments "magically" in an additive way, rather than using a UA stylesheet that could be overridden, because of the lessons we learned with the `hidden` attribute: doing it in a normal UA rule becomes trivial to accidentally override when applying your own lesser containments, while doing it in a UA-important rule means you can't apply *extra* containments beyond what the feature requires, because the author rule will lose. If/when we get additive cascade features we can probably avoid the magic.
* We might be able to get around this by specifying that if both `size` containment and `size-with-child` containment are applied, the size-with-child wins out. Or that the magic doesn't attempt to add size containment if it detects size-with-child containment already in place.
* If the containment value definitely turns on size containment, then you need to make sure you only apply it when the element is invisible-subtree mode (`rendering="invisible"` or `rendering="invisible-activatable"`). That's not difficult (we purposely designed the feature to make the attribute a source of truth, so you can use it in selectors to style differently based on current state), but it is one more detail to think about, versus just blind applying a property that'll only have an effect when it matters. Alternately we could make it a containment value that just modifies size containment but has no effect on its own, which feels a *little* weird but I guess not terrible.

So, yeah, we've avoided it for now, but it's possible to do if the group decides a specialty property is overkill.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4229#issuecomment-523564966 using your GitHub account
Received on Wednesday, 21 August 2019 17:27:51 UTC

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