There are a number of stack overflow questions about auto-layout of UITableView
cells and section headers / footers that concern the UIView-Encapsulated-Layout-Width
constraints that the UITableView
uses to make its components be the correct size:
- what is NSLayoutConstraint "UIView-Encapsulated-Layout-Height" and how should I go about forcing it to recalculate cleanly
- iOS 8.3 'UIView-Encapsulated-Layout-Width' in Custom Keyboard
- Auto-layout: What creates constraints named UIView-Encapsulated-Layout-Width & Height?
- What is a 'UIView-Encapsulated-Layout-Width' constraint?
The purpose of these constraints seems pretty clear – they allow the UITableView
and also UICollectionView
to interface with constraint layout and pass in its specification about how large cells (and other components) should be.
Most issues seem to be that people have a set of required constraints that are incompatible with these encapsulation constraints also requiring a size of 0
. The most workable answers seem to be to lower the priority of user defined constraints to 999
so that the framework's can overrule them.
However – what I'm interested in understanding is why is UITableView
requiring a width of 0
for one of its views? Is this a bug? Or is it a results of incorrect use? Or does it make perfect sense?
Height constraints of 0
sometimes make sense, if cells are being expanded from nothing. Lowering priorities is a good way to handle this. But why would the cells be getting a width of 0
?