Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.

Releases

providence-analytics@0.13.0

Minor Changes

• 672c8e9: New documentation structure

Patch Changes

• ab7cc1e: providence-analytics: expose skipCheckMatchCompatibility: skips semver checks when targets and reference projects are matched. Handy for forward compatible libs and libs below v1
• 17dadab: providence-analytics: enhanced allowlistMode detection

publish-docs@0.2.0

Minor Changes

• 672c8e9: New documentation structure

remark-extend@0.5.0

Minor Changes

• 672c8e9: New documentation structure

rocket-preset-extend-lion-docs@0.3.0

Minor Changes

• 672c8e9: New documentation structure

Patch Changes

• Updated dependencies [672c8e9]
  • remark-extend@0.5.0

@lion/accordion@0.9.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/ajax@0.14.0

Minor Changes

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

@lion/button@0.17.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/calendar@0.19.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/localize@0.24.0

@lion/checkbox-group@0.20.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0

@lion/collapsible@0.8.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/combobox@0.10.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [d46b989]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [1ea9f29]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/listbox@0.13.0
  • @lion/overlays@0.32.0

@lion/core@0.22.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• 66531e3: SlotMixin: support scoped elements

@lion/dialog@0.15.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [d46b989]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/overlays@0.32.0

@lion/fieldset@0.21.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0

@lion/form@0.14.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/fieldset@0.21.0

@lion/form-core@0.17.0

Minor Changes

• 672c8e9: New documentation structure

• 7016a15: Validation: allow enums as outcome of a Validator

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

• f408f6f: Updated the ValidateMixin __setupValidators method to sync the calendar date with validator params with reference to this issue : https://github.com/ing-bank/lion/pull/1641/files#diff-bed9319548b16e509dd4a5c3d9c7c31175b577f91e433ee55a945e05339d2796R632

Patch Changes

• 9c1dfdc: FormControl: allow a label-sr-only flag to provide visually hidden labels
• 3772c94: form-core: expose 'mimicUserInput' test-helper
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/localize@0.24.0

@lion/form-integrations@0.11.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [a64c552]
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [f7df1ae]
• Updated dependencies [998d95f]
• Updated dependencies [1ea9f29]
• Updated dependencies [85318e3]
  • @lion/validate-messages@0.9.0
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/button@0.17.0
  • @lion/checkbox-group@0.20.0
  • @lion/combobox@0.10.0
  • @lion/fieldset@0.21.0
  • @lion/form@0.14.0
  • @lion/input@0.17.0
  • @lion/input-amount@0.16.0
  • @lion/input-date@0.14.0
  • @lion/input-datepicker@0.25.0
  • @lion/input-email@0.15.0
  • @lion/input-iban@0.18.0
  • @lion/input-range@0.12.0
  • @lion/input-stepper@0.8.0
  • @lion/listbox@0.13.0
  • @lion/localize@0.24.0
  • @lion/radio-group@0.20.0
  • @lion/select@0.16.0
  • @lion/select-rich@0.30.0
  • @lion/switch@0.20.0
  • @lion/textarea@0.15.0

@lion/helpers@0.11.0

Minor Changes

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/icon@0.15.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/input@0.17.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0

@lion/input-amount@0.16.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [a64c552]
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [f7df1ae]
• Updated dependencies [85318e3]
  • @lion/validate-messages@0.9.0
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0
  • @lion/localize@0.24.0

@lion/input-date@0.14.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [a64c552]
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [f7df1ae]
• Updated dependencies [85318e3]
  • @lion/validate-messages@0.9.0
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0
  • @lion/localize@0.24.0

@lion/input-datepicker@0.25.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

• 998d95f: Added a fix by overriding the __onValidatorUpdated() to sync the calendar dates when the validator params got changed

Patch Changes

• Updated dependencies [a64c552]
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [d46b989]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [f7df1ae]
• Updated dependencies [85318e3]
  • @lion/validate-messages@0.9.0
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/calendar@0.19.0
  • @lion/input-date@0.14.0
  • @lion/localize@0.24.0
  • @lion/overlays@0.32.0

@lion/input-email@0.15.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [a64c552]
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [f7df1ae]
• Updated dependencies [85318e3]
  • @lion/validate-messages@0.9.0
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0
  • @lion/localize@0.24.0

@lion/input-iban@0.18.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [a64c552]
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [f7df1ae]
• Updated dependencies [85318e3]
  • @lion/validate-messages@0.9.0
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0
  • @lion/localize@0.24.0

