use-wc 1.0.0-pre.56 → 1.0.0-pre.57
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.
- package/custom-elements.json +65 -65
- package/dist/tokens.css +3 -3
- package/package.json +1 -1
- package/vscode.html-custom-data.json +6 -6
package/custom-elements.json
CHANGED
|
@@ -702,71 +702,6 @@
|
|
|
702
702
|
}
|
|
703
703
|
]
|
|
704
704
|
},
|
|
705
|
-
{
|
|
706
|
-
"kind": "javascript-module",
|
|
707
|
-
"path": "src/elements/use-caret/use-caret.ts",
|
|
708
|
-
"declarations": [
|
|
709
|
-
{
|
|
710
|
-
"kind": "class",
|
|
711
|
-
"description": "`use-caret` supplies the caret icon and label layout for a consumer who wants to own the\ninvoking button itself. It renders inside a plain `<button>`\nthat carries the native `popovertarget` attribute, pointing at a `use-menu`:\n\n```html\n<button id=\"thing\" popovertarget=\"thing-menu\">\n <use-caret>Menu</use-caret>\n</button>\n<use-menu id=\"thing-menu\" aria-label=\"Menu\">\n <button role=\"menuitem\">First thing</button>\n</use-menu>\n```\n\n`use-menu` finds this button on its own via `popovertarget` and anchors to it — no\n`anchortarget` needed here; that's only for a menu with more than one invoker. See `use-menu`'s\nown docs for that case.\n\nThe button is entirely the consumer's own element — their classes, their content, their event\nhandlers. `use-caret` contributes no interactivity of its own: no internal button, no focus\ntarget, no state. It only renders the label and caret glyph, so consumers get a consistent\nvisual trigger without giving up control of the button.\n\nThe caret direction is derived rather than configured: a trigger nested inside a `use-menu`\nis understood to open a submenu and renders pointing sideways; a top-level trigger renders\npointing down.\n\nSwapping in a different caret **per instance** is a slot: put your own element in the `icon`\nslot and it replaces `part(icon-default)` entirely for that trigger.\n\nSwapping the default caret **for every trigger in the app** doesn't need touching this\ncomponent's `render()` at all — style `::part(icon-default)` from an outside stylesheet, the\nsame way any shadow DOM part is themed:\n\n```css\nuse-caret::part(icon-default) {\n mask-image: url(\"/icons/my-caret.svg\");\n}\n```\n\n(When the design system's `theme.css` is loaded, this is already wired to a token —\n`--usewc-effect-dropdown-trigger-icon-mask-image` — so redefining that custom property has\nthe same effect without writing a `::part()` rule at all.)\n\n`::part()` only reaches CSS-expressible changes (a mask, a background, a transform). For\nanything else — different markup, an icon font, logic beyond a mask — set the static `icon`\nand `nestedIcon` hooks. Every `<use-caret>` in the page picks them up; consumers keep writing\nthe same tag, no new element to register or remember to use instead. `icon` supplies a\ntop-level trigger's glyph, `nestedIcon` a submenu trigger's — set whichever apply; an unset one\nkeeps the built-in ▼/▶ for that case. Set them once, as early as possible (an app's entry\npoint, before any triggers connect) — Lit calls `render()` fresh on every update, so an\nalready-connected instance only reflects the change once something causes it to re-render:\n\n```ts\n// A bare string or TemplateResult is used as-is, on every trigger of that kind:\nUseCaret.icon = \"▾\";\nUseCaret.nestedIcon = \"▸\";\n\n// A function is called on every render instead:\nUseCaret.nestedIcon = (html) => html`<my-icon name=\"chevron-right\"></my-icon>`;\n```\n\nThe function form is called with the component's own `html` tag as its (optional) first\nargument rather than requiring the caller to import one — a page can end up with more than one\ncopy of `lit-html` in its module graph, and a `TemplateResult` built from a *different* copy\nthan the one this component renders with can silently fail to render. Taking `html` in as a\nparameter sidesteps that: whatever's returned is guaranteed to come from the same `lit-html`\nthis component already uses. A bare string skips the concern entirely.\n\nOnly need to change the icon on **some** triggers, not every one in the app? Extend the\nclass, override `render()` normally, and register the subclass under a different tag name so\nit coexists with the built-in element instead of replacing it everywhere:\n\n```ts\nclass MyCaret extends UseCaret {\n override render() {\n return html`<slot></slot><slot name=\"icon\"><my-icon name=\"chevron\"></my-icon></slot>`;\n }\n}\ncustomElements.define(\"my-caret\", MyCaret);\n```",
|
|
712
|
-
"name": "UseCaret",
|
|
713
|
-
"slots": [
|
|
714
|
-
{
|
|
715
|
-
"description": "Trigger label content.",
|
|
716
|
-
"name": "default"
|
|
717
|
-
},
|
|
718
|
-
{
|
|
719
|
-
"description": "Replaces the default caret glyph.",
|
|
720
|
-
"name": "icon"
|
|
721
|
-
}
|
|
722
|
-
],
|
|
723
|
-
"members": [
|
|
724
|
-
{
|
|
725
|
-
"kind": "field",
|
|
726
|
-
"name": "icon",
|
|
727
|
-
"type": {
|
|
728
|
-
"text": "((html: HtmlTag) => TemplateResult | string) | TemplateResult | string | undefined"
|
|
729
|
-
},
|
|
730
|
-
"static": true,
|
|
731
|
-
"description": "Global override for a top-level trigger's caret. When set, every non-nested `<use-caret>` in\nthe page renders this inside `part(icon-default)` instead of the built-in ▼ character. A\nplain string or `TemplateResult` is used as-is; the function form is called with the\ncomponent's own `html` tag, so a returned template is guaranteed to come from the same\n`lit-html` instance this component renders with. Unset (the default) keeps the built-in ▼."
|
|
732
|
-
},
|
|
733
|
-
{
|
|
734
|
-
"kind": "field",
|
|
735
|
-
"name": "nestedIcon",
|
|
736
|
-
"type": {
|
|
737
|
-
"text": "((html: HtmlTag) => TemplateResult | string) | TemplateResult | string | undefined"
|
|
738
|
-
},
|
|
739
|
-
"static": true,
|
|
740
|
-
"description": "Global override for a submenu trigger's caret — the counterpart to icon for a\n`<use-caret>` nested inside a `use-menu`. Unset (the default) keeps the built-in ▶."
|
|
741
|
-
}
|
|
742
|
-
],
|
|
743
|
-
"superclass": {
|
|
744
|
-
"name": "LitElement",
|
|
745
|
-
"package": "lit"
|
|
746
|
-
},
|
|
747
|
-
"tagName": "use-caret",
|
|
748
|
-
"customElement": true
|
|
749
|
-
}
|
|
750
|
-
],
|
|
751
|
-
"exports": [
|
|
752
|
-
{
|
|
753
|
-
"kind": "js",
|
|
754
|
-
"name": "UseCaret",
|
|
755
|
-
"declaration": {
|
|
756
|
-
"name": "UseCaret",
|
|
757
|
-
"module": "src/elements/use-caret/use-caret.ts"
|
|
758
|
-
}
|
|
759
|
-
},
|
|
760
|
-
{
|
|
761
|
-
"kind": "custom-element-definition",
|
|
762
|
-
"name": "use-caret",
|
|
763
|
-
"declaration": {
|
|
764
|
-
"name": "UseCaret",
|
|
765
|
-
"module": "src/elements/use-caret/use-caret.ts"
|
|
766
|
-
}
|
|
767
|
-
}
|
|
768
|
-
]
|
|
769
|
-
},
|
|
770
705
|
{
|
|
771
706
|
"kind": "javascript-module",
|
|
772
707
|
"path": "src/elements/use-date-input/use-date-input.ts",
|
|
@@ -893,6 +828,71 @@
|
|
|
893
828
|
}
|
|
894
829
|
]
|
|
895
830
|
},
|
|
831
|
+
{
|
|
832
|
+
"kind": "javascript-module",
|
|
833
|
+
"path": "src/elements/use-caret/use-caret.ts",
|
|
834
|
+
"declarations": [
|
|
835
|
+
{
|
|
836
|
+
"kind": "class",
|
|
837
|
+
"description": "`use-caret` supplies the caret icon and label layout for a consumer who wants to own the\ninvoking button itself. It renders inside a plain `<button>`\nthat carries the native `popovertarget` attribute, pointing at a `use-menu`:\n\n```html\n<button id=\"thing\" popovertarget=\"thing-menu\">\n <use-caret>Menu</use-caret>\n</button>\n<use-menu id=\"thing-menu\" aria-label=\"Menu\">\n <button role=\"menuitem\">First thing</button>\n</use-menu>\n```\n\n`use-menu` finds this button on its own via `popovertarget` and anchors to it — no\n`anchortarget` needed here; that's only for a menu with more than one invoker. See `use-menu`'s\nown docs for that case.\n\nThe button is entirely the consumer's own element — their classes, their content, their event\nhandlers. `use-caret` contributes no interactivity of its own: no internal button, no focus\ntarget, no state. It only renders the label and caret glyph, so consumers get a consistent\nvisual trigger without giving up control of the button.\n\nThe caret direction is derived rather than configured: a trigger nested inside a `use-menu`\nis understood to open a submenu and renders pointing sideways; a top-level trigger renders\npointing down.\n\nSwapping in a different caret **per instance** is a slot: put your own element in the `icon`\nslot and it replaces `part(icon-default)` entirely for that trigger.\n\nSwapping the default caret **for every trigger in the app** doesn't need touching this\ncomponent's `render()` at all — style `::part(icon-default)` from an outside stylesheet, the\nsame way any shadow DOM part is themed:\n\n```css\nuse-caret::part(icon-default) {\n mask-image: url(\"/icons/my-caret.svg\");\n}\n```\n\n(When the design system's `theme.css` is loaded, this is already wired to a token —\n`--usewc-effect-dropdown-trigger-icon-mask-image` — so redefining that custom property has\nthe same effect without writing a `::part()` rule at all.)\n\n`::part()` only reaches CSS-expressible changes (a mask, a background, a transform). For\nanything else — different markup, an icon font, logic beyond a mask — set the static `icon`\nand `nestedIcon` hooks. Every `<use-caret>` in the page picks them up; consumers keep writing\nthe same tag, no new element to register or remember to use instead. `icon` supplies a\ntop-level trigger's glyph, `nestedIcon` a submenu trigger's — set whichever apply; an unset one\nkeeps the built-in ▼/▶ for that case. Set them once, as early as possible (an app's entry\npoint, before any triggers connect) — Lit calls `render()` fresh on every update, so an\nalready-connected instance only reflects the change once something causes it to re-render:\n\n```ts\n// A bare string or TemplateResult is used as-is, on every trigger of that kind:\nUseCaret.icon = \"▾\";\nUseCaret.nestedIcon = \"▸\";\n\n// A function is called on every render instead:\nUseCaret.nestedIcon = (html) => html`<my-icon name=\"chevron-right\"></my-icon>`;\n```\n\nThe function form is called with the component's own `html` tag as its (optional) first\nargument rather than requiring the caller to import one — a page can end up with more than one\ncopy of `lit-html` in its module graph, and a `TemplateResult` built from a *different* copy\nthan the one this component renders with can silently fail to render. Taking `html` in as a\nparameter sidesteps that: whatever's returned is guaranteed to come from the same `lit-html`\nthis component already uses. A bare string skips the concern entirely.\n\nOnly need to change the icon on **some** triggers, not every one in the app? Extend the\nclass, override `render()` normally, and register the subclass under a different tag name so\nit coexists with the built-in element instead of replacing it everywhere:\n\n```ts\nclass MyCaret extends UseCaret {\n override render() {\n return html`<slot></slot><slot name=\"icon\"><my-icon name=\"chevron\"></my-icon></slot>`;\n }\n}\ncustomElements.define(\"my-caret\", MyCaret);\n```",
|
|
838
|
+
"name": "UseCaret",
|
|
839
|
+
"slots": [
|
|
840
|
+
{
|
|
841
|
+
"description": "Trigger label content.",
|
|
842
|
+
"name": "default"
|
|
843
|
+
},
|
|
844
|
+
{
|
|
845
|
+
"description": "Replaces the default caret glyph.",
|
|
846
|
+
"name": "icon"
|
|
847
|
+
}
|
|
848
|
+
],
|
|
849
|
+
"members": [
|
|
850
|
+
{
|
|
851
|
+
"kind": "field",
|
|
852
|
+
"name": "icon",
|
|
853
|
+
"type": {
|
|
854
|
+
"text": "((html: HtmlTag) => TemplateResult | string) | TemplateResult | string | undefined"
|
|
855
|
+
},
|
|
856
|
+
"static": true,
|
|
857
|
+
"description": "Global override for a top-level trigger's caret. When set, every non-nested `<use-caret>` in\nthe page renders this inside `part(icon-default)` instead of the built-in ▼ character. A\nplain string or `TemplateResult` is used as-is; the function form is called with the\ncomponent's own `html` tag, so a returned template is guaranteed to come from the same\n`lit-html` instance this component renders with. Unset (the default) keeps the built-in ▼."
|
|
858
|
+
},
|
|
859
|
+
{
|
|
860
|
+
"kind": "field",
|
|
861
|
+
"name": "nestedIcon",
|
|
862
|
+
"type": {
|
|
863
|
+
"text": "((html: HtmlTag) => TemplateResult | string) | TemplateResult | string | undefined"
|
|
864
|
+
},
|
|
865
|
+
"static": true,
|
|
866
|
+
"description": "Global override for a submenu trigger's caret — the counterpart to icon for a\n`<use-caret>` nested inside a `use-menu`. Unset (the default) keeps the built-in ▶."
|
|
867
|
+
}
|
|
868
|
+
],
|
|
869
|
+
"superclass": {
|
|
870
|
+
"name": "LitElement",
|
|
871
|
+
"package": "lit"
|
|
872
|
+
},
|
|
873
|
+
"tagName": "use-caret",
|
|
874
|
+
"customElement": true
|
|
875
|
+
}
|
|
876
|
+
],
|
|
877
|
+
"exports": [
|
|
878
|
+
{
|
|
879
|
+
"kind": "js",
|
|
880
|
+
"name": "UseCaret",
|
|
881
|
+
"declaration": {
|
|
882
|
+
"name": "UseCaret",
|
|
883
|
+
"module": "src/elements/use-caret/use-caret.ts"
|
|
884
|
+
}
|
|
885
|
+
},
|
|
886
|
+
{
|
|
887
|
+
"kind": "custom-element-definition",
|
|
888
|
+
"name": "use-caret",
|
|
889
|
+
"declaration": {
|
|
890
|
+
"name": "UseCaret",
|
|
891
|
+
"module": "src/elements/use-caret/use-caret.ts"
|
|
892
|
+
}
|
|
893
|
+
}
|
|
894
|
+
]
|
|
895
|
+
},
|
|
896
896
|
{
|
|
897
897
|
"kind": "javascript-module",
|
|
898
898
|
"path": "src/elements/use-date-picker/use-date-picker.ts",
|
package/dist/tokens.css
CHANGED
|
@@ -548,15 +548,15 @@
|
|
|
548
548
|
--usewc-layout-popover-menu-item-padding-block: var(--usewc-space-2);
|
|
549
549
|
--usewc-layout-popover-menu-item-line-height: var(--usewc-line-height-24);
|
|
550
550
|
--usewc-color-popover-menu-item-background-static: var(--usewc-color-transparent);
|
|
551
|
-
--usewc-color-popover-menu-item-background-hover: var(--usewc-color-
|
|
552
|
-
--usewc-color-popover-menu-item-background-active: var(--usewc-color-
|
|
551
|
+
--usewc-color-popover-menu-item-background-hover: var(--usewc-color-selector-background-hover);
|
|
552
|
+
--usewc-color-popover-menu-item-background-active: var(--usewc-color-selector-background-hover);
|
|
553
553
|
--usewc-effect-popover-menu-item-border-radius: var(--usewc-effect-border-radius-4);
|
|
554
554
|
--usewc-layout-popover-menu-anchor-offset: var(--usewc-space-4);
|
|
555
555
|
--usewc-layout-popover-menu-padding: var(--usewc-space-4);
|
|
556
556
|
--usewc-layout-popover-menu-border: var(--usewc-space-1-relative);
|
|
557
557
|
--usewc-effect-popover-menu-border-style: var(--usewc-effect-border-solid);
|
|
558
558
|
--usewc-color-popover-menu-background: var(--usewc-color-canvas-background);
|
|
559
|
-
--usewc-color-popover-menu-border: var(--usewc-color-
|
|
559
|
+
--usewc-color-popover-menu-border: var(--usewc-color-button-base-border-static);
|
|
560
560
|
--usewc-effect-popover-menu-border-radius: var(--usewc-effect-border-radius-8);
|
|
561
561
|
--usewc-font-popover-menu-header-size: var(--usewc-font-size-14);
|
|
562
562
|
--usewc-font-popover-menu-header-weight: var(--usewc-font-weight-medium);
|
package/package.json
CHANGED
|
@@ -57,12 +57,6 @@
|
|
|
57
57
|
"attributes": [{ "name": "date", "values": [] }],
|
|
58
58
|
"references": []
|
|
59
59
|
},
|
|
60
|
-
{
|
|
61
|
-
"name": "use-caret",
|
|
62
|
-
"description": "`use-caret` supplies the caret icon and label layout for a consumer who wants to own the\ninvoking button itself. It renders inside a plain `<button>`\nthat carries the native `popovertarget` attribute, pointing at a `use-menu`:\n\n```html\n<button id=\"thing\" popovertarget=\"thing-menu\">\n <use-caret>Menu</use-caret>\n</button>\n<use-menu id=\"thing-menu\" aria-label=\"Menu\">\n <button role=\"menuitem\">First thing</button>\n</use-menu>\n```\n\n`use-menu` finds this button on its own via `popovertarget` and anchors to it — no\n`anchortarget` needed here; that's only for a menu with more than one invoker. See `use-menu`'s\nown docs for that case.\n\nThe button is entirely the consumer's own element — their classes, their content, their event\nhandlers. `use-caret` contributes no interactivity of its own: no internal button, no focus\ntarget, no state. It only renders the label and caret glyph, so consumers get a consistent\nvisual trigger without giving up control of the button.\n\nThe caret direction is derived rather than configured: a trigger nested inside a `use-menu`\nis understood to open a submenu and renders pointing sideways; a top-level trigger renders\npointing down.\n\nSwapping in a different caret **per instance** is a slot: put your own element in the `icon`\nslot and it replaces `part(icon-default)` entirely for that trigger.\n\nSwapping the default caret **for every trigger in the app** doesn't need touching this\ncomponent's `render()` at all — style `::part(icon-default)` from an outside stylesheet, the\nsame way any shadow DOM part is themed:\n\n```css\nuse-caret::part(icon-default) {\n mask-image: url(\"/icons/my-caret.svg\");\n}\n```\n\n(When the design system's `theme.css` is loaded, this is already wired to a token —\n`--usewc-effect-dropdown-trigger-icon-mask-image` — so redefining that custom property has\nthe same effect without writing a `::part()` rule at all.)\n\n`::part()` only reaches CSS-expressible changes (a mask, a background, a transform). For\nanything else — different markup, an icon font, logic beyond a mask — set the static `icon`\nand `nestedIcon` hooks. Every `<use-caret>` in the page picks them up; consumers keep writing\nthe same tag, no new element to register or remember to use instead. `icon` supplies a\ntop-level trigger's glyph, `nestedIcon` a submenu trigger's — set whichever apply; an unset one\nkeeps the built-in ▼/▶ for that case. Set them once, as early as possible (an app's entry\npoint, before any triggers connect) — Lit calls `render()` fresh on every update, so an\nalready-connected instance only reflects the change once something causes it to re-render:\n\n```ts\n// A bare string or TemplateResult is used as-is, on every trigger of that kind:\nUseCaret.icon = \"▾\";\nUseCaret.nestedIcon = \"▸\";\n\n// A function is called on every render instead:\nUseCaret.nestedIcon = (html) => html`<my-icon name=\"chevron-right\"></my-icon>`;\n```\n\nThe function form is called with the component's own `html` tag as its (optional) first\nargument rather than requiring the caller to import one — a page can end up with more than one\ncopy of `lit-html` in its module graph, and a `TemplateResult` built from a *different* copy\nthan the one this component renders with can silently fail to render. Taking `html` in as a\nparameter sidesteps that: whatever's returned is guaranteed to come from the same `lit-html`\nthis component already uses. A bare string skips the concern entirely.\n\nOnly need to change the icon on **some** triggers, not every one in the app? Extend the\nclass, override `render()` normally, and register the subclass under a different tag name so\nit coexists with the built-in element instead of replacing it everywhere:\n\n```ts\nclass MyCaret extends UseCaret {\n override render() {\n return html`<slot></slot><slot name=\"icon\"><my-icon name=\"chevron\"></my-icon></slot>`;\n }\n}\ncustomElements.define(\"my-caret\", MyCaret);\n```\n---\n\n\n### **Slots:**\n - **default** - Trigger label content.\n- **icon** - Replaces the default caret glyph.",
|
|
63
|
-
"attributes": [],
|
|
64
|
-
"references": []
|
|
65
|
-
},
|
|
66
60
|
{
|
|
67
61
|
"name": "use-date-input",
|
|
68
62
|
"description": "Displays a date picker using segmented inputs for year, month, and day.\n\nUses browser locale for formatting and ARIA labels.\n---\n",
|
|
@@ -74,6 +68,12 @@
|
|
|
74
68
|
],
|
|
75
69
|
"references": []
|
|
76
70
|
},
|
|
71
|
+
{
|
|
72
|
+
"name": "use-caret",
|
|
73
|
+
"description": "`use-caret` supplies the caret icon and label layout for a consumer who wants to own the\ninvoking button itself. It renders inside a plain `<button>`\nthat carries the native `popovertarget` attribute, pointing at a `use-menu`:\n\n```html\n<button id=\"thing\" popovertarget=\"thing-menu\">\n <use-caret>Menu</use-caret>\n</button>\n<use-menu id=\"thing-menu\" aria-label=\"Menu\">\n <button role=\"menuitem\">First thing</button>\n</use-menu>\n```\n\n`use-menu` finds this button on its own via `popovertarget` and anchors to it — no\n`anchortarget` needed here; that's only for a menu with more than one invoker. See `use-menu`'s\nown docs for that case.\n\nThe button is entirely the consumer's own element — their classes, their content, their event\nhandlers. `use-caret` contributes no interactivity of its own: no internal button, no focus\ntarget, no state. It only renders the label and caret glyph, so consumers get a consistent\nvisual trigger without giving up control of the button.\n\nThe caret direction is derived rather than configured: a trigger nested inside a `use-menu`\nis understood to open a submenu and renders pointing sideways; a top-level trigger renders\npointing down.\n\nSwapping in a different caret **per instance** is a slot: put your own element in the `icon`\nslot and it replaces `part(icon-default)` entirely for that trigger.\n\nSwapping the default caret **for every trigger in the app** doesn't need touching this\ncomponent's `render()` at all — style `::part(icon-default)` from an outside stylesheet, the\nsame way any shadow DOM part is themed:\n\n```css\nuse-caret::part(icon-default) {\n mask-image: url(\"/icons/my-caret.svg\");\n}\n```\n\n(When the design system's `theme.css` is loaded, this is already wired to a token —\n`--usewc-effect-dropdown-trigger-icon-mask-image` — so redefining that custom property has\nthe same effect without writing a `::part()` rule at all.)\n\n`::part()` only reaches CSS-expressible changes (a mask, a background, a transform). For\nanything else — different markup, an icon font, logic beyond a mask — set the static `icon`\nand `nestedIcon` hooks. Every `<use-caret>` in the page picks them up; consumers keep writing\nthe same tag, no new element to register or remember to use instead. `icon` supplies a\ntop-level trigger's glyph, `nestedIcon` a submenu trigger's — set whichever apply; an unset one\nkeeps the built-in ▼/▶ for that case. Set them once, as early as possible (an app's entry\npoint, before any triggers connect) — Lit calls `render()` fresh on every update, so an\nalready-connected instance only reflects the change once something causes it to re-render:\n\n```ts\n// A bare string or TemplateResult is used as-is, on every trigger of that kind:\nUseCaret.icon = \"▾\";\nUseCaret.nestedIcon = \"▸\";\n\n// A function is called on every render instead:\nUseCaret.nestedIcon = (html) => html`<my-icon name=\"chevron-right\"></my-icon>`;\n```\n\nThe function form is called with the component's own `html` tag as its (optional) first\nargument rather than requiring the caller to import one — a page can end up with more than one\ncopy of `lit-html` in its module graph, and a `TemplateResult` built from a *different* copy\nthan the one this component renders with can silently fail to render. Taking `html` in as a\nparameter sidesteps that: whatever's returned is guaranteed to come from the same `lit-html`\nthis component already uses. A bare string skips the concern entirely.\n\nOnly need to change the icon on **some** triggers, not every one in the app? Extend the\nclass, override `render()` normally, and register the subclass under a different tag name so\nit coexists with the built-in element instead of replacing it everywhere:\n\n```ts\nclass MyCaret extends UseCaret {\n override render() {\n return html`<slot></slot><slot name=\"icon\"><my-icon name=\"chevron\"></my-icon></slot>`;\n }\n}\ncustomElements.define(\"my-caret\", MyCaret);\n```\n---\n\n\n### **Slots:**\n - **default** - Trigger label content.\n- **icon** - Replaces the default caret glyph.",
|
|
74
|
+
"attributes": [],
|
|
75
|
+
"references": []
|
|
76
|
+
},
|
|
77
77
|
{
|
|
78
78
|
"name": "use-date-picker",
|
|
79
79
|
"description": "A day-granularity date picker. Value format: YYYY-MM-DD.\n\nCustomize day rendering on an instance:\n```ts\ndatePicker.renderDay = ({ day, date }, html) =>\n date === \"2026-03-17\" ? html`<strong>${day}</strong>` : String(day);\n```\n\nOr override on a subclass to apply it to every instance, falling back to\n`super.renderDay(...)` for dates you don't want to customize:\n```ts\nclass MyDatePicker extends UseDatePicker {\n renderDay(data: { day: number; date: string }, html: LitHtml) {\n if (data.date === \"2026-03-17\") {\n return html`<strong>${data.day}</strong>`;\n }\n return super.renderDay(data, html);\n }\n}\n```\n---\n\n\n### **Events:**\n - **use-change** - Fired on selection with detail `{ value: string }`\n\n### **Methods:**\n - **renderDay(data: _{ day: number; date: string }_, _html: _LitHtml_): _TemplateResult | string_** - See UseCalendarRenderDay. Assigning a new function on an\ninstance (e.g. via `.renderDay=${fn}` in a Lit template) after first\nrender does not schedule a re-render on its own — call `requestUpdate()`\nif needed.\n\nDeclared as a regular method rather than a class field so subclass\noverrides can call `super.renderDay(data, html)` to fall back to the\ndefault (or a parent override's) rendering.\n\n### **Slots:**\n - **header-start** - Content before the title in the header\n- **title** - Title showing the month and year\n- **controls** - Navigation controls (previous, today, next buttons)\n- **header-end** - Content after the controls in the header\n- **date-{YYYY-MM-DD}** - Per-date content that replaces the default day number\n\n### **CSS Parts:**\n - **header** - The header container\n- **title** - The title text\n- **title-month** - The month part of the title\n- **title-literal** - Literal text in the title\n- **title-year** - The year part of the title\n- **controls** - The controls slot container\n- **control** - Individual control button\n- **control-previous** - Previous month button\n- **control-today** - Today button\n- **control-next** - Next month button\n- **grid** - The main calendar grid\n- **grid-header** - The header row with day names\n- **grid-header-cell** - Individual day name header cell\n- **grid-body** - The container for calendar weeks\n- **row** - A row of days\n- **day** - A day cell\n- **day-empty** - An empty day cell (from previous/next month)\n- **day-selected** - A selected day cell\n- **day-today** - The current date cell\n- **day-disabled** - A disabled date cell\n- **title-button** - The clickable button wrapping the month/year title\n- **picker** - The scrollable month/year picker panel (replaces grid when open)\n- **picker-year-section** - Container for one year's label and month grid\n- **picker-year-label** - The year heading inside a year section\n- **picker-months** - The 4-column month grid inside a year section\n- **picker-month** - An individual month button\n- **picker-month-current** - Applied to the currently selected month button",
|