@livx.cc/bare-v3 0.1.0-alpha.105 → 0.1.0-alpha.106

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,5 +1,5 @@
1
1
  {
2
- "version": "0.1.0-alpha.105",
2
+ "version": "0.1.0-alpha.106",
3
3
  "cssSha256": "c8aad669e68ccbd81d21741636b8e3b04823dd166ca33f31c08661a308e97de1",
4
4
  "classes": [
5
5
  "b3-accordion",
@@ -29,6 +29,8 @@ Choose a semantic composition:
29
29
 
30
30
  Use named CSS for app-specific composition, not a second utility vocabulary. Start with intrinsic wrapping and content bounds. Preserve the atoms’ shrink behavior: do not add an unconditional rem-based min-width to a field or peer. Use a flexible basis for preferred width; if a minimum is necessary, cap it to the available inline size. Check narrow layouts with enlarged text, where rem-based minimums grow but the viewport does not. Add a breakpoint only when the interaction or information hierarchy needs a real mode change. Do not shrink text, remove labels, duplicate a whole screen or create a phone frame to make a desktop layout fit.
31
31
 
32
+ For rows with long user text and several controls, keep the main text together and let secondary actions wrap as a group (`b3-split` with a `b3-cluster` for actions), or use `b3-row b3-stack` when the content needs a vertical row. A compact `b3-row` does not wrap by itself. Do not force checkbox, label, quantity and removal into a shrinking single line: a page can fit while its label becomes a one-letter column. Inspect readable line length and row height at enlarged text, not just overflow. The playground Data section’s “Long names need room” shows the stacked composition with independently wrapping controls.
33
+
32
34
  Task-first density matters as much as fitting the width. A dashboard should reveal useful data early; a marketing hero should not be reused as its header. When a sidebar becomes mobile navigation, remove duplicated context and relocate secondary links. Preserve primary destinations, readable text and touch targets. Verify the first meaningful content is actually visible at the target phone height, not just free of horizontal overflow.
33
35
 
34
36
  For on-demand navigation, wrap `dialog.b3-dialog[data-b3-placement="end"]` in `<b3-dialog backdrop="dismiss">` with a labeled `nav.b3-nav[data-b3-orientation="vertical"]`, native destination links and an explicit `data-b3-close` button. Open with `data-b3-open="dialog-id"` after importing `@livx.cc/bare-v3/components`. Full-page links navigate normally. For same-page routing, the app must close the drawer and focus the destination after closing; otherwise opener restoration can steal destination focus. Do not duplicate a second hidden navigation tree merely to support another screen size.
@@ -2,6 +2,8 @@
2
2
 
3
3
  Use b3-row for a list or native rows inside b3-table. Layout does not own editing state. Keep field nodes stable; validate and save committed changes synchronously. Retain an edited row while focus is anywhere inside it, even when its new value stops matching the filter. This lets Tab and Shift+Tab reach the other fields before the row disappears.
4
4
 
5
+ Build the candidate state before saving; publish it to committed in-memory state only after persistence succeeds, or explicitly roll back on failure. Otherwise duplicate guards can reject a retry for an item that was never saved or rendered. Keep initial rendering independent of a successful storage write. Preserve the user's input and show a recoverable error; test a failed save followed by a successful retry.
6
+
5
7
  Native change/blur can report activeElement as BODY before the next field receives focus. Capture row ownership on focusin, then reapply filtering only after native focus navigation has settled. Here `list` is the owning ul/ol/tbody, and `matchesFilter(row)` is your app's predicate. Bind before user interaction. These are app functions, not a Bare runtime API.
6
8
 
7
9
  ```js
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@livx.cc/bare-v3",
3
- "version": "0.1.0-alpha.105",
3
+ "version": "0.1.0-alpha.106",
4
4
  "type": "module",
5
5
  "thirdPartyNotices": "./dist/third-party.json",
6
6
  "files": [