@markout-lang/bootstrap-kit 0.2.0 → 0.2.2

package/README.md

@@ -33,54 +33,10 @@ Bootstrap out:
 <:import src="/npm/@markout-lang/bootstrap-kit/parts/card.htm" />
 ```
 
-Run the showcase — every component below, live — with:
-
-```sh
-npm run dev
-```
-
-That serves [the site](../../sites/site/), which is where the pages built on
-this kit live: `/demos/kitchen-sink.html`, every component one after another;
-and `/demos/orbit.html`, an operations dashboard built out of them, which is
-what they look like wired to one page's data.
-
-The site is a plain Express app rather than markout's `Server`, because Orbit
-is a whole application: it has an API of its own, served from a fake
-in-memory database (`orbit-db.ts`), and markout is the middleware that
-renders its pages. Orbit reads that API with `std-data` from the std kit,
-which fetches while the page renders — so the served console is complete and
-the browser asks for nothing.
-
-Orbit is four files, which is the shape an application takes:
-`demos/orbit.html` for its state, layout and logic; `demos/orbit/components.htm`
-for the tags it defines on top of the kit's; `demos/orbit/sources.htm` for
-where its data comes from; and `server.ts` for its API. The first is imported,
-the second included — a definition wants to arrive once per page however often
-it is named, and an instance wants to be spliced exactly where it is written,
-because that is where its name resolves.
-
-`orbit/sources.htm` also shows the token pattern working for an application's
-own fragment: its root carries `:apiBase="/api"`, which lands on whatever
-contains the `<:include>` unless that element declares it, so a page points
-Orbit at another host without the fragment changing. That is the same
-mechanism as `bsCssUrl` below — not something kits get and applications
-don't.
-
-## Tests
-
-`packages/cli/test/kits/bootstrap-kit.test.ts`, in two tiers:
-
-- **compiled**, which is most of it: every part compiles on its own, the
-  showcase compiles and server-renders with nothing reported, and the id
-  wiring is checked mechanically — every `aria-controls`, `aria-labelledby`,
-  `for`, `data-bs-target` and `data-bs-parent` has to name an element that
-  exists. That last one is the kit's whole reason for existing, so it is
-  worth a test that can't be argued with.
-- **live**, in Playwright: the value-driven components actually driven, and
-  a stubbed Bootstrap asserting the plugin calls. Skipped when no browser is
-  installed (`npx playwright install chromium`).
-
-Nothing reaches the network: the tests set the URL tokens to local files.
+Every component below is shown one after another in the [kitchen
+sink](https://markout.dev/demos/kitchen-sink), and
+[Orbit](https://markout.dev/demos/orbit) is an operations dashboard built out
+of them — what they look like wired to one page's data.
 
 ## What is and isn't a component
 
@@ -152,6 +108,19 @@ That holds however deeply the component sits: a `bs-toast :aka="saved"`
 written inside a `bs-toast-container` is still named where you wrote it, so
 `saved.open = true` reaches it from anywhere on the page.
 
+`bs-input` and `bs-textarea` answer `valid` the same way -- is there a value,
+and does it pass `check`? -- which is what a submit button needs:
+
+```html
+<bs-input :aka="email" :label="Email" :check=${v => v.includes('@')} />
+<bs-button :disabled=${!email.valid}>Send</bs-button>
+```
+
+It is not the negation of the error state. An empty field is not marked
+wrong, which is what keeps a form from opening in red, and it is not
+something to submit either -- so it shows nothing and answers `false`.
+`required` is what makes empty an error as well as a gap.
+
 **Optional regions are `:if`.** A region that exists only when a parameter
 was given is written `:if=${header}`, and nothing inside it evaluates while
 the condition is false — which is what makes `${user.name}` safe to write in
@@ -274,6 +243,9 @@ commented.
 | `bs-range` | `label` `name` `min` `max` `step` `value` `disabled` `showValue` |
 | `bs-input-group` | `prefix` `suffix` `size` |
 
+`bs-input` and `bs-textarea` also answer `valid`, which is read rather than
+passed -- see *Values are read and written* above.
+
 ### Components
 
 | Tag | Parameters |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@markout-lang/bootstrap-kit",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "description": "Bootstrap 5.3 as Markout components: one part per component, with the id wiring, the ARIA attributes and the repetition written once",
   "repository": {
     "type": "git",

package/parts/input.htm

@@ -19,6 +19,17 @@
     invalid once it is non-empty and fails `:check`. Empty is neutral, so a
     form doesn't open covered in errors. `:required` extends that to empty.
 
+    `:valid` is the other side of that, and what a form's own controls read —
+
+      <bs-input :aka="email" :label="Email" :check=${v => v.includes('@')} />
+      <bs-button :disabled=${!email.valid}>Send</bs-button>
+
+    It is deliberately NOT the negation of the error state, which is the one
+    thing about it worth knowing. An untouched field is not wrong — that is
+    what keeps the form out of red — and it is also not something to submit.
+    So empty answers `false` here while showing nothing, and `:required` is
+    what makes empty an error as well as a gap.
+
     Floating labels are the same control with the label after the input
     instead of before it — Bootstrap's CSS keys off that order — so the two
     layouts are two regions rather than one with a class toggled on it.
@@ -49,6 +60,9 @@
     :_invalid=${_empty ? required : !check(value)}
     :_class=${['form-control', size ? `form-control-${size}` : '']
               .filter(s => s).join(' ')}
+
+    // read from outside: is there a value, and does it pass?
+    :valid=${!_empty && check(value)}
   >
     <!--- plain layout: label, control, feedback -->
     <div :if=${!floating}>
@@ -123,6 +137,9 @@
     :_helpId=${`bs-textarea-help-${$id}`}
     :_empty=${value === '' || value == null}
     :_invalid=${_empty ? required : !check(value)}
+
+    // read from outside, as bs-input's is
+    :valid=${!_empty && check(value)}
   >
     <label class="form-label"
       for=${_id}

package/parts/navbar.htm

@@ -40,6 +40,17 @@
       extra,
     ].filter(s => s).join(' ')}
 
+    // The gap under the links is only wanted while they are stacked, which
+    // is up to `expand` and not to any one breakpoint: left at `mb-lg-0` it
+    // would survive into a bar that has already gone horizontal and push the
+    // links up off the brand's line. A navbar that never collapses has no
+    // stacked state to space out, hence the plain `mb-0`.
+    :_navClass=${[
+      'navbar-nav',
+      'me-auto',
+      expand ? `mb-2 mb-${expand}-0` : 'mb-0',
+    ].join(' ')}
+
     class=${_class}
     :class-sticky-top=${sticky}
     :class-fixed-top=${fixed}
@@ -59,7 +70,7 @@
       </button>
 
       <div class="collapse navbar-collapse" id=${_id}>
-        <ul class="navbar-nav me-auto mb-2 mb-lg-0">
+        <ul class=${_navClass}>
           <li class="nav-item" :for-each=${items} :for-as="item">
             <a class="nav-link"
               :class-active=${item.active}