Add closed details block to formatting guide (#6421)
Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>
This commit is contained in:
parent
e76ec7c0c7
commit
eacc70b361
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -13,7 +13,7 @@ redirect_from:
|
|||
|
||||
---
|
||||
|
||||
<details closed markdown="block">
|
||||
<details markdown="block">
|
||||
<summary>
|
||||
Table of contents
|
||||
</summary>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -94,7 +94,7 @@ GET testindex/_search
|
|||
|
||||
The response contains both documents:
|
||||
|
||||
<details closed markdown="block">
|
||||
<details markdown="block">
|
||||
<summary>
|
||||
Response
|
||||
</summary>
|
||||
|
|
|
@ -82,7 +82,7 @@ GET testindex/_search
|
|||
|
||||
The response contains the matching document:
|
||||
|
||||
<details closed markdown="block">
|
||||
<details markdown="block">
|
||||
<summary>
|
||||
Response
|
||||
</summary>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -13,7 +13,7 @@ redirect_from:
|
|||
|
||||
---
|
||||
|
||||
<details closed markdown="block">
|
||||
<details markdown="block">
|
||||
<summary>
|
||||
Table of contents
|
||||
</summary>
|
||||
|
|
|
@ -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>
|
||||
|
|
Loading…
Reference in New Issue