@qti-components/base 1.5.1 → 2.0.1

package/dist/styles/drop-region.styles.d.ts

@@ -0,0 +1,36 @@
+/**
+ * The `drop` region of every drop target.
+ *
+ * One rule: **a drop container hosts a chip, it never sizes one.** No `flex: 1`, no stretch, no
+ * centring. The chip's box is decided by the chip — in the drag bank, mid-flight as a clone, and
+ * once dropped — and a container that centres or stretches it makes the drop the one place where
+ * that stops being true. That is felt as the chip jumping the instant it lands.
+ *
+ * `flex: 0 1 auto` on the children says "intrinsic size, no growing, shrink if you must".
+ * `align-items: flex-start` stops the cross axis stretching them, which is the flex default and
+ * the reason a chip in a tall dropzone used to grow to fill it.
+ *
+ * The shrink half used to be 0 as well, on the reading that a drop must not resize a chip. It does
+ * not say that. `flex-shrink: 0` does not preserve the chip's size, it preserves the chip's
+ * UNCONSTRAINED max-content size — and those are the same number only while the bank is wide enough
+ * to give the chip its full width. Once the bank is narrower, the bank chip (`flex: 0 1 auto`, like
+ * any flex item) shrinks and wraps, the placed chip does not, and the two disagree.
+ *
+ * Measured on the order fixture, bank vs placed: 209x36 / 209x36 at a 480px interaction, but
+ * 204x55 / 209x36 at 440px and 154x55 / 209x36 at 340px — the placed chip a fixed 209px wide,
+ * overflowing a drop that had correctly reserved 156px for it. It reached CI as a font difference:
+ * the same label measures ~227px under the Linux fonts, which puts 480px on the wrong side of the
+ * boundary too.
+ *
+ * Shrinking cannot make a placed chip smaller than the reservation, because the reservation IS the
+ * measured chip (`--qti-dropzone-min-*`, applied to this region's content box). So the floor a
+ * shrink stops at is the chip's own size, which is the rule above, not an exception to it.
+ * `flex-grow: 0` is what actually prevents the stretch this block cares about, and it is untouched.
+ *
+ * A container that wants a *minimum* size still declares one (see `--qti-dropzone-min-*`). That
+ * sizes the container, never its contents.
+ *
+ * Verified by drag-drop.invariance.spec.ts: "a chip is the same chip wherever it lives" — including
+ * the narrow-bank order fixture, which is there because the wide one passes either way.
+ */
+export declare const dropRegion: import("lit").CSSResult;

package/dist/styles/drop-region.styles.js

