@sebgroup/green-core 3.23.0 → 3.24.1

package/generated/react/icons/icon-satellite/index.js

@@ -0,0 +1,14 @@
+import "../../../../chunks/chunk.CAV4X6PU.js";
+import { createElement } from "react";
+import { IconSatellite as IconSatelliteClass } from "../../../../components/icon/icons/satellite.component.js";
+import { getReactComponent } from "../../../../utils/react.js";
+const IconSatellite = (props) => {
+  IconSatelliteClass.define();
+  const JSXElement = getReactComponent("gds-icon-satellite");
+  const propsWithClass = { ...props, class: props.className, ref: props.ref };
+  return createElement(JSXElement, propsWithClass);
+};
+IconSatellite.displayName = "IconSatellite";
+export {
+  IconSatellite
+};

package/generated/react/index.d.ts

@@ -26,8 +26,8 @@ export * from './grouped-list/index.js';
 export * from './img/index.js';
 export * from './input/index.js';
 export * from './link/index.js';
-export * from './mask/index.js';
 export * from './list/index.js';
+export * from './mask/index.js';
 export * from './menu-button/index.js';
 export * from './pagination/index.js';
 export * from './backdrop/index.js';
@@ -315,6 +315,7 @@ export * from './icons/icon-robot/index.js';
 export * from './icons/icon-rocket/index.js';
 export * from './icons/icon-run-shortcut/index.js';
 export * from './icons/icon-safari/index.js';
+export * from './icons/icon-satellite/index.js';
 export * from './icons/icon-school/index.js';
 export * from './icons/icon-scissors/index.js';
 export * from './icons/icon-search-menu/index.js';

package/generated/react/index.js

@@ -26,8 +26,8 @@ export * from "./grouped-list/index.js";
 export * from "./img/index.js";
 export * from "./input/index.js";
 export * from "./link/index.js";
-export * from "./mask/index.js";
 export * from "./list/index.js";
+export * from "./mask/index.js";
 export * from "./menu-button/index.js";
 export * from "./pagination/index.js";
 export * from "./backdrop/index.js";
@@ -315,6 +315,7 @@ export * from "./icons/icon-robot/index.js";
 export * from "./icons/icon-rocket/index.js";
 export * from "./icons/icon-run-shortcut/index.js";
 export * from "./icons/icon-safari/index.js";
+export * from "./icons/icon-satellite/index.js";
 export * from "./icons/icon-school/index.js";
 export * from "./icons/icon-scissors/index.js";
 export * from "./icons/icon-search-menu/index.js";

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@sebgroup/green-core",
   "description": "A carefully crafted set of Web Components, laying the foundation of the Green Design System.",
-  "version": "3.23.0",
+  "version": "3.24.1",
   "main": "index.js",
   "module": "index.js",
   "type": "module",
@@ -189,6 +189,7 @@
     "./components/icon/icons/search-menu.js",
     "./components/icon/icons/scissors.js",
     "./components/icon/icons/school.js",
+    "./components/icon/icons/satellite.js",
     "./components/icon/icons/safari.js",
     "./components/icon/icons/run-shortcut.js",
     "./components/icon/icons/rocket.js",

package/utils/helpers/custom-element-scoping.js

@@ -1,6 +1,6 @@
 import "../../chunks/chunk.CAV4X6PU.js";
 import { html as litHtml } from "lit";
