Reference · SemText · Definitions & citations

`<sem-properties>`

SemText element

You write one sem-property per pair. The grid renders with plain CSS, so it works with JavaScript off. Machines read the same pairs back.

A list of key–value pairs, shown as a tidy definition grid. You write one sem-property per pair. The grid renders with plain CSS, so it works with JavaScript off. Machines read the same pairs back. (on each `sem-property`): required, free text (the term). The property text is the value.

(optional): free token (`config`, `spec`, `env` …).

per the global attribute catalog (conventions.md §2)

(optional; R/W1): the block is a glossary. Each property should carry an `id`; prose elsewhere links a term with a plain anchor (`<a href="#g-jwt">JWT</a>`), optionally wrapping it in `<dfn>` at its defining use.

Example

sem-properties.html

source

              
              <sem-properties kind="config">
            
                <sem-property key="token ttl" role="definition" aria-label="token ttl">15m</sem-property>
            
                <sem-property key="refresh rotation" role="definition" aria-label="refresh rotation">per use</sem-property>
            
                <sem-property key="storage" role="definition" aria-label="storage">httpOnly cookie</sem-property>
            
              </sem-properties>

render

Live render boots with JavaScript — the authored source is alongside.

variant: glossary view

`view-as="glossary"` (R/W1): the same closed set as a glossary — each property stacks term over definition, and every property carries an `id` prose can link with a plain anchor. With the bundle live, each such anchor gets a hover/focus preview popover showing the pair (`Esc` closes, the anchor still navigates); with no script it stays a definition list with a `:target` highlight and nothing hidden. Extraction is unchanged: a glossary property is still a `sem-property` record.

variant: glossary view

sem-properties-glossary.html

source

              
              <p>The service accepts <dfn>token ttl</dfn>, <dfn>refresh rotation</dfn> and <dfn>storage</dfn> settings — see <a href="#g-token-ttl">token ttl</a> and <a href="#g-refresh-rotation">refresh rotation</a>.</p>
            
              <sem-properties kind="config" view-as="glossary">
            
                <sem-property id="g-token-ttl" key="token ttl" role="definition" aria-label="token ttl">15m</sem-property>
            
                <sem-property id="g-refresh-rotation" key="refresh rotation" role="definition" aria-label="refresh rotation">per use</sem-property>
            
                <sem-property id="g-storage" key="storage" role="definition" aria-label="storage">httpOnly cookie</sem-property>
            
              </sem-properties>

render

Live render boots with JavaScript — the authored source is alongside.

variant: compact `term :: value` sugar

The conventions §3 pair sugar is legal in the property text; `key` stays canonical and wins when both are present. The runtime does not parse `::`, so the value column shows the property text verbatim until a parser ships — which is why the sugar author also writes `key`: sugar without it renders an empty key column.

variant: compact `term :: value` sugar

sem-properties-compact-sugar.html

source

              
              <sem-properties kind="config">
            
                <sem-property key="token ttl" role="definition" aria-label="token ttl">token ttl :: 15m</sem-property>
            
                <sem-property key="refresh rotation" role="definition" aria-label="refresh rotation">refresh rotation :: per use</sem-property>
            
              </sem-properties>

render

Live render boots with JavaScript — the authored source is alongside.

Source: spec/schema/sem-properties.md