@@ -0,0 +1,78 @@
+import { css } from 'lit';
+/**
+ * The `drop` region of every drop target.
+ *
+ * One rule: **a drop container hosts a chip, it never sizes one.** No `flex: 1`, no stretch, no
+ * centring. The chip's box is decided by the chip — in the drag bank, mid-flight as a clone, and
+ * once dropped — and a container that centres or stretches it makes the drop the one place where
+ * that stops being true. That is felt as the chip jumping the instant it lands.
+ *
+ * `flex: 0 1 auto` on the children says "intrinsic size, no growing, shrink if you must".
+ * `align-items: flex-start` stops the cross axis stretching them, which is the flex default and
+ * the reason a chip in a tall dropzone used to grow to fill it.
+ *
+ * The shrink half used to be 0 as well, on the reading that a drop must not resize a chip. It does
+ * not say that. `flex-shrink: 0` does not preserve the chip's size, it preserves the chip's
+ * UNCONSTRAINED max-content size — and those are the same number only while the bank is wide enough
+ * to give the chip its full width. Once the bank is narrower, the bank chip (`flex: 0 1 auto`, like
+ * any flex item) shrinks and wraps, the placed chip does not, and the two disagree.
+ *
+ * Measured on the order fixture, bank vs placed: 209x36 / 209x36 at a 480px interaction, but
+ * 204x55 / 209x36 at 440px and 154x55 / 209x36 at 340px — the placed chip a fixed 209px wide,
+ * overflowing a drop that had correctly reserved 156px for it. It reached CI as a font difference:
+ * the same label measures ~227px under the Linux fonts, which puts 480px on the wrong side of the
+ * boundary too.
+ *
+ * Shrinking cannot make a placed chip smaller than the reservation, because the reservation IS the
+ * measured chip (`--qti-dropzone-min-*`, applied to this region's content box). So the floor a
+ * shrink stops at is the chip's own size, which is the rule above, not an exception to it.
+ * `flex-grow: 0` is what actually prevents the stretch this block cares about, and it is untouched.
+ *
+ * A container that wants a *minimum* size still declares one (see `--qti-dropzone-min-*`). That
+ * sizes the container, never its contents.
+ *
+ * Verified by drag-drop.invariance.spec.ts: "a chip is the same chip wherever it lives" — including
+ * the narrow-bank order fixture, which is there because the wide one passes either way.
+ */
+export const dropRegion = css `
+  [part~='drop'] {
+    /*
+     * The one deliberate opt-out from the border-box reset.
+     *
+     * --qti-dropzone-min-* is the border-box of the largest chip, and what has to hold that chip is
+     * this region's *content* area. Under border-box a theme's dashed drop border is subtracted
+     * from the chip's own size, the content comes up short, and the drop grows the moment a chip
+     * lands in it. Order's drop did exactly that: 64px empty, 66px full, for a 1px border.
+     */
+    box-sizing: content-box;
+
+    /*
+     * No padding, and no token for one.
+     *
+     * A drop reserves --qti-dropzone-min-*, which is the chip's BORDER-box, as this region's CONTENT
+     * area — so the chip already fits exactly, with nothing to spare and nothing squeezed. An inset
+     * on top would only make the drop bigger than the thing it holds.
+     *
+     * There was a 1px one, to make the drop read as a frame a hair outside the chip. It never painted:
+     * an EMPTY slot has nothing inside the inset to separate from, and a FILLED one hides its edge
+     * (DROP-SIZING.md §4), so both states spent 2px on an invisible ring. The one drop that genuinely
+     * wants breathing room — match's category card — declares padding on its own rule, which a
+     * theme reaches with ::part(drop). A token in between bought nothing.
+     */
+    display: flex;
+    flex-wrap: wrap;
+    align-items: flex-start;
+    justify-content: flex-start;
+    /* No gap either: 0 is the flex initial value, so the declaration only existed to host a token.
+       A drop that wants space between chips sets gap on its own rule. */
+    /* Containing block for anything a theme draws over the drop. Was 'position: relative' in the
+       theme's 'drop' mixin, which put a document stylesheet in charge of a shadow node's position. */
+    position: relative;
+  }
+
+  [part~='drop'] > * {
+    flex: 0 1 auto;
+    align-self: flex-start;
+  }
+`;
+//# sourceMappingURL=drop-region.styles.js.map