@lion/input-range@0.12.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/input@0.17.0
  • @lion/localize@0.24.0

@lion/input-stepper@0.8.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0

@lion/input-tel@0.1.0

Minor Changes

• a882c94: New component "LionInputTel"

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0
  • @lion/localize@0.24.0

@lion/input-tel-dropdown@0.1.0

Minor Changes

• 32b322c: New component LionInpuTelDropdown

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [a882c94]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/localize@0.24.0
  • @lion/input-tel@0.1.0

@lion/listbox@0.13.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• 1ea9f29: Fix: Prevent default behavior while scrolling using arrow keys in a horizontal listbox
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0

@lion/localize@0.24.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/overlays@0.32.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• d46b989: Fix check for css typed object support
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/pagination@0.8.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/localize@0.24.0

@lion/progress-indicator@0.8.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/localize@0.24.0

@lion/radio-group@0.20.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/input@0.17.0

@lion/select@0.16.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0

@lion/select-rich@0.30.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [d46b989]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
• Updated dependencies [1ea9f29]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/button@0.17.0
  • @lion/listbox@0.13.0
  • @lion/overlays@0.32.0

@lion/steps@0.11.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/switch@0.20.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0
  • @lion/helpers@0.11.0

@lion/tabs@0.12.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• 03c294c: tabs: allow to be initialized withhout children
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0

@lion/textarea@0.15.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/core@0.22.0

@lion/tooltip@0.23.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• Updated dependencies [66531e3]
• Updated dependencies [672c8e9]
• Updated dependencies [d46b989]
• Updated dependencies [aa8b891]
  • @lion/core@0.22.0
  • @lion/overlays@0.32.0

@lion/validate-messages@0.9.0

Minor Changes

• 672c8e9: New documentation structure

• aa8b891: BREAKING CHANGE: Work without polyfill if possible

  When using component composition in a Lion Component we always made it very explicit which sub-components are used.
  On top of that we scoped these sub components to the current shadow root allowing multiple version to be used simultaneously.

  To enable this features we relied on the fact that the ScopedElementsMixin did loaded the needed polyfill for us.

  We however over time got feedback from multiple consumers that lion components "break the app as soon as you load them".
  The reasons is/was that not everyone is always using ScopedElementsMixin or in full control of the app (or its load order).

  To quote the release notes of ScopedElementsMixin v2.1.0:

  ScopedElementsMixin 2.x tried to be as convenient as possible by automatically loading the scoped custom elements registry polyfill.
  This however led to a fatal error whenever you registered any component before ScopedElementsMixin was used.

  And this was the case.

  With the upgrade to @open-wc/scoped-elements v2.1.1 Lion now no longer automatically loads the polyfill through ScopedElementsMixin.

  This essentially means the polyfill became optional which results in the following behavior

  1. If polyfill is not loaded it will use the global registry as a fallback
  2. Log error if actually scoping is needed and polyfill is not loaded
  3. If you manually create elements you will need to handle polyfilled and not polyfilled cases now

  -  const myButton = this.shadowRoot.createElement('my-button');
  +  const myButton = this.createScopedElement('my-button');

  This also removes @webcomponents/scoped-custom-element-registry as a production dependency.

  If you need scoping be sure to load the polyfill before any other web component gets registered.

  It may look something like this in your HTML

  <script src="/node_modules/@webcomponents/scoped-custom-element-registry/scoped-custom-element-registry.min.js"></script>

  or if you have an SPA you can load it at the top of your app shell code

  import '@webcomponents/scoped-custom-element-registry';

  You need scoping if you want to

  use 2 major versions of a web component (e.g. in an SPA pageA uses 1.x and pageB uses 2.x of color-picker)
  or you want to use the same tag name with different implementations (use tag color-picker from foo here and from bar here)

  See more details at

  • Lion release blog post
  • @open-wc/scoped-elements release blog post
  • Change log of ScopedElementsMixin

Patch Changes

• a64c552: fix(validate-messages): typo IsData message
• f7df1ae: validate-messages: PhoneNumber messages
• 85318e3: Fixed en-PH default validation message
• Updated dependencies [9c1dfdc]
• Updated dependencies [3772c94]
• Updated dependencies [672c8e9]
• Updated dependencies [7016a15]
• Updated dependencies [a882c94]
• Updated dependencies [aa8b891]
• Updated dependencies [f408f6f]
  • @lion/form-core@0.17.0
  • @lion/localize@0.24.0
  • @lion/input-tel@0.1.0

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}