Add closed details block to formatting guide (#6421)

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>
This commit is contained in:
kolchfa-aws 2024-02-16 12:32:44 -05:00 committed by GitHub
parent e76ec7c0c7
commit eacc70b361
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
17 changed files with 58 additions and 37 deletions

View File

@ -111,7 +111,7 @@ For a callout with multiple paragraphs or lists, use `>`:
## Collapsible blocks
To insert a collapsible block, use the `<details>` element as follows:
To insert an open collapsible block, use the `<details>` element as follows:
````html
<details open markdown="block">
@ -132,6 +132,27 @@ To insert a collapsible block, use the `<details>` element as follows:
</details>
````
To insert a closed collapsible block, omit the `open` state:
````html
<details markdown="block">
<summary>
Response
</summary>
{: .text-delta}
```json
{
"_nodes" : {
"total" : 1,
"successful" : 1,
"failed" : 0
}
}
```
</details>
````
Collapsible blocks are useful for long responses and for the Table of Contents at the beginning of a page.
## Dashes

View File

@ -116,7 +116,7 @@ GET /testindex/_stats?level=shards
By default, the returned statistics are aggregated in the `primaries` and `total` aggregations. The `primaries` aggregation contains statistics for the primary shards. The `total` aggregation contains statistics for both primary and replica shards. The following is an example Index Stats API response:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -112,7 +112,7 @@ GET _nodes/stats/
Select the arrow to view the example response.
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -74,7 +74,7 @@ The Profile API response is verbose, so if you're running the request through th
The response contains profiling information:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -225,7 +225,7 @@ The response contains profiling information:
The following is an example response for a concurrent segment search with three segment slices:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -553,7 +553,7 @@ GET /opensearch_dashboards_sample_data_ecommerce/_search
The response contains profiling information:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -825,7 +825,7 @@ GET /opensearch_dashboards_sample_data_ecommerce/_search
The response contains profiling information:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -20,7 +20,7 @@ DQL and query string query (Lucene) language are the two search bar language opt
To follow this tutorial in OpenSearch Dashboards, expand the following setup steps.
<details closed markdown="block">
<details markdown="block">
<summary>
Setup
</summary>

View File

@ -13,7 +13,7 @@ Use the Alerting API to programmatically create, update, and manage monitors and
---
<details closed markdown="block">
<details markdown="block">
<summary>
Table of contents
</summary>

View File

@ -13,7 +13,7 @@ redirect_from:
---
<details closed markdown="block">
<details markdown="block">
<summary>
Table of contents
</summary>

View File

@ -73,7 +73,7 @@ GET /testindex/_search
The query returns both documents:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -262,7 +262,7 @@ POST /testindex/_search
The response contains only document 2:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -332,7 +332,7 @@ POST /testindex/_search
The response contains document 2:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -94,7 +94,7 @@ GET testindex/_search
The response contains both documents:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -82,7 +82,7 @@ GET testindex/_search
The response contains the matching document:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -80,7 +80,7 @@ GET testindex/_search
The response contains the matching document:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -139,7 +139,7 @@ GET testindex/_search
The `english` analyzer removes the stopword `the` and performs stemming, producing the token `wind`. Both documents match this token and are returned in the results:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -204,7 +204,7 @@ GET _search
The query still returns the matching document:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -91,7 +91,7 @@ GET testindex/_search
The query is constructed as `wind AND rise` and returns document 1 as the matching document:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -151,7 +151,7 @@ GET testindex/_search
Now documents are required to match both terms, so only document 1 is returned (this is equivalent to the `and` operator):
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -210,7 +210,7 @@ GET testindex/_search
The `english` analyzer removes the stopword `the` and performs stemming, producing the tokens `wind` and `rise`. The latter token matches document 1, which is returned in the results:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -315,7 +315,7 @@ GET testindex/_search
The token `wnid` matches `wind` and the query returns documents 1 and 2:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -480,7 +480,7 @@ The `cross_fields` query only works as a term-centric query on fields with the s
For example, consider an index where the `first_name` and `last_name` fields are analyzed with the default `standard`
analyzer and their `.edge` subfields are analyzed with an edge n-gram analyzer:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -713,7 +713,7 @@ GET articles/_search
Because by default a `phrase` query matches text only when the terms appear in the same order, only document 1 is returned in the results:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -770,7 +770,7 @@ GET articles/_search
The response contains document 2:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -109,7 +109,7 @@ GET /customers/_search
However, the results include not only the expected document, but all four documents:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>
@ -213,7 +213,7 @@ GET /customers/_search
The preceding query returns document 2:
<details closed markdown="block">
<details markdown="block">
<summary>
Response
</summary>

View File

@ -159,7 +159,7 @@ OpenSearch sends back the model group ID:
You'll use this ID to register the chosen model to the model group.
<details closed markdown="block">
<details markdown="block">
<summary>
Test it
</summary>
@ -271,7 +271,7 @@ Once the task is complete, the task state will be `COMPLETED` and the Tasks API
You'll need the model ID in order to use this model for several of the following steps.
<details closed markdown="block">
<details markdown="block">
<summary>
Test it
</summary>
@ -391,7 +391,7 @@ Once the task is complete, the task state will be `COMPLETED`:
}
```
<details closed markdown="block">
<details markdown="block">
<summary>
Test it
</summary>
@ -469,7 +469,7 @@ PUT /_ingest/pipeline/nlp-ingest-pipeline
```
{% include copy-curl.html %}
<details closed markdown="block">
<details markdown="block">
<summary>
Test it
</summary>
@ -541,7 +541,7 @@ PUT /my-nlp-index
Setting up a k-NN index allows you to later perform a vector search on the `passage_embedding` field.
<details closed markdown="block">
<details markdown="block">
<summary>
Test it
</summary>
@ -670,7 +670,7 @@ GET /my-nlp-index/_search
Document 3 is not returned because it does not contain the specified keywords. Documents containing the words `rodeo` and `cowboy` are scored lower because semantic meaning is not considered:
<details closed markdown="block">
<details markdown="block">
<summary>
Results
</summary>
@ -762,7 +762,7 @@ GET /my-nlp-index/_search
This time, the response not only contains all five documents, but the document order is also improved because neural search considers semantic meaning:
<details closed markdown="block">
<details markdown="block">
<summary>
Results
</summary>
@ -910,7 +910,7 @@ GET /my-nlp-index/_search?search_pipeline=nlp-search-pipeline
Not only does OpenSearch return documents that match the semantic meaning of `wild west`, but now the documents containing words related to the wild west theme are also scored higher relative to the others:
<details closed markdown="block">
<details markdown="block">
<summary>
Results
</summary>

View File

@ -13,7 +13,7 @@ redirect_from:
---
<details closed markdown="block">
<details markdown="block">
<summary>
Table of contents
</summary>

View File

@ -24,7 +24,7 @@ If you need to delete a snapshot, be sure to use the OpenSearch API rather than
---
<details closed markdown="block">
<details markdown="block">
<summary>
Table of contents
</summary>