DOC Document always inline saving elements

en/08_Changelogs/5.3.0.md

@@ -9,7 +9,7 @@ title: 5.3.0 (unreleased)
 - [Features and enhancements](#features-and-enhancements)
   - [High-level API for converting files](#file-converter)
   - [Improve customisability of rendered images](#image-rendering)
-  - [Validation for elemental content blocks when saving individual blocks](#elemental-validation)
+  - [Validation for inline-editable elemental blocks](#elemental-validation)
   - [Define scaffolded form fields for relations to `DataObject` models](#scaffolded-relation-formfields)
   - [Support for `JOIN` in SQL `UPDATE`](#sql-update-join)
   - [Other new features](#other-new-features)
@@ -79,6 +79,8 @@ Elemental content blocks now support validation when saving or publishing indivi
 
 Validation can be added to a content block using standard [Model Validation and Constraints](https://docs.silverstripe.org/en/5/developer_guides/model/validation/#validation-and-constraints) by implementing a [`DataObject::validate()`](api:SilverStripe\ORM\DataObject::validate()) method on a content block, or by using [Form Validation](https://docs.silverstripe.org/en/5/developer_guides/forms/validation/#form-validation) where there are several options available.
 
+Elemental data is no longer sent when saving the parent `DataObject` (usually a `Page`) that contains an [`ElementalAreaField`](api:DNADesign\Elemental\Forms\ElementalAreaField). Instead, when saving the parent `DataObject`, all the child inline-editable elements that have unsaved changes are inline saved at the same time. This change was done to consolidate the saving process down to a single code path. The code that was previously used to process any element data sent with the parent data has been removed.
+
 ### Define scaffolded form fields for relations to `DataObject` models {#scaffolded-relation-formfields}
 
 Most `DataObject` classes will rely on some amount of automatic scaffolding of form fields in their [`getCMSFields()`](api:SilverStripe\ORM\DataObject::getCMSFields()) implementations. However, it's common for modules to provide a specialised form field which is intended to always be used with a specific `DataObject` class. In those cases, even though you always want to use that form field with that class, you have to copy some boilerplate code from the module's documentation to set it up.