kempo-ui 0.0.82 → 0.0.83

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kempo-ui",
-  "version": "0.0.82",
+  "version": "0.0.83",
   "type": "module",
   "description": "A Lit based web-component library",
   "main": "index.js",

package/CONTRIBUTING.md

@@ -1,219 +0,0 @@
-# Code Contribution Guidelines
-
-## Project Structure
-
- - All code should be in the `src/` directory, with the exception of npm scripts.
- - All components should be in the `src/components/` directory.
- - All utility function module files should be in the `src/utils/` directory.
- - All documnentation should be in the `docs/` directory. This directory is used by GitHub as the "GitHub Pages", so all links need to be relative, and there will be a build script which copies all code to the `docs/` directory.
-
-## Coding Style Guidelines
-
-### Code Organization
-Use multi-line comments to separate code into logical sections. Group related functionality together.
-  - Example: In Lit components, group lifecycle callbacks, event handlers, public methods, utility functions, and rendering logic separately.
-
-```javascript
-/*
-  Lifecycle Callbacks
-*/
-```
-
-### Avoid single-use variables/functions
-Avoid defining a variable or function to only use it once; inline the logic where needed. Some exceptions include:
-  - recursion
-  - scope encapsulation (IIFE)
-  - context changes
-
-### Minimal Comments, Empty Lines, and Spacing
-
-Use minimal comments. Assume readers understand the language. Some exceptions include:
-  - complex logic
-  - anti-patterns
-  - code organization
-
-Do not put random empty lines within code; put them where they make sense for readability, for example:
-  - above and below definitions for functions and classes.
-  - to help break up large sections of logic to be more readable. If there are 100 lines of code with no breaks, it gets hard to read.
-  - above multi-line comments to indicate the comment belongs to the code below
-
-No  empty lines in css.
-
-End each file with an empty line.
-
-End each line with a `;` when possible, even if it is optional.
-
-Avoid unnecessary spacing, for example:
-  - after the word `if`
-  - within parentheses for conditional statements
-
-```javascript
-let count = 1;
-
-const incrementOdd = (n) => {
-  if(n % 2 !== 0){
-    return n++;
-  }
-  return n;
-};
-
-count = incrementOdd(count);
-```
-
-### Prefer Arrow Functions
-Prefer the use of arrow functions when possible, especially for class methods to avoid binding. Use normal functions if needed for preserving the proper context.
- - For very basic logic, use implicit returns
- - If there is a single parameter, omit the parentheses.
-```javascript
-const addOne = n => n + 1;
-```
-
-### Module Exports
-  - If a module has only one export, use the "default" export, not a named export.
-    - Do not declare the default export as a const or give it a name; just export the value.
-
-```javascript
-export default (n) => n + 1;
-```
-  - If a module has multiple exports, use named exports and do not use a "default" export.
-
-### Code Reuse
-Create utility functions for shared logic.
-  - If the shared logic is used in a single file, define a utility function in that file.
-  - If the shared logic is used in multiple files, create a utility function module file in `src/utils/`.
-
-### Naming
-Do not prefix identifiers with underscores.
-  - Never use leading underscores (`_`) for variable, property, method, or function names.
-  - Use clear, descriptive names without prefixes.
-  - When true privacy is needed inside classes, prefer native JavaScript private fields (e.g., `#myField`) instead of simulated privacy via underscores.
-
-## Components
-
-### Base Component Architecture
-
-The project provides three base components for different rendering strategies. Choose the appropriate base component and extend it:
-
-#### ShadowComponent
-For components that need shadow DOM encapsulation and automatic `/kempo.css` stylesheet injection.
-
-```javascript
-import ShadowComponent from './ShadowComponent.js';
-
-export default class MyComponent extends ShadowComponent {
-  render() {
-    return html`<p>Shadow DOM content with scoped styles</p>`;
-  }
-}
-```
-
-#### LightComponent  
-For components that render directly to light DOM without shadow DOM encapsulation.
-
-```javascript
-import LightComponent from './LightComponent.js';
-
-export default class MyComponent extends LightComponent {
-  renderLightDom() {
-    return html`<p>Light DOM content</p>`;
-  }
-}
-```
-
-#### HybridComponent
-For components that need both shadow DOM (with automatic `/kempo.css`) and light DOM rendering.
-
-```javascript
-import HybridComponent from './HybridComponent.js';
-
-export default class MyComponent extends HybridComponent {
-  render() {
-    return html`<p>Shadow DOM content</p>`;
-  }
-  
-  renderLightDom() {
-    return html`<p>Light DOM content alongside natural children</p>`;
-  }
-}
-```
-
-**Important:** Always call `super.updated()` when overriding the `updated()` method in LightComponent or HybridComponent to ensure proper rendering.
-
-### Component Architecture and Communication
-
-- Use methods to cause actions; do not emit events to trigger logic. Events are for notifying that something already happened.
-  - Prefer `el.closest('ktf-test-framework')?.enqueueSuite({...})` over firing an `enqueue` event.
-
-- Wrap dependent components inside a parent `ktf-test-framework` element. Children find it via `closest('ktf-test-framework')` and call its methods. The framework can query its subtree to orchestrate children.
-
-- Avoid `window` globals and global custom events for coordination. If broadcast is needed, scope events to the framework element; reserve window events for global, non-visual concerns (e.g., settings changes).
-
-## Development Workflow
-
-### NPM Scripts
-
-#### Build
-```bash
-npm run build
-```
-Compiles and minifies source files from `src/` and copies all necessary files to the `docs/` directory for GitHub Pages deployment.
-
-#### Documentation Server
-```bash
-npm run docs
-```
-Starts a local development server and opens the documentation site. Automatically runs the build script first.
-
-**Variants:**
-- `npm run docs:src` - Serves from `src/` instead of `docs/` for development
-- `npm run docs:no-build` - Skips the build step and serves existing `docs/`
-
-#### Testing
-```bash
-npm test              # Run all tests
-npm run test:gui      # Run tests with GUI interface
-npm run test:browser  # Run browser-only tests
-npm run test:node     # Run Node.js-only tests
-```
-
-#### Update Kempo CSS
-```bash
-npm run update-kempo-css
-```
-Downloads the latest version of Kempo CSS from the CDN and updates local files.
-
-### Adding Icons
-
-Use the `geticon` script to download icons from [Google Material Symbols](https://fonts.google.com/icons). The script automatically formats icons and triggers a build.
-
-#### Basic Usage
-```bash
-npm run geticon <icon_name>
-```
-
-Example:
-```bash
-npm run geticon format_bold
-```
-
-This downloads the icon and saves it as `format_bold.svg` in the `icons/` directory.
-
-#### Custom Naming
-
-Rename icons when downloading by providing a second argument:
-```bash
-npm run geticon <icon_name> <custom_name>
-```
-
-Example - download `content_copy` but save as `copy.svg`:
-```bash
-npm run geticon content_copy copy
-```
-
-#### What the Script Does
-
-- Downloads the specified icon from Google's Material Symbols CDN
-- Removes `width` and `height` attributes
-- Adds `fill="currentColor"` to all `<path>` elements
-- Saves the formatted SVG to the `icons/` directory
-- Automatically runs the build script to copy the icon to `docs/`