Change expandable to details

content/how-to/bpmn/bpmn-elements.md

@@ -382,7 +382,7 @@ width="50%"
 caption="<em>Parallel gateways run jobs in parallel.</em>"
 >}}
 
-{{% expandable title="Parallel joins" %}}
+{{% details title="Parallel joins" %}}
 
 You can join parallel tasks with another parallel gateway.
 This joins the variables from both branches to [process variable context](#process-variable-context).
@@ -396,7 +396,7 @@ width="50%"
 caption="<em>Parallel joins join variable context, but have performance costs.</em>"
 >}}
 
-{{% /expandable %}}
+{{% /details %}}
 
 ## Variables and expressions
 

content/how-to/work-calendars/create-work-calendar.md

@@ -53,7 +53,7 @@ Note that some items, such as `Equipment A`, `Equipment B`, and `Equipment C`,
 have links to child equipment, as expressed in the `isMadeUpOf` property.
 These relationships express the equipment hierarchy.
 
-{{< expandable title="mutation addEquipment" >}}
+{{< details title="mutation addEquipment" closed="true" >}}
 ```gql
 mutation AddEquipment($input: [AddEquipmentInput!]!, $upsert: Boolean) {
   addEquipment(input: $input, upsert: $upsert) {
@@ -156,7 +156,7 @@ mutation AddEquipment($input: [AddEquipmentInput!]!, $upsert: Boolean) {
   "upsert": true
 }
 ```
-{{< /expandable >}}
+{{< /details >}}
 
 
 ### Add Hierarchy scope
@@ -179,7 +179,7 @@ To create levels of calendar scope, add `children`, each of which can link to eq
 This example adds a work-calendar hierarchy, `WorkCalendar_PSDT`, with associated children scopes.
 The scope and its children link to equipment created in the previous step through `equipmentHierarchy`.
 
-{{< expandable title=" mutation addHierarchyScope" >}}
+{{< details title=" mutation addHierarchyScope" >}}
 
 
 ```gql
@@ -282,7 +282,7 @@ mutation AddHierarchyScope($input: [AddHierarchyScopeInput!]!) {
 }
 ```
 
-{{< /expandable >}}
+{{< /details >}}
 
 ### Create work calendar definition
 
@@ -309,7 +309,7 @@ You can optionally add `properties` to each entry to add additional context and
 This `addWorkCalendarDefinition` mutation adds entries for planned downtime and shutdown time.
 Note that the calendar definitions link to a hierarchy scope defined in the previous step.
 
-{{< expandable title="mutation addWorkCalendarDefinition" >}}
+{{< details title="mutation addWorkCalendarDefinition" closed="true" >}}
 ```gql
 mutation AddWorkCalendarDefinition($input: [AddWorkCalendarDefinitionInput!]!, $upsert: Boolean) {
   addWorkCalendarDefinition(input: $input, upsert: $upsert) {
@@ -487,5 +487,5 @@ mutation AddWorkCalendarDefinition($input: [AddWorkCalendarDefinitionInput!]!, $
   "upsert": true
 }
 ```
-{{< /expandable >}}
+{{< /details >}}
 

content/use-cases/data-collection-ebr.md

@@ -142,7 +142,7 @@ Here is a small, generic snippet of how it looks:
 Note how the query specifies exactly the fields to return: no further response filtering is required.
 For an idea of how a more complete query looks, refer to the [Electronic Batch Records]({{< relref "ebr" >}}) guide.
 
-{{< expandable title="Snippet of a makeEbr query" >}}
+{{< details title="Snippet of a makeEbr query" >}}
 ```graphql
 query makeEbr ($filter: JobOrderFilter) {
   queryJobResponse(filter: $filter) {
@@ -162,7 +162,7 @@ query makeEbr ($filter: JobOrderFilter) {
   }
 }
 ```
-{{< /expandable >}}
+{{< /details >}}
 
 The only extra step is to use the returned JSON object as the input for however you create your eBR documents.