-const VER_SUFFIX = "-3deb38";
+const VER_SUFFIX = "-808a82";
 class ScopedElementRegistry {
   static get instance() {
     if (!globalThis.__gdsElementLookupTable?.[VER_SUFFIX])

package/utils/helpers/has-changed.d.ts

@@ -0,0 +1,8 @@
+/**
+ * A `hasChanged` function for Lit reactive properties that treats `Date` values as equal when they
+ * represent the same point in time, rather than requiring referential equality. Use this on
+ * `Date`-typed properties (e.g. `value`) to avoid triggering reactive side effects, such as `@watch`
+ * handlers, when an equivalent but new `Date` instance is assigned - a common occurrence when a value
+ * is bound from a framework wrapper that re-renders with freshly created `Date` objects.
+ */
+export declare function dateHasChanged<T>(value: T, oldValue: T): boolean;

package/utils/helpers/has-changed.js

@@ -0,0 +1,10 @@
+import "../../chunks/chunk.CAV4X6PU.js";
+function dateHasChanged(value, oldValue) {
+  if (value instanceof Date && oldValue instanceof Date) {
+    return value.getTime() !== oldValue.getTime();
+  }
+  return value !== oldValue;
+}
+export {
+  dateHasChanged
+};

package/generated/mcp/alert/guidelines.md

@@ -1,105 +0,0 @@
-# Alert
-
-An alert displays important messages, feedback, or time-sensitive information.
-
-
-## Overview
-
-### Variants
-
-A set of predefined styles that convey different meanings and states through consistent visual treatment each with specific icons.
-
-#### Information
-
-Used for _passive_, non-critical updates like tips or background information. It's quiet and unobtrusive.
-
-#### Notice
-
-Used for _actionable_, attention-worthy updates that are still non-critical, like a change in a process or a reminder to do something soon.
-
-#### Positive
-
-Confirms successful actions, such as form submissions, with a success message, optional next steps, and possible brand reinforcement.
-
-#### Warning
-
-Highlights non-critical issues, such as upcoming deadlines, with a concise issue summary, optional duration estimate, and suggested actions.
-
-#### Negative
-
-Communicates critical issues or errors, such as system outages, with a clear problem description, optional apology for system issues, and resolution guidance.
-
-### Action button
-
-Alert supports an optional action button with customisable text to trigger relevant actions.
-
-### Dismissible
-
-Alerts can be configured as `dismissible` in order to show a close button in the upper right corner. This also enabled closing the alert by pressing the escape key.
-
-### Auto-dismiss
-
-Alert can also be set up to use an auto-dismiss timer. In this configuration, a timer progress bar will be shown at the bottom of the alert, and the alert will close once the timer reaches the end.
-
-### Placement
-
-The most important rule is to place the alert near the issue that triggered it.
-
-#### Global alert
-
-Used for system-wide messages.
-
-*   Placed above the header and takes full width of the screen.
-    
-*   The icon, text content, and action button should be center-aligned horizontally.
-    
-*   The dismiss button is placed at the far right.
-
-#### Page alert
-
-Used for messages affecting the entire page (e.g., _Bankgiro is down_).
-
-*   Placed at the top of the page, below the header.
-
-#### Group alert
-
-Used for messages related to a specific module (e.g., _Transaction listing is unavailable_).
-
-*   Placed within the module, at the top.
-
-#### Specific alert
-
-Used for messages related to specific content (e.g., _Negative balance_).
-
-*   Placed directly in the content area, close to the element it concerns (such as a table or field).
-
-### Guidelines
-
-Select the appropriate variant to match the message’s intent, such as using positive for success messages or negative for errors. Also ensure a meaningful label property is set to describe the alert’s purpose for accessibility. A label should always be set when using alert.
-
-Choose the role property carefully, using alert for critical messages and status for informational updates, to align with ARIA best practices.
-
-For toast-like messages, like save confirmations and other non-critical messages, auto-dismiss can be used to avoid interrupting user workflows.
-
-
-## UX Guidelines
-
-### Writing UX text for alerts
-
-### Alert with a heading
-
-### Alert without a heading
-
-### Alert with a button
-
-### Alert with a link
-
-### Using buttons and links together
-
-### Information alert
-
-### Success alert
-
-### Warning alert
-
-### Critical and error alert

package/generated/mcp/avatar/guidelines.md

@@ -1,40 +0,0 @@
-# Avatar
-
-An avatar represents a user, entity, or object. It is typically displayed as an image, initials, or icon, and helps identify ownership, participation, or presence in the interface.
-
-
-## Overview
-
-### Usage
-
-Use an avatar when you need to represent a user, such as in lists, messages, or account-related contexts. It provides quick visual recognition and helps users understand who is involved in a specific action or piece of content. Avatars are especially useful in collaborative or communication-heavy interfaces where multiple people are present.
-
-### Variants
-
-The avatar comes in two shapes:
-
-- **Circular**  
-Used in more prominent or personal contexts, such as the top header or profile-related areas.
-- **Squared**  
-Used to represent products, accounts, or organizations. This includes cases like specific account types, funds, or company logos.
-
-
-
-### Sizes
-
-The avatar is available in four sizes:
-
-- **XS**
-- **S**
-- **M** 
-- **L**
-
-
-
-### Grouped avatars
-
-Avatars can be grouped to represent multiple users, for example in shared ownership or collaborative contexts. The avatars are displayed in a horizontal stack with a slight overlap to save space and create a cohesive visual unit.
-
-To maintain clarity, a maximum of three avatars should be visible at the same time. If more users are included, the remaining count is shown as a “+X” indicator, such as “+2”.
-
-

package/generated/mcp/badge/guidelines.md

@@ -1,56 +0,0 @@
-# Badge
-
-A compact visual indicator for status, counts and notifications.
-
-
-## Overview
-
-### Usage
-
-Badges are especially useful for:
-
-*   **Status indicators** – Showing that something is new, in progress, needs attention, or has been successfully completed.
-    
-*   **Counters** – Indicating the number of new messages, notifications, or tasks.
-    
-*   **Contextual highlights** – Marking a feature as beta or signaling updates users should be aware of.
-    
-
-Use badges sparingly – too many can create visual noise and reduce their impact. Always ensure that the badge color, icon and label clearly support the intended message.
-
-### Variants
-
-A set of predefined styles that convey different meanings and states through consistent visual treatment.
-
-*   **Information** – For general updates or tips that help the user understand context.
-    
-*   **Notice** – For neutral alerts or flags that are not critical but still relevant.
-    
-*   **Positive** – For confirming success or a completed action (e.g., “Active” or “Paid”).
-    
-*   **Warning** – For potential issues users should be cautious about.
-    
-*   **Negative** – For errors, failed states, or items requiring immediate attention.
-
-### Size
-
-Available in large (default) and small sizes to accommodate different UI contexts and content requirements.
-
-### Notification mode
-
-Optimised for notification indicators.
-
-### Rounded
-
-The rounded property transforms the badge's appearance by applying fully circular corners, making it ideal for numerical indicators or status markers.
-
-### Lead and trail slots
-
-The badge component supports both lead and trail slots, enabling the placement of icons or additional content before or after the main text.
-
-
-## UX Guidelines
-
-### Writing UX text for badges
-
-### Our most common statuses

package/generated/mcp/blur/guidelines.md

@@ -1,3 +0,0 @@
-# Blur
-
-The Blur component is used to apply a blur effect over content, often used to obscure sensitive or background information.

package/generated/mcp/breadcrumbs/guidelines.md

@@ -1,35 +0,0 @@
-# Breadcrumbs
-
-A breadcrumb is a secondary navigation showing the website hierarchy.
-
-
-## Overview
-
-### When to use it
-
-Use for sites and applications that have a substantial amount of pages present deeper down in site structures.
-
-### Desktop
-
-The full path may not take up more than one row in the layout.
-
-### Mobile
-
-For mobile views we only display the link to the parent page, as the full path tends to take too much space.
-
-The same version may be used in shallow hierarchies where there still is a need to easily move one step up, or back to the page from where you came.
-
-### Overflow
-
-The breadcrumbs component is designed with flexibility in mind, allowing developers to implement \* custom overflow solutions that best fit their specific needs.
-
-
-## UX Guidelines
-
-### Writing UX text for breadcrums
-
-### Be clear and simple
-
-### Breadcrumbs on mobile web
-
-### Breadcrumbs in native apps

package/generated/mcp/button/guidelines.md

@@ -1,83 +0,0 @@
-# Button
-
-A button can be tapped or clicked to perform an action.
-
-
-## Overview
-
-### Variants and ranks
-
-Variant is used to communicate the intent of the button, such as positive, negative, notice.
-
-Rank determines the priority of the button, and can be primary, secondary or tertiary. All variants are each available in those three ranks. 
-
-### Neutral
-
-This is our default button used for most cases. Carefully choose what rank to use and avoid using more than one primary button for each context.
-
-### Brand
-
-Our brand button is used in specific scenarios, such as hero areas, login or brand enforcing messages.
-
-### Negative
-
-Used for destructive actions such as "Delete". Also used for sell actions (e.g. selling stocks or funds).
-
-### Notice
-
-Use only for the notice alert and for buy actions (e.g. buying stocks or funds).
-
-### Icon button
-
-Use an icon button only when the icon is universally understood and can stand on its own, such as a close or expand icon.
-
-If the action is not immediately clear, use a regular button with a text label instead to ensure clarity and accessibility.
-
-The icon button comes in the same ranks and variants as regular buttons.
-
-### Split button
-
-The split button always has a primary action. This action is most likely to be used by the customer as the default action. The users can click on the icon button to reveal a context menu providing secondary or additional options.
-
-### Next and back button
-
-Used inside flows to signal the direction forward or backward.
-
-Back button comes in both primary and secondary state depending on what suits the content. The next button comes as primary only.
-
-### Size
-
-Buttons can be xs, small, medium or large. The default size is medium.  
-Choose size depending on context. Avoid to mix different sizes in the same context.
-
-### Desktop placements
-
-- **Left**: In overviews and widgets, the user tends to read from top to bottom following the left side, therefore the buttons are kept to the left. Place the primary button furthest to the left.
-- **Right**: Modals and flows move the user forward (interpreted as to the right in western culture), therefore the buttons are placed to the right. Place the primary button furthest to the right.
-
-
-
-### In a mobile device
-
-- **One button**, use the full width of the content area.
-- **Two buttons**, aim to place them side by side. It is allowed to stack them if needed.
-- **Three buttons**, consider the need for all of them. "cancel or close" might be x in the top right corner. Worst case scenario: place two buttons side by side and one tertiary button under.
-
-
-
-### Do’s and don’ts
-
-Only use one primary action in the same context of several actions.
-
-
-## UX Guidelines
-
-### Writing UX text for buttons
-
-### Use commands and requests in the button
-
-### Avoid Perform and Okay
-
-### Standard button texts
-
-### Do’s and don’ts

package/generated/mcp/calendar/guidelines.md

@@ -1,3 +0,0 @@
-# Calendar
-
-The calendar displays a grid of selectable dates.

package/generated/mcp/card/guidelines.md

@@ -1,78 +0,0 @@
-# Card
-
-The card groups related content into a single container.
-
-
-## Overview
-
-### Variants
-
-### Brand cards
-
-Brand-01 and brand-02 can only be used in special contexts and with specific content. This will be added as guidelines. Since we do not have any matching action components for now you can only slot text, link and icon.
-
-### Interactions
-
-#### Default
-
-The entire card area is not clickable. The slotted content can contain one or several clickable elements, such as button and link.
-
-#### Linked
-
-The entire card area is clickable. The slotted content can include one decorative element. This element must be inert (non-interactive) since the whole card already functions as the clickable target.
-
-### Usage
-
-Don't mix linked and default cards in the same group or grid. Interactions should be consistent across a set of cards to ensure a predictable and accessible experience. If you must use both in the same view, do it with care, for example, by visually separating them or clearly communicating the interaction difference.
-
-#### Why this matters:
-
-- **Consistency** – users should understand how a card behaves before they interact with it. Mixing types can make it unclear whether the whole card or only parts are clickable.
-- **Accessibility** – linked cards rely on different interaction logic and focus handling compared to cards with multiple actions. Mixing them can create confusion for keyboard and screen-reader users.
-- **Visual clarity** – linked cards use hover and press states that don’t apply to default cards, which can create inconsistent visual feedback.
-
- 
-
-### Card on card
-
-Cards can be placed inside other cards to create hierarchy and visual grouping. This also goes for a card inside a modal since the card and the modal have the same base tokens. To support this, we use elevated color tokens that ensure proper contrast and consistency across both light and dark mode.
-
-#### How it works
-
-When nesting cards or placing cards in modals, the inner card should always contrast against its parent background. This is handled through paired color tokens and creates a clear visual separation between layers without relying on shadows alone.  
-
-#### Light mode behavior
-
-Always use the “-2” token for the nested card to maintain correct contrast and hierarchy.
-
-- A **grey card (neutral-01)** can contain a **white card (neutral-01-2)**
-- A **white card (neutral-02)** can contain a **grey card (neutral-02-2)**
-
- 
-
-#### Dark mode behavior
-
-In dark mode, base card variants share the same surface value. The elevated variants (“-2”) are adjusted to create subtle contrast between layers. This ensures that nested cards remain distinguishable and maintain a clear sense of hierarchy.
-
-- **Neutral-01** and **Neutral-02** share the same base value
-- **Neutral-01-2** and **Neutral-02-2** use slightly adjusted values to create elevation and separation between nested cards. (MIGHT NEED UPDATE!)
-
- 
-
-#### In Figma
-
-Elevated cards are available as **variants** of the Card component. We call them ”Raised”. 
-
-- Select the appropriate **variant** based on the card’s context (base or nested).
-- Use the **“-2” variants** when placing a card inside another card or modal.
-- Avoid manually changing fill colors, always switch variants instead.
-
-(A card instance in a card needs a bit of a trick. You need to add the card instance in your slot AFTER you place the slot in your card. This will be much easier as soon as we rebuild the cards to use the new feature with actual slots, that will remove the obsticle of you needing to create a lot of slot components).
-
-#### Card on card guidelines
-
-- Use nested cards to group related content or create visual hierarchy.
-- Always use the paired “-2” variants/tokens for inner cards.
-- Think of the “-2” variants as an elevation step, they define how surfaces stack.
-
-### Do's and don'ts

package/generated/mcp/card-pattern-01/guidelines.md

@@ -1,52 +0,0 @@
-# Card pattern 01
-
-Card pattern 01 is a pre-built composition based on the card component.
-
-
-## Overview
-
-### Slots
-
-All card patterns are built on top of the base card component. Card pattern 01 is available in both interaction types – default card and linked card, and uses slots to build flexible yet consistent layouts.
-
-Each variant consists of:
-
-- **header slot** – img, icon or custom
-- **main area** – includes heading and excerpt
-- **footer** **slot** – supports actions depending on card type (see below).
-
-
-
-### Header
-
-#### Empty
-
-No header content. 
-
-#### Image
-
-Can be 16:9 (landscape) or 1:1 (portrait).
-
-#### Custom
-
-Allows placement of custom content.
-
-### Footer
-
-### Decorative elements
-
-The footer on a linked card upports two types of decorative elements: a label, set via the `label` property, and slotted elements, such as an icon button.
-
-Note: All decorative elements are always inert.
-
-### Empty
-
-The footer will not show if the card is linked without a label, or if no slotted elements are provided.
-
-### Actions
-
-Note: This only applies to the default card (not linked).
-
-### Variants
-
-In card pattern 01, you can choose between two variants: `neutral-01` and `neutral-02`. The `neutral-02` variant can also be outlined.

package/generated/mcp/checkbox/guidelines.md

@@ -1,91 +0,0 @@
-# Checkbox
-
-A checkbox is a form control that allows users to select one or multiple options.
-
-
-## Overview
-
-### Variants
-
-- **Default**
-- **Contained**: Coming soon Used on its own or together with other form components.
-
-
-
-### Features
-
-#### Label
-
-All individual checkboxes must have a label to ensure clarity and accessibility. When checkboxes are grouped, the group must have a header label. Labels help users understand the purpose of the checkboxes, including those using assistive technologies.
-
-#### Optional field indicator
-
-Only use in the header label. We only ask for required information. If some fields are optional, we let users know by adding "(optional)" in brackets next to the field label. The word "(optional)" is shown in regular font weight to distinguish it from the label.
-
-### Support text
-
-This can be used for both the header and individual checkboxes. Use this to explain how to fill in the field, for example how to count or what to include. Contained checkboxes don’t have support text for the individual checkboxes.
-
-### Contextual help
-
-If the label and support text are not enough to explain a field, we can use the info icon. Clicking the icon shows additional support text between the label support and the field.
-
-- Use a tooltip if space is limited.
-- Use a modal for large amounts of text.
-
-
-
-### Error message
-
-Used to indicate that a single checkbox must be checked or that a group of checkboxes has errors.
-
-### Indeterminate state
-
-Used when a checkbox is partially selected, typically in parent-child relationships within nested checkboxes. Not available for the contained variant.
-
-### Behaviour:
-
-- If some child checkboxes are selected, the parent shows the indeterminate state.
-- If all child checkboxes are selected, the parent appears selected.
-- Selecting a parent checkbox (whether unselected or in the indeterminate state) selects all child checkboxes.
-- Deselecting the parent checkbox deselects all child checkboxes.
-
-
-
-### Alignment
-
-Checkboxes can be aligned horizontal or vertical.
-
-- **Vertical**: This is the default alignment. It's easier to read and scan the available options.
-- **Horizontal**: Only used for a small set of options if the page shouldn't be to long, but try to avoid.
-
-
-
-### Do's and don'ts
-
-### Read only
-
-The read only shows the selected state without allowing it to be changed. When several checkboxes represent a group of choices, the read only retain enough context for users to understand both selected and unselected options when that information is relevant.
-
-[Read more about the read only pattern](https://seb.io/patterns/read-only)
-
-
-## UX Guidelines
-
-### Writing UX text for checkboxes
-
-### Stand-alone checkbox
-
-### Use the “I” form
-
-### Don't
-
-### Avoid negations
-
-### Avoid questions
-
-### Multiple options
-
-### Do
-
-### Don't

package/generated/mcp/coachmark/guidelines.md

@@ -1,8 +0,0 @@
-# Coachmark
-
-Coachmarks guide users through interface features.
-
-
-## UX Guidelines
-
-### Writing UX text for coach marks