@fusion.dev/helix-headless 0.1.0 → 0.3.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fusion.dev/helix-headless",
   "description": "Headless component tier. Structure, accessibility, state, and form participation. No styling.",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "license": "MIT",
   "author": "Ross Sheppard <ross.sheppard@fusion.dev>",
   "repository": {
@@ -38,7 +38,7 @@
   ],
   "scripts": {
     "analyze": "cem analyze --config custom-elements-manifest.config.ts",
-    "build": "tsc -p tsconfig.json",
+    "build": "tsc -p tsconfig.json && tsc -p tsconfig.types.json",
     "test": "bun run test:pure && bun run test:dom && bun run test:ssr",
     "test:dom": "bun test dom.spec",
     "test:pure": "bun test pure.spec",
@@ -47,15 +47,15 @@
   },
   "bugs": "https://github.com/project-fusion/fusion/issues",
   "dependencies": {
-    "@fusion.dev/helix-core": "0.1.0",
-    "@fusion.dev/helix-icons": "0.1.0",
+    "@fusion.dev/helix-core": "0.3.0",
+    "@fusion.dev/helix-icons": "0.3.0",
     "uqr": "^0.1.3"
   },
   "devDependencies": {
     "@custom-elements-manifest/analyzer": "^0.11.0",
     "@happy-dom/global-registrator": "^20.0.0",
-    "@fusion.dev/helix-cem": "0.1.0",
-    "@fusion.dev/helix-testing": "0.1.0",
+    "@fusion.dev/helix-cem": "0.3.0",
+    "@fusion.dev/helix-testing": "0.3.0",
     "@lit-labs/ssr": "^3.3.0",
     "@types/bun": "^1.3.0",
     "lit": "^3.2.1"

package/vue.d.ts

@@ -8657,7 +8657,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessVideoPlaylistVueProps,
     HelixHeadlessVideoPlaylistVueEvents
   >;
-  /** **The picture is a real '<video>'.** Decoding, buffering, captions, Picture in Picture, AirPlay and the codecs a device happens to have are all the platform's, and none of them can be had from anything else. What is replaced is the control bar, which is the one part of a video element that cannot be styled and looks different in every browser.  **Every control is a real control.** The scrubber and the volume are '<input type="range">', so a reader gets arrow keys, Home and End, the platform's own touch target and its screen reader announcement without this element implementing any of it. Drawing a div and listening for pointer moves is how a media player ends up unusable from a keyboard.  **Native controls are the fallback, not the default.** Where a consumer sets 'controls', the browser's bar is used and this one is not drawn: two sets of controls over one video is worse than either alone, and a consumer who asked for the native bar has a reason.  The keys are the ones every player uses: Space and 'k' to play or pause, the arrows to seek and to change the volume, 'm' to mute, 'f' for fullscreen. They are bound on this element rather than on the document, because a video is not a palette: keys belong to it only while a reader is on it.  **And none of them where 'controls' is set.** The browser's own bar owns those keys, and two handlers on one press is a video that seeks twice or plays and immediately pauses. The focus stop goes with them, since the native controls bring their own.  **'<source>' and '<track>' are copied into the video, not slotted into it.** A media element runs its resource selection over its own child *nodes*, and a slot is one node: the sources and the caption tracks a consumer wrote were assigned into the flattened tree and the video never saw any of them. It had no text tracks, no current source and a 'readyState' of zero, so a video given sources this way did not merely lack captions, it did not play.  They are copied rather than moved, because the consumer's light DOM is theirs and a framework that re-renders it would find its children gone. The copies are rebuilt whenever the slot changes and the video is asked to load again, which is what makes a '<track>' added later take effect.  **The lock screen and a headset's buttons work, and one player owns them.** There is one 'navigator.mediaSession' per page, so the rule is stated rather than left to render order: whichever player was started last owns it, which is what a reader means by "this one" when they press play on their headphones. The title comes from 'label' and the artwork from 'poster'.  **'remote' sends the picture somewhere else.** The Remote Playback API is what Safari implements for AirPlay and Chrome for Cast, so one control covers both and the platform supplies the device list. It is offered only once something has answered 'watchAvailability': a button that opens an empty list is worse than no button, and a consumer who wants none can set 'disableremoteplayback' on this element.  The properties below are written by this component and read by whoever draws it. A consumer sets none of them: they carry a number this element computed and CSS cannot, which is what lets a stylesheet on this tier draw the thing without measuring anything itself. */
+  /** **The picture is a real '<video>'.** Decoding, buffering, captions, Picture in Picture, AirPlay and the codecs a device happens to have are all the platform's, and none of them can be had from anything else. What is replaced is the control bar, which is the one part of a video element that cannot be styled and looks different in every browser.  **Every control is a real control.** The scrubber and the volume are '<input type="range">', so a reader gets arrow keys, Home and End, the platform's own touch target and its screen reader announcement without this element implementing any of it. Drawing a div and listening for pointer moves is how a media player ends up unusable from a keyboard.  **Native controls are the fallback, not the default.** Where a consumer sets 'controls', the browser's bar is used and this one is not drawn: two sets of controls over one video is worse than either alone, and a consumer who asked for the native bar has a reason.  The keys are the ones every player uses: Space and 'k' to play or pause, the arrows to seek and to change the volume, 'm' to mute, 'f' for fullscreen. They are bound on this element rather than on the document, because a video is not a palette: keys belong to it only while a reader is on it. Where 'controls' is set they are not bound at all, since two handlers on one press is a video that seeks twice, and the focus stop goes with them.  **'<source>' and '<track>' are copied into the video, never slotted into it.** A media element runs resource selection over its own child *nodes*, and a slot is one node, so slotted sources reach it as nothing: no text tracks, no current source, 'readyState' zero. A video given sources that way does not merely lack captions, it does not play.  They are copied rather than moved, because the consumer's light DOM is theirs and a framework that re-renders it would find its children gone. The copies are rebuilt whenever the slot changes and the video is asked to load again, which is what makes a '<track>' added later take effect.  **The lock screen and a headset's buttons work, and one player owns them.** There is one 'navigator.mediaSession' per page, so the rule is stated rather than left to render order: whichever player was started last owns it, which is what a reader means by "this one" when they press play on their headphones. The title comes from 'label' and the artwork from 'poster'.  **'remote' sends the picture somewhere else.** The Remote Playback API is what Safari implements for AirPlay and Chrome for Cast, so one control covers both and the platform supplies the device list. It is offered only once something has answered 'watchAvailability': a button that opens an empty list is worse than no button, and a consumer who wants none can set 'disableremoteplayback' on this element.  The properties below are written by this component and read by whoever draws it. A consumer sets none of them: they carry a number this element computed and CSS cannot, which is what lets a stylesheet on this tier draw the thing without measuring anything itself. */
   "helix-headless-video": DefineCustomElement<
     HelixHeadlessVideo,
     HelixHeadlessVideoVueProps,