package/dist/styles/drop-region.styles.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"drop-region.styles.js","sourceRoot":"","sources":["../../src/styles/drop-region.styles.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,GAAG,EAAE,MAAM,KAAK,CAAC;AAE1B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AACH,MAAM,CAAC,MAAM,UAAU,GAAG,GAAG,CAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwC5B,CAAC","sourcesContent":["import { css } from 'lit';\n\n/**\n * The `drop` region of every drop target.\n *\n * One rule: **a drop container hosts a chip, it never sizes one.** No `flex: 1`, no stretch, no\n * centring. The chip's box is decided by the chip — in the drag bank, mid-flight as a clone, and\n * once dropped — and a container that centres or stretches it makes the drop the one place where\n * that stops being true. That is felt as the chip jumping the instant it lands.\n *\n * `flex: 0 1 auto` on the children says \"intrinsic size, no growing, shrink if you must\".\n * `align-items: flex-start` stops the cross axis stretching them, which is the flex default and\n * the reason a chip in a tall dropzone used to grow to fill it.\n *\n * The shrink half used to be 0 as well, on the reading that a drop must not resize a chip. It does\n * not say that. `flex-shrink: 0` does not preserve the chip's size, it preserves the chip's\n * UNCONSTRAINED max-content size — and those are the same number only while the bank is wide enough\n * to give the chip its full width. Once the bank is narrower, the bank chip (`flex: 0 1 auto`, like\n * any flex item) shrinks and wraps, the placed chip does not, and the two disagree.\n *\n * Measured on the order fixture, bank vs placed: 209x36 / 209x36 at a 480px interaction, but\n * 204x55 / 209x36 at 440px and 154x55 / 209x36 at 340px — the placed chip a fixed 209px wide,\n * overflowing a drop that had correctly reserved 156px for it. It reached CI as a font difference:\n * the same label measures ~227px under the Linux fonts, which puts 480px on the wrong side of the\n * boundary too.\n *\n * Shrinking cannot make a placed chip smaller than the reservation, because the reservation IS the\n * measured chip (`--qti-dropzone-min-*`, applied to this region's content box). So the floor a\n * shrink stops at is the chip's own size, which is the rule above, not an exception to it.\n * `flex-grow: 0` is what actually prevents the stretch this block cares about, and it is untouched.\n *\n * A container that wants a *minimum* size still declares one (see `--qti-dropzone-min-*`). That\n * sizes the container, never its contents.\n *\n * Verified by drag-drop.invariance.spec.ts: \"a chip is the same chip wherever it lives\" — including\n * the narrow-bank order fixture, which is there because the wide one passes either way.\n */\nexport const dropRegion = css`\n  [part~='drop'] {\n    /*\n     * The one deliberate opt-out from the border-box reset.\n     *\n     * --qti-dropzone-min-* is the border-box of the largest chip, and what has to hold that chip is\n     * this region's *content* area. Under border-box a theme's dashed drop border is subtracted\n     * from the chip's own size, the content comes up short, and the drop grows the moment a chip\n     * lands in it. Order's drop did exactly that: 64px empty, 66px full, for a 1px border.\n     */\n    box-sizing: content-box;\n\n    /*\n     * No padding, and no token for one.\n     *\n     * A drop reserves --qti-dropzone-min-*, which is the chip's BORDER-box, as this region's CONTENT\n     * area — so the chip already fits exactly, with nothing to spare and nothing squeezed. An inset\n     * on top would only make the drop bigger than the thing it holds.\n     *\n     * There was a 1px one, to make the drop read as a frame a hair outside the chip. It never painted:\n     * an EMPTY slot has nothing inside the inset to separate from, and a FILLED one hides its edge\n     * (DROP-SIZING.md §4), so both states spent 2px on an invisible ring. The one drop that genuinely\n     * wants breathing room — match's category card — declares padding on its own rule, which a\n     * theme reaches with ::part(drop). A token in between bought nothing.\n     */\n    display: flex;\n    flex-wrap: wrap;\n    align-items: flex-start;\n    justify-content: flex-start;\n    /* No gap either: 0 is the flex initial value, so the declaration only existed to host a token.\n       A drop that wants space between chips sets gap on its own rule. */\n    /* Containing block for anything a theme draws over the drop. Was 'position: relative' in the\n       theme's 'drop' mixin, which put a document stylesheet in charge of a shadow node's position. */\n    position: relative;\n  }\n\n  [part~='drop'] > * {\n    flex: 0 1 auto;\n    align-self: flex-start;\n  }\n`;\n"]}

package/dist/styles/validation-message.styles.d.ts

@@ -0,0 +1,18 @@
+/**
+ * The `#validation-message` region every interaction renders, hidden until there is a message.
+ *
+ * `Interaction` owns showing and hiding it: `reportValidity` sets
+ * `display: block !important` inline when `_internals.validationMessage` is non-empty, and clears the
+ * text and sets `display: none` inline again when it is not (see interaction.ts). An inline
+ * `!important` beats this rule, so the JS still wins whenever it speaks.
+ *
+ * What it did not own was the *initial* state. Before first validation the div has no inline style,
+ * so it needs a stylesheet to start hidden — otherwise it paints as an empty box with the theme's
+ * warning border and padding. That hide used to be a `display: none` inside the theme's
+ * `validation-message` mixin, which made a document stylesheet responsible for a shadow node's box.
+ * Two components had already noticed and worked around it with `style="display:none"` in their
+ * template; the other five relied on the theme.
+ *
+ * The theme still paints the message — colour, border, padding, radius — via `::part(message)`.
+ */
+export declare const validationMessage: import("lit").CSSResult;

package/dist/styles/validation-message.styles.js

