diff --git a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc
index 34511055f92..4bc08e9bfa0 100644
--- a/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc
+++ b/framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-collaborators.adoc
@@ -159,8 +159,10 @@ Kotlin::
 ----
 ======
 
-.[[beans-factory-ctor-arguments-type]]Constructor argument type matching
---
+[discrete]
+[[beans-factory-ctor-arguments-type]]
+==== Constructor argument type matching
+
 In the preceding scenario, the container can use type matching with simple types if
 you explicitly specify the type of the constructor argument via the `type` attribute,
 as the following example shows:
@@ -172,10 +174,11 @@ as the following example shows:
 		<constructor-arg type="java.lang.String" value="42"/>
 	</bean>
 ----
---
 
-.[[beans-factory-ctor-arguments-index]]Constructor argument index
---
+[discrete]
+[[beans-factory-ctor-arguments-index]]
+==== Constructor argument index
+
 You can use the `index` attribute to specify explicitly the index of constructor arguments,
 as the following example shows:
 
@@ -191,10 +194,11 @@ In addition to resolving the ambiguity of multiple simple values, specifying an
 resolves ambiguity where a constructor has two arguments of the same type.
 
 NOTE: The index is 0-based.
---
 
-.[[beans-factory-ctor-arguments-name]]Constructor argument name
---
+[discrete]
+[[beans-factory-ctor-arguments-name]]
+==== Constructor argument name
+
 You can also use the constructor parameter name for value disambiguation, as the following
 example shows:
 
@@ -244,7 +248,6 @@ Kotlin::
 	constructor(val years: Int, val ultimateAnswer: String)
 ----
 ======
---
 
 
 [[beans-setter-injection]]
diff --git a/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc b/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc
index bb5b6ef4aa3..dab7103ab3a 100644
--- a/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc
+++ b/framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc
@@ -331,8 +331,10 @@ TIP: Constructor injection in `@Configuration` classes is only supported as of S
 Framework 4.3. Note also that there is no need to specify `@Autowired` if the target
 bean defines only one constructor.
 
-.[[beans-java-injecting-imported-beans-fq]]Fully-qualifying imported beans for ease of navigation
---
+[discrete]
+[[beans-java-injecting-imported-beans-fq]]
+==== Fully-qualifying imported beans for ease of navigation
+
 In the preceding scenario, using `@Autowired` works well and provides the desired
 modularity, but determining exactly where the autowired bean definitions are declared is
 still somewhat ambiguous. For example, as a developer looking at `ServiceConfig`, how do
@@ -501,7 +503,6 @@ Now `ServiceConfig` is loosely coupled with respect to the concrete
 get a type hierarchy of `RepositoryConfig` implementations. In this
 way, navigating `@Configuration` classes and their dependencies becomes no different
 than the usual process of navigating interface-based code.
---
 
 TIP: If you want to influence the startup creation order of certain beans, consider
 declaring some of them as `@Lazy` (for creation on first access instead of on startup)
@@ -594,8 +595,10 @@ that uses Spring XML, it is easier to create `@Configuration` classes on an
 as-needed basis and include them from the existing XML files. Later in this section, we cover the
 options for using `@Configuration` classes in this kind of "`XML-centric`" situation.
 
-.[[beans-java-combining-xml-centric-declare-as-bean]]Declaring `@Configuration` classes as plain Spring `<bean/>` elements
---
+[discrete]
+[[beans-java-combining-xml-centric-declare-as-bean]]
+==== Declaring `@Configuration` classes as plain Spring `<bean/>` elements
+
 Remember that `@Configuration` classes are ultimately bean definitions in the
 container. In this series examples, we create a `@Configuration` class named `AppConfig` and
 include it within `system-test-config.xml` as a `<bean/>` definition. Because
@@ -703,16 +706,16 @@ Kotlin::
 ----
 ======
 
-
 NOTE: In `system-test-config.xml` file, the `AppConfig` `<bean/>` does not declare an `id`
 element. While it would be acceptable to do so, it is unnecessary, given that no other bean
 ever refers to it, and it is unlikely to be explicitly fetched from the container by name.
 Similarly, the `DataSource` bean is only ever autowired by type, so an explicit bean `id`
 is not strictly required.
---
 
-.[[beans-java-combining-xml-centric-component-scan]] Using <context:component-scan/> to pick up `@Configuration` classes
---
+[discrete]
+[[beans-java-combining-xml-centric-component-scan]]
+==== Using <context:component-scan/> to pick up `@Configuration` classes
+
 Because `@Configuration` is meta-annotated with `@Component`, `@Configuration`-annotated
 classes are automatically candidates for component scanning. Using the same scenario as
 described in the previous example, we can redefine `system-test-config.xml` to take advantage of component-scanning.
@@ -736,7 +739,6 @@ The following example shows the modified `system-test-config.xml` file:
 		</bean>
 	</beans>
 ----
---
 
 [[beans-java-combining-java-centric]]
 === `@Configuration` Class-centric Use of XML with `@ImportResource`