- From: Chris Harrelson <notifications@github.com>
- Date: Thu, 21 Nov 2019 14:54:56 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/437/557309261@github.com>
Hi, here are some responses to a couple of your points. > Secondly, even looking at the spec, explainer and examples, I had trouble following what problem this proposal is solving. In particular, it was very unclear to me (even after looking at the examples) why the existing properties mentioned in the "Alternatives Considered" section weren't sufficient. Hmm. The explainer addresses each of these directly. Perhaps there was something missed, or the explanation could be improved. The primary motivating use case is representing estimated placeholder sizing of a DOM subtree, to avoid layout instability and preserve scroll sizing. The browser may not have done the work for multiple reasons, some of which include: * Subtree content is not yet loaded * Subtree content was not committed, or fully committed, from VDOM or some other script-internal state * Subtree content has display:none * Root of subtree uses rendersubtree (the other part of the overall display locking proposal), and the browser skipped doing this work There are other use cases that may arise because now the developer can specify the intrinsic sizing inputs to layout algorithms directly. One potential such use case involving control of scrollbars was brought up at TPAC (by another CSSWG member). > It would be very helpful to have a clear explanation/demonstration of what the precise problem is, and how the existing options behave incorrectly. The examples assert that the behaviour is incorrect, but without a clear explanation of what the desired behaviour is in each case it doesn't actually help in understanding the issue. I'll try to state it as succinctly as possible: *representing estimated placeholder sizing of a DOM subtree which will be loaded and/or rendered later. With that statement I hope it's clear why the examples state that the alternative approaches are incorrect. In those examples, the desired behavior is that a DOM subtree which has an actual sizing exactly equal to the intrinsic sizing CSS property should have exactly the same layout impact on the rest of the document. In other words: once the content has loaded and rendered, layout should remain stable. The "existing options" don't have that behavior on the described examples. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/437#issuecomment-557309261
Received on Thursday, 21 November 2019 22:54:58 UTC