@@ -0,0 +1,24 @@
+import { css } from 'lit';
+/**
+ * The `#validation-message` region every interaction renders, hidden until there is a message.
+ *
+ * `Interaction` owns showing and hiding it: `reportValidity` sets
+ * `display: block !important` inline when `_internals.validationMessage` is non-empty, and clears the
+ * text and sets `display: none` inline again when it is not (see interaction.ts). An inline
+ * `!important` beats this rule, so the JS still wins whenever it speaks.
+ *
+ * What it did not own was the *initial* state. Before first validation the div has no inline style,
+ * so it needs a stylesheet to start hidden — otherwise it paints as an empty box with the theme's
+ * warning border and padding. That hide used to be a `display: none` inside the theme's
+ * `validation-message` mixin, which made a document stylesheet responsible for a shadow node's box.
+ * Two components had already noticed and worked around it with `style="display:none"` in their
+ * template; the other five relied on the theme.
+ *
+ * The theme still paints the message — colour, border, padding, radius — via `::part(message)`.
+ */
+export const validationMessage = css `
+  [part~='message'] {
+    display: none;
+  }
+`;
+//# sourceMappingURL=validation-message.styles.js.map

package/dist/styles/validation-message.styles.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"validation-message.styles.js","sourceRoot":"","sources":["../../src/styles/validation-message.styles.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,GAAG,EAAE,MAAM,KAAK,CAAC;AAE1B;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,CAAC,MAAM,iBAAiB,GAAG,GAAG,CAAA;;;;CAInC,CAAC","sourcesContent":["import { css } from 'lit';\n\n/**\n * The `#validation-message` region every interaction renders, hidden until there is a message.\n *\n * `Interaction` owns showing and hiding it: `reportValidity` sets\n * `display: block !important` inline when `_internals.validationMessage` is non-empty, and clears the\n * text and sets `display: none` inline again when it is not (see interaction.ts). An inline\n * `!important` beats this rule, so the JS still wins whenever it speaks.\n *\n * What it did not own was the *initial* state. Before first validation the div has no inline style,\n * so it needs a stylesheet to start hidden — otherwise it paints as an empty box with the theme's\n * warning border and padding. That hide used to be a `display: none` inside the theme's\n * `validation-message` mixin, which made a document stylesheet responsible for a shadow node's box.\n * Two components had already noticed and worked around it with `style=\"display:none\"` in their\n * template; the other five relied on the theme.\n *\n * The theme still paints the message — colour, border, padding, radius — via `::part(message)`.\n */\nexport const validationMessage = css`\n  [part~='message'] {\n    display: none;\n  }\n`;\n"]}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@qti-components/base",
   "description": "QTI shared utilities",
-  "version": "1.5.1",
+  "version": "2.0.1",
   "author": "",
   "dependencies": {
     "@qti-components/utilities": "^1.3.3"
@@ -16,6 +16,21 @@
   ],
   "license": "GPL-3.0-only",
   "main": "dist/index.js",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js"
+    },
+    "./elements": {
+      "types": "./dist/elements.d.ts",
+      "import": "./dist/elements.js"
+    },
+    "./register": {
+      "types": "./dist/register.d.ts",
+      "import": "./dist/register.js"
+    },
+    "./*": "./dist/*"
+  },
   "peerDependencies": {
     "@lit/context": "^1.1.6",
     "lit": "^3.3.1"

package/dist/context/qti-assessment-item.context.d.ts

@@ -1,4 +0,0 @@
-import type { ItemContext } from './item.context';
-export declare const itemContext: {
-    __context__: ItemContext;
-};

package/dist/context/qti-assessment-item.context.js

@@ -1,3 +0,0 @@
-import { createContext } from '@lit/context';
-export const itemContext = createContext(Symbol('item'));
-//# sourceMappingURL=qti-assessment-item.context.js.map

package/dist/context/qti-assessment-item.context.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"qti-assessment-item.context.js","sourceRoot":"","sources":["../../src/context/qti-assessment-item.context.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,aAAa,EAAE,MAAM,cAAc,CAAC;AAI7C,MAAM,CAAC,MAAM,WAAW,GAAG,aAAa,CAAc,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC","sourcesContent":["import { createContext } from '@lit/context';\n\nimport type { ItemContext } from './item.context';\n\nexport const itemContext = createContext<ItemContext>(Symbol('item'));\n"]}