@lion/ui 0.24.0 → 0.26.0

package/docs/guides/principles/scoped-elements.md

@@ -1,119 +0,0 @@
----
-parts:
-  - Principles
-  - Scoped Elements
-title: 'Scoped Elements'
-eleventyNavigation:
-  key: 'Principles: Scoped Elements'
-  order: 40
-  parent: Principles
-  title: Scoped Elements
----
-
-# Scoped Elements
-
-The [CustomElementRegistry](https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry) provides methods for registering custom elements. One of the limitations of working with this global registry is that multiple versions of the same element cannot co-exist. This causes bottlenecks in software delivery that should be managed by the teams and complex build systems. [Scoped Custom Element Registries](https://github.com/w3c/webcomponents/issues/716) is a proposal that will solve the problem. Since this functionality won't be available (especially not cross browser) anytime soon, we've adopted [OpenWC's Scoped Elements](https://open-wc.org/docs/development/scoped-elements/).
-
-Whenever a lion component uses composition (meaning it uses another lion component inside), we
-apply ScopedElementsMixin to make sure it uses the right version of this internal component.
-
-```js
-import { LitElement, html } from '@lion/ui/core.js';
-import { ScopedElementsMixin } from '@open-wc/scoped-elements/lit-element.js';
-import { html, LitElement } from 'lit';
-
-import { LionInput } from '@lion/ui/input.js';
-import { LionButton } from '@lion/ui/button.js';
-
-class MyElement extends ScopedElementsMixin(LitElement) {
-  static get scopedElements() {
-    return {
-      'lion-input': LionInput,
-      'lion-button': LionButton,
-    };
-  }
-
-  render() {
-    return html`
-      <lion-input label="Greeting" name="greeting" .modelValue="${'Hello world'}"></lion-input>
-      <lion-button>Save</lion-button>
-    `;
-  }
-}
-```
-
-## Polyfill
-
-This package requires use of the Scoped Custom Element Registry polyfill. Make sure to load it as the first thing in your application:
-
-```js
-import '@webcomponents/scoped-custom-element-registry';
-```
-
-If you're using `@web/rollup-plugin-polyfills-loader`, you can use it in your rollup config like this:
-
-```js
-polyfillsLoader({
-  polyfills: {
-    scopedCustomElementRegistry: true,
-  },
-});
-```
-
-If you're using `@web/dev-server` for local development, you can use the `@web/dev-server-polyfill` plugin:
-
-```js
-polyfill({
-  scopedCustomElementRegistry: true,
-});
-```
-
-## Edge cases
-
-Sometimes we need to render parts of a template to light dom for [accessibility](https://wicg.github.io/aom/explainer.html). For instance we render a node via `lit-html` that we append to the host element, so it gets slotted in the right position.
-In this case, we should also make sure that we also scope the rendered element.
-
-We can do this as follows:
-
-```js
-_myLightTemplate() {
-  return html`
-    This template may be overridden by a Subclasser.
-    Even I don't end up in shadow root, I need to be scoped to constructor.scopedElements as well.
-    <div>
-      <lion-button>True</lion-button>
-      <lion-input label="xyz"></lion-input>
-    </div>
-  `;
-}
-
-__getLightDomNode() {
-  const renderParent = document.createElement('div');
-  this.constructor.render(this._myLightTemplate(), renderParent, {
-    scopeName: this.localName,
-    eventContext: this,
-  });
-  // this node will be appended to the host
-  return renderParent.firstElementChild;
-}
-
-connectedCallback() {
-  super.connectedCallback();
-  this.appendChild(this.__getLightDomNode());
-}
-```
-
-In a less complex case, we might just want to add a child node to the dom.
-
-```js
-import { LitElement  } from 'lit';
-import { ScopedElementsMixin } from '@open-wc/scoped-elements/lit-element.js';
-
-...
-
-__getLightDomNode() {
-  return document.createElement('lion-input', this.constructor.scopedElements);
-}
-```
-
-We encourage you to have a look at [OpenWC's Scoped elements](https://open-wc.org/docs/development/scoped-elements/).

package/docs/guides/principles/styling.md

@@ -1,43 +0,0 @@
----
-parts:
-  - Principles
-  - Styling
-title: 'Styling'
-eleventyNavigation:
-  key: 'Principles: Styling'
-  order: 30
-  parent: Principles
-  title: Styling
----
-
-# Styling
-
-## Markup and styling
-
-All Lion web components have white label styling: this means theming is not applied,
-but functional styling is.
-
-### Functional styling
-
-Functional styling can be divided into defaults for `basic layout` and `accessibility`.
-Examples for both categories can be found below:
-
-- Basic layout examples:
-  - A dropdown menu has `position: absolute;`.
-  - A lion-button might behave as an `display: inline-block;` element.
-  - A suffix attached to an input is horizontally positioned (instead of vertically stacked).
-
-- Accessibility examples:
-  - Content (for instance a caption in a table) can be `visually hidden`: it will be
-    readable by screen readers, but invisible for end users.
-  - When an html table is used, we allow [subclassers](https://github.com/ing-bank/lion/blob/bc7530702f41df90a4ca3059cfb9edb08e27f742/docs/guides/principles/subclasser-apis.md) to override the display property (`table-cell`) to `flex`. By putting the proper accessible roles (`role="cell"`) in the markup, we guarantee our markup stays accessible.
-
-Although Lion components try to stay as unbiased as possible with regard to styling, defaults will be needed. In these cases we try to follow the platform as much as possible. If the platform doesn't provide defaults, the largest common denominator across existing UI systems is taken as a lead.
-
-## CSS variables
-
-Css variables will not be added in our white label style components, but adding them in your own extension layer would be a perfect fit.
-
-## Parts and themes
-
-The `::part` and `::theme` specs might currently not be widely adopted enough to be used inside style components. When they are, we could be consider to add them later to our components as a means to theme components (changing a whole Design System is not a good idea).

package/docs/guides/principles/subclasser-apis.md

@@ -1,40 +0,0 @@
----
-parts:
-  - Principles
-  - Subclasser apis
-title: 'Subclasser apis'
-eleventyNavigation:
-  key: 'Principles: Subclasser apis'
-  order: 50
-  parent: Principles
-  title: Subclasser apis
----
-
-# Subclasser apis
-
-In order to make it easy for Subclassers to extend our components, we follow a certain set
-of best practices naming conventions to make our code predictable.
-
-## Templates
-
-### Template naming conventions
-
-For templates that do need access to the instance of the web component there is a prefix `_render/__render`.
-Examples are `__renderHeader` and `__renderData`.
-
-### Separation of concerns
-
-Our components should make it possible to override markup and styling, without having to redefine
-functionality.
-By using the spread directive, we can achieve this. For more info, see [explanation](https://github.com/ing-bank/lion/issues/591).
-
-## Node references
-
-As a Subclasser, you sometimes need access to a protected node inside the shadow dom.
-Most functional nodes have their own getters. A Subclasser can access those in his extension and
-in some cases, override these getters.
-
-### Node naming conventions
-
-A node reference will have an underscore prefix and always ends with `Node`.
-Examples are `_inputNode` and `_formNode`.