There is still the limitation imposed by the choice of a field on layout being editable or viewable only. Deselecting field entry in browse mode also blocks the scrolling property of the field.
Scrolling very clearly belongs to the realm of 'viewable'.
The limitation applies to both regular data (text scroll) and container (i.e. pdf scroll) fields.
There are workarounds, but all come with their own limitations and pitfalls, adding complexity, clutter and risk.
The issue was first brought to attention in 2015: search this forum for 'scrollable', or specifically in the 'product ideas area'.
Why should it be programmatic?
If a field is in 'editable' or 'viewable' state depends on context. Context means layout.
The context can be determined by
- user action (i.e. lock or unlock record)
- other parameters
In a context A, a user shall be able to edit a field while in a context B, user shall only have view access. Context A and B may happen on the same layout. Any attempt to get this right in the privileges set falls short. Using layout-level workarounds like calculated fields, script triggers, web viewers or using multiple field objects with visible/invisible toggles add complexity and clutter to a solution.
The advantage and benefits of a clear separation between 'viewable' and 'editable' realm properties, all programmatically controllable at layout level, are quite obvious.
This has been advocated since years and yet I have not seen evidence of consideration.