Many components can require changes to the "logical" size they require during state changes. The first and classic example of this is the Inline-edit "component", which manages (at least) two different views (with possibly widely different markup) on the same "state". There are a number of important, and possibly conflicting goals to be met when processing this change.
Firstly, it is important to avoid visual "seethe" - this is especially important when the editable components are closely packed, for example in a table layout. The state change to and from editable mode should occur without causing a disruption to the layout or causing the table to reflow or "jitter/seethe" in any way.
Secondly, it is important to provide "adequate" size for the editable view. Certainly for some editable components there is a "minimum usable size" - where this is a plain text entry field, this minimum size could be quite small. However, once we graduate to allowing more complex editable views such as date entry fields, this minimum size could be quite large, and probably often bigger than the non-editable view.
These two together suggest either or both of i) a "mixed" policy towards customising editable size, allowing the editable view to be able to specify its preferences in terms of minimum/preferred size, ii) a "floating" style to layout where the editable view is not actually positioned inline in the document flow but essentially "hovers" over the top of the position where the non-editable view rests.
ii) is quite attractive on many grounds since it guarantees the absence of seethe, but promises to create new issues as regards event capture and CSS - since the "render-only" view under this model would not actually be "hidden" but simply "occluded"....