SemText

Reference · SemText · Facts & recall

<sem-fact>

SemText element

You write the statement, the conclusion drawn from it, and any incorrect-statement to warn against. The id is the token other text cites. It reads as plain sentences with JavaScript off.

Shares its schema with <sem-facts> — the option bullets below belong to that element's contract.

One fact: a statement, its conclusion, and optionally what would be wrong to believe. You write the statement, the conclusion drawn from it, and any incorrect-statement to warn against. The id is the token other text cites. It reads as plain sentences with JavaScript off.

No options beyond the global attribute catalog are stated for this tag.

Children

  • <statement>required per fact; the claim itself.
  • <conclusion>required per fact; the assertion the statement resolves to (the back of the card, the quiz answer).
  • <incorrect-statement>optional, quiz view only; an explicit wrong candidate. Without one, sibling conclusions serve as distractors.

Example

sem-fact.html
source
1 <sem-facts id="auth-facts" view-as="flashcards">
2 <sem-fact id="f-rotate">
3 <statement>JWTs rotate per session</statement>
4 <conclusion>Short-lived access tokens; the refresh
5 grant issues a new pair.</conclusion>
6 <incorrect-statement>Store tokens in localStorage.</incorrect-statement>
7 </sem-fact>
8 <sem-fact id="f-expiry">
9 <statement>Access tokens expire after 15 minutes</statement>
10 <conclusion>The client mints a new pair from the refresh
11 grant; the user never re-signs-in mid-session.</conclusion>
12 <incorrect-statement>The user must sign in again every 15
13 minutes.</incorrect-statement>
14 </sem-fact>
15 <sem-fact id="f-secret">
16 <statement>Client secrets never reach the browser</statement>
17 <conclusion>The confidential client holds the secret
18 server-side; the browser only ever sees tokens.</conclusion>
19 <incorrect-statement>Embed the client secret in the SPA
20 bundle.</incorrect-statement>
21 </sem-fact>
22 </sem-facts>
render

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

view-as omitted — list (default): every fact readable, no chrome

`<sem-fact>` is the atomic unit; a container stacks its facts in document order with `view-as` omitted. Each fact shows its `<statement>` (the claim) then its `<conclusion>` (the assertion the claim resolves to). Nothing is interactive and no chrome is added, so the default view reads as an ordinary document.

view-as omitted — list (default): every fact readable, no chrome
sem-fact-list.html
source
1 <sem-facts id="token-facts">
2 <sem-fact id="f-rotate">
3 <statement>Refresh tokens rotate on every use</statement>
4 <conclusion>Each exchange retires the presented token; a replayed one is rejected.</conclusion>
5 </sem-fact>
6 <sem-fact id="f-scope">
7 <statement>Scope is the durable control, not token lifetime</statement>
8 <conclusion>Tight scopes outlive short expiries; extending an expiry only widens the blast radius.</conclusion>
9 </sem-fact>
10 </sem-facts>
render

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

view-as="flashcards" — one fact at a time, the flip reveals its conclusion

The same pair as a self-test card. Only the current `<sem-fact>` shows: front is the statement, back is the conclusion, revealed by a click (the flip). The meter is an index — one numbered chip per card, the current one highlighted, answered chips tinted by their ✓ Got it / ✗ Wrong verdict; prev/next walk the deck and a chip jumps straight to its card. When every card carries a verdict the deck ends on a total ("You got X of N") with a Restart control. Not part of the fact's stored data — `view-as` is display-only, and every fact extracts the same pair.

view-as="flashcards" — one fact at a time, the flip reveals its conclusion
sem-fact-flashcards.html
source
1 <sem-facts id="oauth-facts" view-as="flashcards">
2 <sem-fact id="f-device">
3 <statement>OAuth device flow targets input-constrained devices</statement>
4 <conclusion>TVs, consoles and CLIs poll the token endpoint with a device code.</conclusion>
5 </sem-fact>
6 <sem-fact id="f-pkce">
7 <statement>PKCE binds the authorization code to the client</statement>
8 <conclusion>The code exchange proves possession of the verifier, so a stolen code is inert.</conclusion>
9 </sem-fact>
10 </sem-facts>
render

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

view-as="quiz" — the fact as a scored question, conclusion as the answer

Quiz turns each fact into one answerable question: the statement is the prompt, the `<conclusion>` is the correct option, and the `<incorrect-statement>` children are the decoys — options render on thin-bordered buttons in a seeded shuffled order. A wrong pick marks that button (✗, spent) and the question stays open: the reader keeps picking until the correct option lands (✓), which scores `1/1 · score 1/1` in the meter and auto-advances after a 500 ms beat. With no `<incorrect-statement>`, sibling conclusions fill the decoy slots.

view-as="quiz" — the fact as a scored question, conclusion as the answer
sem-fact-quiz.html
source
1 <sem-facts id="quiz-facts" view-as="quiz">
2 <sem-fact id="f-header">
3 <statement>The OIDC token travels in which header?</statement>
4 <conclusion>Authorization</conclusion>
5 <incorrect-statement>Cookie</incorrect-statement>
6 <incorrect-statement>X-Auth-Token</incorrect-statement>
7 </sem-fact>
8 </sem-facts>
render

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

Source: spec/schema/sem-facts.md